Understanding Cloudflare 520 Web Server Returns Unknown Error: The Catch-All Origin Failure

520 Web Server Returns Unknown Error is Cloudflare's catch-all: your origin sent back something, but it wasn't a response Cloudflare could make sense of. That's a deliberately fuzzy definition, and it covers a wide range of actual failures — an empty reply, a crashed PHP process, headers that blew past a size limit, a broken HTTP/2 negotiation. This post covers what a 520 actually promises (and doesn't), the specific causes Cloudflare's own documentation lists, and how to get past the generic error page to see what your origin really did.

What Is a 520?

A 520 means Cloudflare successfully connected to your origin server, but the response that came back wasn't something Cloudflare could interpret as valid HTTP.

Not a standard code. 520 doesn't appear in any RFC and isn't in the IANA HTTP status code registry. It's Cloudflare-proprietary, part of a family of 52x codes Cloudflare invented to describe its own connectivity problems talking to your origin — distinct from the standard 502 Bad Gateway, which is what a generic reverse proxy returns for a similar situation. If your site isn't behind Cloudflare, you will never see a 520; if it is, this is Cloudflare's edge, not your application, generating the page.

Cloudflare's documentation defines it plainly:

This error occurs when the origin server returns an empty, unknown, or unexpected response to Cloudflare. — Cloudflare documentation, Error 520

In plain English: the TCP connection worked, but whatever came back over it didn't look like a response Cloudflare's edge could parse as HTTP — or it parsed, but violated the protocol badly enough that Cloudflare gave up and substituted its own error page instead of forwarding something broken to the visitor.

Why 520 Is a Catch-All

Cloudflare sits between visitors and your origin server, terminating the visitor-facing connection and opening its own connection to your infrastructure. The 52x family of codes is Cloudflare reporting its own problem reaching or talking to your origin — as opposed to the standard gateway codes like 502 and 504, which report the same category of failure but aren't tied to a specific vendor's edge network. 520 specifically is the bucket for "I got a reply, but I can't do anything useful with it" — everything that isn't cleanly a refused connection (521), a timeout before a response (522), or an unreachable network path (523) lands here by elimination.

Cloudflare's docs list the specific triggers behind that bucket:

Origin server crashes or misconfigurations. Firewalls or security plugins blocking Cloudflare IPs at your origin. Headers exceeding 128 KB (often due to excessive cookies). Empty or malformed responses lacking an HTTP status code or response body. Missing response headers or origin web server not returning proper HTTP error responses. Incorrect HTTP/2 configuration at the origin server. Authentication Origin Pull enabled on Cloudflare but the origin is not configured as expected. — Cloudflare documentation, Error 520

The site's own data lines up with that list — origin crashes, invalid or malformed headers, and outright HTTP protocol violations are the recurring themes. One specific number worth remembering: the 128 KB header size limit, which is a common source of 520s that have nothing to do with the origin being broken — a session cookie or auth header that's grown too large over time is enough to trip it.

Cloudflare also flags one platform in particular: PHP. As their docs put it, "520 errors are prevalent with certain PHP applications that crash the origin web server." If you're running WordPress or another PHP stack and see a spike in 520s after a plugin update or traffic surge, a crashed PHP-FPM worker or exhausted memory limit is a good first guess.

520 vs. the Rest of the Cloudflare 52x Family

520 is the code you get when the connection itself wasn't the problem — the origin was reachable, accepted the TCP handshake, and sent something back. The something just wasn't usable HTTP.

Diagnosing a 520

The single most useful move is to see what your origin actually returned, without Cloudflare's edge translating it into a generic error page. A few ways to get there:

1. Check your origin's own logs first. If your web server or application logs show a clean 200 for the request that Cloudflare reported as a 520, the response was likely malformed on the way out — oversized headers or a truncated body are common culprits — rather than an application-level failure.
2. Temporarily bypass Cloudflare. Cloudflare's own guidance for this is to set the affected DNS record to DNS-only (commonly called "grey-clouding") in the Cloudflare DNS app, or pause Cloudflare on the zone entirely, as a temporary diagnostic step — this routes traffic directly to your origin so you can see its raw, unproxied behavior. Just remember this also removes Cloudflare's proxying and protection for that record while it's off, so treat it as short-lived.
3. Check HTTP/2 configuration if it's enabled at your origin. Cloudflare's documentation explains the failure mode precisely: "Cloudflare connects to servers who announce support of HTTP/2 connections via ALPN. If the origin web server accepts the HTTP/2 connection but then does not respect or support the protocol, an HTTP 520 error will be returned." If that matches your setup, Cloudflare's dashboard has a toggle to disable HTTP/2 to Origin under Speed → Settings → Protocol Optimization.
4. Watch for the header-size ceiling. If cookies or custom headers have grown over time (tracking IDs, JWTs, session data), audit their size — 128 KB sounds generous until a handful of large cookies stack up across subdomains.

If none of that resolves it, Cloudflare's support process asks for the full URL, the cf-ray ID from the error page, the output of /cdn-cgi/trace on your domain, and two HAR files — one captured with Cloudflare enabled and one with it disabled — so their team can compare the two paths directly.

Common Pitfalls

1. Assuming 520 always means the origin is "down." It doesn't — that's 521. A 520 means the origin answered; the answer just wasn't parseable HTTP. Chasing an uptime problem when the real issue is an oversized cookie wastes the investigation.
2. Not checking origin logs before escalating. If your application logs a clean 200 while Cloudflare logs a 520 for the same request, the bug is in what left the wire, not in your handler logic — look at response size and header formatting, not business logic.
3. Leaving Cloudflare's proxy on while trying to reproduce the raw origin response. You can't see what the origin actually sent through Cloudflare's edge once it's already converted the failure into a 520 page — you need the DNS-only bypass (or a direct request to the origin IP with the right Host header) to see the unfiltered response.
4. Overlooking HTTP/2-to-origin as a cause. It's an easy one to skip because the origin "looks" fine over HTTP/1.1 — the failure only shows up when Cloudflare negotiates HTTP/2 with a backend that doesn't fully support it.

Wrapping Up

520 is Cloudflare telling you it got an answer from your origin that it couldn't turn into a valid response — not that your server is unreachable or refusing connections. The rules of thumb:

• 520 = "I got a reply, but I couldn't parse it." Different failure mode from 521 (refused), 522 (timed out before replying), and 523 (unreachable).
• It's Cloudflare-specific, not an RFC status code — no IANA registry entry, same category as NGINX's 499.
• Oversized headers (128 KB+), malformed or empty responses, and PHP crashes are the most common real-world causes.
• Bypass Cloudflare (DNS-only mode) to see the origin's raw, unproxied response when the cause isn't obvious from logs alone.

For more, see our pages on 520 Web Server Returns Unknown Error, 521 Web Server Is Down, 522 Connection Timed Out, and 523 Origin Is Unreachable, or our posts on the standard-HTTP equivalents, 502 Bad Gateway and 504 Gateway Timeout.