Cloudflare Error 520: Web Server Returns Unknown Error

Cloudflare error 520 means your origin server answered Cloudflare, but the answer was unintelligible. Cloudflare's own documentation defines it as the origin returning "an empty, unknown, or unexpected response". That makes 520 the odd one out in the 52x family: the TCP connection succeeded and bytes came back, they just did not add up to a valid HTTP response. The most common real causes are an application crashing mid-response, response headers exceeding Cloudflare's 128 KB limit (usually from cookie bloat), a connection reset before the response completed, and a broken HTTP/2 configuration at the origin.

What does Cloudflare error 520 mean?

The error page reads "Web server returns an unknown error" and shows the familiar three-box diagram with the host marked as the failure. What Cloudflare is telling you is narrower and more useful than it looks. It reached your server. It opened a connection. It sent a request. Something came back. And whatever came back could not be parsed as HTTP.

That is a genuinely unusual failure. A healthy server that is overloaded returns a 503. A server that is down refuses the connection. A server behind a broken firewall stays silent. For a 520 you need a server that is alive enough to accept a socket and write to it, but that produces output which is empty, truncated, or malformed. In practice that means the response was cut off partway, or something upstream of your web server mangled it.

What causes Cloudflare error 520?

Cloudflare publishes a specific list, and unlike the vaguer 5xx codes it is worth taking literally. Every item on it describes a different way of producing a response that is not a response.

Cloudflare specifically notes that 520 is "prevalent with certain PHP applications that crash the origin web server", which is the single most useful hint in the entire document. A PHP fatal error, an out-of-memory kill, or a segfault in an extension will take down the worker handling the request. The socket closes. Cloudflare has half a response and nothing to do with it.

The 128 KB header limit is the cause almost nobody checks

This one deserves its own section because it produces the most baffling symptom pattern in the whole family: the site works perfectly for you in an incognito window and returns a 520 the moment you log in.

Cookies are sent as headers, and they accumulate. A session cookie, a CSRF token, a consent record, a few analytics identifiers, a marketing attribution blob, a feature-flag payload and a cart snapshot are individually small and collectively enormous. Set them all on the parent domain and they ride along on every request and every response. Once the total crosses 128 KB, Cloudflare stops trying and returns a 520.

The tell is that the failure follows the user, not the page. One person cannot load anything while everyone else is fine, and clearing cookies fixes it instantly, which is exactly the sort of report that arrives through a support ticket rather than through a dashboard. Because it is per-user rather than site-wide, uptime monitoring will show a clean green month while a slice of your customers cannot use the product at all, and teams usually only spot the pattern once they can see usage, tickets and feedback from the same customer in one timeline instead of three separate tools.

To check it, look at what you are actually setting:

curl -sI https://your-origin.example.com/ | awk '{ total += length($0) } END { print total " bytes of headers" }'

Run it again with a real session cookie attached. If the number jumps toward six figures, you have found it. The fix is to stop storing state in cookies: move the payload server-side and keep an identifier in the cookie, scope analytics cookies to the subdomain that needs them, and delete the ones nothing reads any more.

What is the difference between Cloudflare error 520, 521, 522, 523 and 524?

All five say the origin is at fault, and all five have completely different causes. The distinction is what your server did when Cloudflare knocked.

Read that table top to bottom and the diagnostic sequence falls out of it. 523 is a routing problem, 522 and 521 are connectivity problems, 524 is a performance problem, and 520 is an application problem. A 520 is the only one of the five where you can stop investigating the network entirely. The connection worked. Something in your code or your response is malformed, and no amount of firewall auditing will find it. If you are chasing the neighbouring codes, we have written up Cloudflare error 521 and Cloudflare error 522 in the same detail, and the standard gateway codes are covered in 502 bad gateway, 503 service unavailable and 504 gateway timeout.

How do I fix Cloudflare error 520?

Work in this order. It is arranged so the cheapest tests eliminate the largest number of causes first.

1. Confirm the origin is genuinely at fault

Bypass Cloudflare entirely and talk to the origin directly, keeping the Host header intact so virtual hosting still routes correctly:

curl -sv --resolve your-domain.com:443:ORIGIN_IP https://your-domain.com/ -o /dev/null

If that returns a clean response, the origin is fine for a plain request and the problem is specific to how Cloudflare is asking, which points at HTTP/2, Authenticated Origin Pull, or headers. If it also fails or returns something strange, you have a reproducible origin bug and you can debug it without Cloudflare in the way at all.

2. Read the origin's error log at the exact timestamp

This is the step people skip and it is the one that usually ends the investigation. Take the cf-ray value from the error page, note the time, and open the application and web server logs for that second. A crash writes something: a PHP fatal error, an out-of-memory kill in dmesg, a segfault, an nginx upstream prematurely closed connection line. A 520 caused by a crash is never silent at the origin, it is only silent at the edge.

3. Measure your response headers

Run the header-size check above, once anonymously and once with a logged-in session. If you are over 128 KB, or anywhere near it, that is your answer and nothing else on this list matters.

4. Turn off HTTP/2 to Origin

In the Cloudflare dashboard under Speed, disable "HTTP/2 to Origin" and retest. This is a one-click test that either clears the error or eliminates a whole category. Origin HTTP/2 implementations vary in quality, and an older nginx or a proxy in front of your app can negotiate the protocol and then handle it badly.

5. Disable recently changed origin security software

Security plugins and host-level WAFs sit in the request path and some of them return non-HTTP output when they block something. If a 520 started the day a plugin was installed or a rule set was updated, disable it long enough to test rather than reasoning about whether it could be responsible.

6. Check Authenticated Origin Pull

If this is enabled, the origin must be configured to accept and validate Cloudflare's client certificate. Enabling it on the Cloudflare side alone produces an immediate site-wide failure. This is worth checking early if the error appeared the moment somebody was hardening the setup.

7. As a temporary measure, go DNS-only

Setting the record to DNS-only in Cloudflare removes the proxy from the path. Visitors reach the origin directly and the 520 disappears, because the component reporting it is gone. Use this to confirm where the fault lies and to keep the site reachable while you fix it properly, not as a resolution: you lose the WAF, caching and origin IP masking for as long as it is off.

Why does Cloudflare error 520 come and go?

Because the two most common causes are both conditional rather than constant. A crash fires only on the code path that triggers it, so the error follows a specific URL, a specific input, or a specific level of concurrency. Header bloat fires only for users whose cookie set has grown past the limit, so it follows the person. Neither produces the steady site-wide failure that makes a problem easy to see.

This is why intermittent 520s so often sit unnoticed for weeks. A five minute uptime check hitting your homepage anonymously will pass every single time while a logged-in customer cannot load a page at all. If you want to catch this class of failure you have to check the paths where it actually happens: an authenticated endpoint, the checkout, the API route that returns the large response. API monitoring with custom headers and response assertions catches a malformed response that a plain homepage ping never will, and checking from several regions separates a real origin fault from one Cloudflare data centre having a bad ten minutes.

How do I find out if my site is returning 520s right now?

Cloudflare's Analytics section breaks down error responses by status code and by data centre, which tells you the scale and whether it is regional. That covers the past. For the present, you need something checking continuously from outside your own network, because a 520 is invisible from inside: the origin thinks it responded, and only the edge knows the response was unusable.

The practical setup is a check on a real, representative URL at 30 or 60 second intervals, from more than one region, asserting on the response body and not just the status code. That last part matters here more than for any other error in the family. A monitor that only looks for a 200 will happily accept a page that returned successfully with a broken body, and a 520 is by definition a response that looked like something and was not.

It is also worth understanding what these outages cost you against whatever you have promised. An intermittent 520 affecting one in twenty requests will not register on an availability figure measured by homepage pings, but it is a real outage for the customers hitting it. If you publish an availability commitment, 99.95% uptime gives you 21 minutes 36 seconds of downtime a month and 99.99% uptime gives you 4 minutes 19 seconds, which is less time than most teams need to notice a 520 is happening at all, let alone fix it.

Frequently asked questions about Cloudflare error 520

Is Cloudflare error 520 my fault or Cloudflare's?

Almost always yours, in the sense that the fault is at the origin. Cloudflare returns a 520 when it received a response it could not parse, which means the connection succeeded and your server produced the invalid output. The exceptions are rare: a misconfigured Cloudflare feature such as Authenticated Origin Pull or HTTP/2 to Origin can create the conditions for it, but the malformed response still comes from the origin.

What is error code 520 on Cloudflare in plain terms?

Your server answered with something that was not a valid web page. Not an error page, not a slow page, not a refused connection. An answer that could not be read as HTTP at all, usually because the process died partway through writing it or because the headers were too large to accept.

How do I fix Cloudflare error 520 on WordPress?

Check the PHP error log first, because on WordPress a 520 is usually a fatal error in a plugin or theme killing the request. Raise the PHP memory limit, then deactivate plugins in halves until the error stops. Security plugins are the most frequent culprit because they sit in the request path. If the error only affects logged-in users, it is header bloat from cookies rather than a crash, and the plugin hunt will waste your afternoon.

Does error 520 mean my server is down?

No, and that is the most important thing to understand about it. A server that is down produces a 521 or a 522. A 520 requires a server that is running, listening, and accepting connections. It is a partially working server, which is why it can return 520s on some requests and serve others perfectly at the same moment.

What does "error reference number 520" mean?

It is the same error. Cloudflare's error pages label the code as a reference number alongside the cf-ray identifier, which is the value support will ask for. The reference number tells you the class of failure; the ray ID identifies the specific request so it can be traced through Cloudflare's logs.

How long does a Cloudflare 520 error last?

As long as the underlying condition does. There is no timeout or automatic recovery, because Cloudflare is not waiting for anything. It asked, it got an unusable answer, and it reported that. If a crash caused it, the error lasts until the crashing request stops being made or the bug is fixed. If cookie bloat caused it, it lasts until those cookies are cleared or scoped properly.

Can I just turn off Cloudflare to fix a 520?

You can make the error message disappear that way, and it is a reasonable emergency measure to keep a site reachable. It does not fix anything. The malformed response is still being produced; without the proxy, the browser receives it directly and usually shows a blank page or a connection error instead. You have swapped a clear diagnostic for a vague one, and lost your WAF and caching in the process.

The short version

A 520 is the only Cloudflare 5xx that tells you the network is fine. The connection succeeded, the request arrived, and the response came back broken. That narrows the search to four things worth checking in order: the origin error log at the timestamp of the failure, the total size of your response headers against the 128 KB limit, whether HTTP/2 to Origin is negotiating something the origin cannot handle, and whether a security plugin or Authenticated Origin Pull has recently been introduced into the request path. Almost every 520 is one of those four, and the log usually names it outright.

The harder part is knowing it is happening. Because 520s are typically conditional rather than constant, they hide from anonymous homepage checks and surface through customer complaints days later. Monitoring the paths where the error actually lives, with response assertions rather than a bare status check, is what turns a 520 from a mystery into a fifteen minute fix.