520 Unknown Error means Cloudflare reached your origin server, but the origin returned something Cloudflare could not interpret as a valid HTTP response. In plain terms, the connection got far enough to touch the server, but the server answered with an empty, malformed, incomplete, or unexpected response.
This is why Error 520 is frustrating. It is a real server-side problem, but it is often vague on the surface. The fix is usually not in Cloudflare itself. It is in the origin server, the application, the firewall, the HTTP/2 setup, or the response headers.
Quick Fix
- Reload the page once and check whether the error is temporary.
- Pause Cloudflare temporarily and test the origin directly.
- Restart the origin web server, PHP-FPM, or application service.
- Check server error logs, PHP logs, and firewall logs.
- Make sure your firewall is not blocking Cloudflare IP ranges.
- Inspect response headers and cookies for abnormal size.
- Disable problematic WordPress plugins or recent code changes.
- If HTTP/2 to origin is enabled, test with it disabled.
- Check Authenticated Origin Pulls if you use them.
- Retest with a simple static page to isolate app-level failures.
What Is 520 Unknown Error (Cloudflare)?
520 Unknown Error is a Cloudflare 5xx error shown when Cloudflare receives an empty, unknown, or otherwise unexpected response from the origin server.
That distinction matters. A 520 error does not usually mean Cloudflare could not reach the origin at all. If Cloudflare cannot connect to the origin, you are more likely to see errors like 521, 522, or 523 instead.
With 520, the request generally gets this far:
- The visitor reaches Cloudflare.
- Cloudflare connects to the origin.
- The origin responds badly or incompletely.
- Cloudflare cannot turn that response into a normal HTTP response.
That is why 520 is often described as a catch-all Cloudflare origin-response problem. It usually points to something unexpected on the web server or application side.
Why 520 Unknown Error Happens
Most 520 cases come from a small group of real causes. Once you check them in the right order, the error becomes much less mysterious.
1. The Origin Server Crashed or Glitched Mid-Request
This is one of the most common causes.
Examples:
- PHP-FPM crashed during page generation
- a WordPress plugin triggered a fatal error
- the application process ran out of memory
- the origin closed the connection too early
Cloudflare specifically notes that 520 is common with certain PHP applications that crash the origin web server.
2. The Origin Returned an Empty or Malformed Response
The origin may answer in a way that is not valid HTTP.
Typical patterns:
- empty response body with no valid status handling
- missing required response headers
- broken status line
- partial response followed by connection reset
Even when the origin is “up,” this kind of response can still trigger 520.
3. A Firewall or Security Plugin Is Blocking Cloudflare
This is another very common cause. The web server itself may work, but something in front of it is rejecting or mangling requests from Cloudflare.
Typical culprits:
- host firewall rules
- mod_security rules
- WordPress security plugins
- fail2ban or automated IP bans
- hosting firewall rules that do not trust Cloudflare IPs
If Cloudflare IP ranges are not allowed correctly, the origin may behave unpredictably instead of returning a clean block response.
4. Response Headers Are Too Large
Oversized response headers are a major real-world trigger for 520.
This often happens because of:
- too many cookies
- very large cookies
- duplicated
Set-Cookieheaders - plugins or apps appending large debug or auth headers
Cloudflare documents header size as a direct 520 cause. Since late 2025, Cloudflare supports up to 128 KB for response headers, which reduces this problem compared with older limits, but broken applications can still exceed practical limits or return malformed header sets. :contentReference[oaicite:1]{index=1}
5. HTTP/2 to Origin Is Broken
This cause is easy to miss. Cloudflare can connect to origins over HTTP/2 when the origin advertises support via ALPN. If the origin accepts the HTTP/2 connection but does not actually handle the protocol correctly, Cloudflare says a 520 can result.
This is especially relevant on:
- older NGINX builds
- misconfigured Apache setups
- custom TLS stacks
- reverse proxies in front of the app
6. Authenticated Origin Pulls Are Misconfigured
If Cloudflare is configured to require Authenticated Origin Pulls, but the origin is not set up to validate that connection properly, Cloudflare lists that as another 520 cause.
This tends to happen after:
- partial SSL hardening changes
- server migrations
- new origin certificate deployment
- switching between Cloudflare SSL modes without matching origin changes
7. WordPress, PHP, or Application-Level Failures
On WordPress and PHP sites, 520 often comes from the app layer, not the web server layer.
Typical examples:
- plugin conflicts
- theme fatal errors
- memory exhaustion
- bad redirect logic
- broken cache layers
- custom code that outputs malformed headers
If the origin generates unstable output under Cloudflare but looks “mostly fine” in simple manual tests, the application is a strong suspect.
8. The Origin Is Overloaded
Under load, an origin may start sending resets, truncated responses, or other unexpected output.
This becomes more likely when:
- CPU is maxed out
- PHP workers are exhausted
- database latency spikes
- concurrency from Cloudflare overwhelms a weak origin
Cloudflare also notes that some 520 and 522 problems can be linked to concurrency bursts hitting underpowered origins.
How to Fix 520 Unknown Error Step by Step
The best way to fix 520 is to isolate the failing layer quickly: Cloudflare edge, origin web server, app, or a security tool in between.
1. Check Whether the Error Is Temporary
Try one normal reload. Then stop.
- If it disappears immediately, you may be looking at a temporary origin crash or overload spike.
- If it returns consistently, move to logs and origin checks.
Do not keep hard-refreshing. That adds noise and can worsen load problems.
2. Test the Origin Directly
This is one of the fastest and most useful checks.
Temporarily pause Cloudflare for the record, or test the origin in a controlled way using the origin IP and correct host header.
What the result means:
- If the origin also fails directly, the problem is definitely behind Cloudflare.
- If the origin works directly but fails through Cloudflare, focus on headers, HTTP/2, firewall rules, SSL, and proxy behavior.
3. Check Web Server and Application Logs Immediately
Start with the time of the failure and look at:
- NGINX or Apache error logs
- PHP-FPM logs
- application logs
- WordPress debug logs if enabled
- firewall logs
Cloudflare specifically advises that the cause of a 5xx error is not always in the main origin logs alone. You should also check logs on any proxies, caches, firewalls, or load balancers between Cloudflare and the origin. :contentReference[oaicite:2]{index=2}
4. Restart the Origin Services
If the site is failing right now, restart the likely weak point.
Typical restart targets:
- NGINX
- Apache
- PHP-FPM
- the app service
- container stack if you use one
This is not the final fix, but it often restores service and confirms whether a crashed or wedged process was involved.
5. Check Whether Cloudflare IPs Are Allowed
This is a high-priority check on any proxied site.
Make sure:
- your firewall allows Cloudflare IP ranges
- security plugins are not banning Cloudflare
- mod_security is not blocking normal proxied requests
- rate limiting is not hitting Cloudflare edge IPs incorrectly
If your origin treats Cloudflare as an attacker, you can get unstable or malformed responses instead of a clean error.
6. Inspect Response Headers and Cookies
This is essential for stubborn 520 cases.
Check for:
- too many
Set-Cookieheaders - very large cookies
- duplicated headers
- strange custom headers
- broken cache headers or malformed output
If a page works when logged out but fails when logged in, cookies are an especially strong suspect.
7. Disable Problematic WordPress Plugins or Recent Code Changes
If you run WordPress, this should happen early.
Temporarily disable:
- security plugins
- cache plugins
- redirect plugins
- membership or login plugins
- anything changed recently
Then test again.
Cloudflare explicitly notes that 520 is common with some PHP applications, so a plugin or theme crash is a realistic cause, not an edge case. :contentReference[oaicite:3]{index=3}
8. Test a Simple Static Page
This is one of the best isolation tricks.
Create or request a simple static HTML page that does not depend on:
- PHP
- database queries
- sessions
- app logic
If the static page works but dynamic pages fail, focus on PHP, the app, and response headers generated by the application.
9. Check HTTP/2 to Origin
If your origin advertises HTTP/2 to Cloudflare, make sure it really handles it correctly.
Cloudflare states that if the origin accepts the HTTP/2 connection but then does not properly support the protocol, Cloudflare can return 520. One official troubleshooting step is to disable HTTP/2 to Origin and retest. :contentReference[oaicite:4]{index=4}
This step is especially worth trying if:
- the error started after TLS or proxy changes
- the origin uses a custom reverse proxy stack
- the site intermittently fails under load
10. Verify Authenticated Origin Pulls
If you enabled Authenticated Origin Pulls, confirm the origin is configured to expect and validate them correctly.
Misalignment here can produce confusing origin failures that surface as 520.
Check:
- certificate trust on the origin
- origin SSL configuration
- whether the feature was enabled only on one side
11. Check Resource Limits on the Origin
Underpowered origins often produce sloppy failures instead of clean 500-series responses.
Look at:
- CPU usage
- memory exhaustion
- PHP-FPM worker limits
- database connection saturation
- container restarts or OOM kills
If the error spikes during traffic bursts, resource pressure is a strong possibility.
12. Review Reverse Proxies, Caches, and Load Balancers
The origin is not always just Apache or NGINX. The real path might include:
- Cloudflare
- load balancer
- NGINX reverse proxy
- Apache
- PHP-FPM or the app
If a middle layer resets or mangles the response, Cloudflare still sees that as an origin problem.
13. Capture the Failure Details
Cloudflare’s 5xx guidance recommends collecting the exact error code, time, timezone, and URL when escalating. That is not just support boilerplate. It helps match edge events to origin-side logs. :contentReference[oaicite:5]{index=5}
Record:
- exact URL
- time of failure
- timezone
- whether logged-in or logged-out
- whether it affects only some paths or all paths
Advanced Troubleshooting
Identify Whether the Response Is Empty, Truncated, or Malformed
Not all 520s are the same. The origin may:
- send nothing at all
- start sending output and then die
- return malformed headers
- break HTTP/2 negotiation
This distinction matters because each one points to a different layer.
Use a Packet Capture or Deep Network Trace if Needed
Cloudflare notes that some 520 issues can involve lower-layer problems and may require packet capture or deeper connection-level investigation, especially when logs do not clearly explain the failure. :contentReference[oaicite:6]{index=6}
This is worth doing when:
- the error is intermittent
- the app logs look clean
- the connection resets before normal HTTP logging
Compare Logged-In vs Logged-Out Behavior
If only authenticated pages fail, think about:
- cookie bloat
- membership plugins
- session handling
- app logic that adds many headers
This is one of the fastest ways to narrow the cause.
Review Recent Changes First
Ask what changed before the error began.
- new plugin
- new cache layer
- SSL mode changes
- HTTP/2 changes
- firewall hardening
- server migration
Most 520 incidents start right after a configuration or deployment change.
Prevention Tips
- Keep the origin stable under realistic traffic.
- Allow Cloudflare IP ranges at the firewall.
- Monitor PHP-FPM, app crashes, and resource exhaustion.
- Avoid oversized cookies and excessive response headers.
- Test HTTP/2 to origin carefully before leaving it enabled.
- Review security plugins after every major update.
- Check logs after deployments, not only after incidents.
- Document SSL and origin-pull settings so they stay consistent after migrations.
The best prevention is simple: make sure the origin always returns a clean, valid HTTP response even when the app fails.
When to Contact Support
Contact your hosting provider or server admin if:
- the origin is crashing
- the web server logs show app or PHP failures
- resource exhaustion is involved
- you cannot inspect the origin stack yourself
Contact Cloudflare support or use Cloudflare troubleshooting resources if:
- you confirmed the origin is healthy directly but 520 still appears through Cloudflare
- HTTP/2 to origin seems involved
- Authenticated Origin Pulls may be misconfigured
- you need help correlating edge behavior with origin data
Cloudflare’s support docs also recommend including the exact 5xx code, URL, time, and timezone when escalating. :contentReference[oaicite:7]{index=7}
FAQ
What does 520 Unknown Error mean in Cloudflare?
It means Cloudflare connected to the origin server but received an empty, malformed, unknown, or otherwise unexpected HTTP response from it.
Is Error 520 a Cloudflare problem or a server problem?
Most of the time it is an origin-side problem. The issue usually sits on the web server, application, firewall, headers, or origin protocol behavior, not in the Cloudflare edge alone.
Can WordPress cause Cloudflare Error 520?
Yes. Plugin conflicts, PHP crashes, bad redirects, memory exhaustion, and oversized cookies or headers can all trigger 520 on WordPress sites.
Can HTTP/2 cause Error 520?
Yes. Cloudflare says that if the origin accepts an HTTP/2 connection but does not properly support the protocol, a 520 can result.
How do I fix Cloudflare Error 520 fast?
Test the origin directly, check logs, allow Cloudflare IPs, inspect response headers, restart the origin services, disable problematic plugins or recent changes, and test whether HTTP/2 to origin is involved.
Final Thoughts
520 Unknown Error looks vague, but the root cause is usually practical. The origin responded in a way Cloudflare could not understand or trust as valid HTTP.
Start by isolating the origin. Then check app crashes, firewalls, oversized headers, HTTP/2 to origin, and any recent changes. That order solves most 520 incidents much faster than treating it like a generic Cloudflare outage.