HTTP 520: Decoding Cloudflare's Unknown Error

Aug 04, 2026 · HTTP Status Codes

You won't find the 520 status code in any RFC. Search the official HTTP specifications and it simply isn't there — because 520 isn't an HTTP standard, it's a Cloudflare invention. When Cloudflare's edge forwards a request to your origin server and gets back something it can't classify as any specific, nameable failure, it files the incident under 520: "Web Server Returned an Unknown Error." It's the junk drawer of Cloudflare's error codes, and that's precisely what makes it frustrating — every other error tells you what went wrong, while 520 tells you only that something did and Cloudflare couldn't tell what.

The good news: the real error exists. It's just sitting at your origin, unlabeled, and there's a reliable process for digging it out.

What the 520 status code covers (and what it doesn't)

Cloudflare uses 520 as the fallback when the origin's behavior doesn't match a more specific code in its 52x range. The connection to your origin worked at the TCP level — that's what separates 520 from its siblings. If the origin refuses the connection outright, that's a 521. If the connection can't be established at all within the time limit, that's a 522. A 520 means Cloudflare got through, sent the request, and then received something broken back: an empty response, a connection that reset mid-reply, headers that don't parse, or a response so malformed it defies categorization.

So a 520 always tells you two things for free: your server is reachable and listening, and whatever it sent back was wrong in a way Cloudflare hadn't seen fit to name.

Why Cloudflare invented its own error codes

Standard HTTP has one word for "the thing behind me failed": 502 Bad Gateway. That's fine for a simple proxy, but Cloudflare sits in front of millions of origins and needs to distinguish "refused me" from "timed out on me" from "sent me garbage" — each has different fixes and different owners. So they carved the 520–526 range out of the unassigned 5xx space, one code per failure mode, with 520 as the residual bucket. Non-standard, but diagnostic. It's a natural consequence of how a CDN works: an intermediary that terminates millions of client connections needs richer vocabulary for origin failures than the standard provides.

The origin responses that trigger a 520

• Empty replies. The origin accepts the connection, then closes it without sending a single byte. Classic causes: an app process that crashes on this specific request, or a web server accepting connections it has no virtual host configured to answer.
• Connection resets mid-response. The origin starts replying and dies partway — a segfaulting worker, an OOM kill at the wrong moment, an aggressive connection-killing rule on the origin firewall.
• Oversized headers. Cloudflare caps total response header size (historically in the 16 KB range). The classic offender is an application stuffing enormous amounts of data into cookies — a few bloated Set-Cookie headers can push a perfectly healthy response over the limit and turn it into a 520.
• Malformed HTTP. A misconfigured service answering on the wrong port, a debugging tool left listening in production, or an app emitting a corrupt status line — anything that makes the response unparseable as HTTP.
• Origin-side interference. Security modules (mod_security rules that drop connections rather than answering), or the origin server silently dropping requests carrying certain Cloudflare headers.

Digging out the real error

The whole game is comparing what Cloudflare sees with what your origin says. Start by bypassing Cloudflare entirely: curl -v --resolve yoursite.com:443:203.0.113.10 https://yoursite.com/failing-page/ (with your actual origin IP) sends the same request straight to the origin. Three outcomes, three directions. If the direct request also fails or hangs, your origin has a plain server-side bug — go read its error logs like you would for any 500-class error. If the direct request succeeds, the origin behaves differently when Cloudflare is the client — now compare header sizes (curl -sI and measure; look hard at Set-Cookie), check whether origin security rules react to Cloudflare's added headers, and confirm the origin firewall isn't resetting long responses. If the direct request succeeds and headers look sane, capture timing: intermittent 520s under load usually mean workers dying on specific heavy requests, which shows up in the origin error log with matching timestamps.

Two more evidence sources worth pulling: the Ray ID on Cloudflare's error page (support can look up exactly what the edge observed for that request), and your origin's access log for the same moment — a request that appears there with a weird status, or doesn't appear at all despite arriving, narrows things fast.

Does a 520 affect crawling and rankings?

Googlebot doesn't have special handling for Cloudflare's custom codes; anything in the 5xx range is a server error, and 520 gets the standard 5xx treatment. Occasional ones are ignored. A recurring pattern slows your crawl rate, and weeks of persistent 520s will start costing you indexed URLs — same trajectory as chronic 500s or 502s. The particular danger with 520 is that it's often partial: one route with bloated cookies, one page that crashes a worker, erroring for months while the rest of the site works. Nobody notices, except every crawler that visits that URL. Run an automated crawl of your site on a schedule so per-URL failures like that surface as a report instead of as a slow leak in your search traffic.

Preventing repeat 520s

Keep response headers lean — audit what your app sticks in cookies, and cap session payloads server-side rather than round-tripping data through the browser. Supervise origin processes so a crashed worker restarts in seconds. Make sure origin firewall and security rules treat Cloudflare's IP ranges and headers as expected traffic, not anomalies. And monitor from outside Cloudflare as well as through it: a check that hits the origin directly will tell you whether a future incident is origin-side or edge-side before you've even opened a terminal.