Quick answer: Error 520 ("Web server returns an unknown error") is a Cloudflare-specific code meaning Cloudflare connected to the website's origin server, but the origin sent back something Cloudflare couldn't interpret: an empty response, a malformed reply, a crash mid-response, or a connection reset. If you're a visitor, refresh and try again later; the problem is on the website's side. If you own the site, the fix lives on your origin server, and the checklist below covers the usual suspects.
520 is famously vague (Cloudflare itself calls it a catch-all), but the vagueness has structure once you know what it excludes.
Where 520 Sits in Cloudflare's Error Family
Cloudflare sits between visitors and origin servers, so it invented the 52x codes to describe origin problems precisely. Each one blames a different failure:
| Code | What happened at the origin |
|---|---|
| 520 | Responded, but with something empty or uninterpretable |
| 521 | Refused the connection (web server down or blocking Cloudflare) |
| 522 | Connection timed out |
| 523 | Unreachable (routing problem) |
| 524 | Connected fine, but took too long to produce a response |
| 525 | TLS handshake with the origin failed |
| 526 | Origin's TLS certificate is invalid |
So a 520 specifically means: the TCP connection worked, the request went through, and what came back was garbage or nothing. That rules out DNS, routing, and most firewall explanations and points at the web server or application itself.
If You're a Visitor
There's little you can do about someone else's origin server, but three things are worth a minute:
- Refresh once or twice. 520s are often transient, caused by a brief origin crash or restart.
- Try again in a few minutes. If the site is deploying or overloaded, it usually recovers quickly.
- Clear cookies for the site. Oversized cookie headers are a documented 520 cause, and they're the one contributor that lives in your browser.
If it persists for hours, the site's operators have a real problem; there's nothing client-side left to fix.
If You Own the Site: The Diagnostic Checklist
The evidence you need is on your origin, not in Cloudflare's dashboard. Work through these in order:
1. Check whether the origin responds at all. Bypass Cloudflare and hit the origin directly (curl against the server's IP with the right Host header). If that fails or returns something malformed, you've reproduced the problem without Cloudflare in the picture.
2. Read the origin's error logs at the timestamp of the 520. Application crashes, out-of-memory kills, and segfaulting workers all produce the empty-response signature Cloudflare reports as 520.
3. Look for oversized headers. Cloudflare has header size limits (32 KB total). Applications that stuff session state into cookies can exceed it, and the result is a 520. If the errors correlate with logged-in users, suspect this first.
4. Check your web server's keepalive and proxy settings. Connection resets from aggressive timeouts, or a proxy in front of your app returning raw TCP resets instead of HTTP errors, both read as "unknown error" to Cloudflare.
5. Confirm nothing is blocking or mangling Cloudflare's requests. Security modules or rate limiters on the origin that drop connections mid-response (rather than returning a proper 4xx) will generate 520s. Allowlist Cloudflare's published IP ranges.
In my experience the split is roughly: half application crashes, a quarter header and cookie bloat, and the rest server misconfiguration. The application logs settle it fast; guessing without them doesn't.
If You're Scraping and Hitting 520s
Data pipelines meet 520s too, and the interpretation differs from a normal block. A 403 or a challenge page means the site refused you; a 520 means the site is genuinely struggling. Hammering a struggling origin makes you part of the problem and gets your IPs flagged when the site recovers.
The right client behavior: treat 520 as transient, retry a small number of times with generous exponential backoff (start at 30 seconds, not 2), and if a domain 520s persistently, park it and come back hours later. A managed fetch layer like link.sc bakes this policy in, along with distinguishing "origin is down" from "you are blocked," which look identical in a naive status-code check but demand opposite responses.
The Bottom Line
520 means Cloudflare asked, the origin answered, and the answer was gibberish. Visitors can only wait. Site owners should go straight to origin logs at the failure timestamp, then check header sizes and proxy configuration. And automated clients should back off politely, because behind every 520 is a server having a genuinely bad day.
Fetching at scale and tired of decoding 52x tea leaves? Get a free link.sc API key and let the retry policy be someone else's code.