How to Fix Cloudflare Error 520 (Web Server Returned an Unknown Error)
What Error 520 means
Cloudflare sits between you and the website's server (the "origin"). Normally it fetches the page from the origin and hands it to you. Error 520 — "Web server is returning an unknown error" — means Cloudflare got through to the origin, but what came back was unusable: an empty reply, a connection that was reset mid-transfer, or headers so malformed that Cloudflare could not parse them into a page. Nothing about your browser caused this in the overwhelming majority of cases; the server failed to produce a valid response.
The useful distinction: 520 is not 521 (origin refused the connection), not 522 (origin timed out), and not 523 (origin unreachable). With 520, the origin answered — it just answered badly. For a site owner, that narrows the hunt enormously: the network path is fine, and the fault is in the application, the response it generated, or something that killed the connection mid-reply. And for a visitor, it means patience often pays — many 520s are a single crashed request in an otherwise healthy server, cleared by a retry a minute later.
Common causes
- Crashed application worker: a PHP worker segfaults, a Node process dies mid-request, or a database connection fails — the origin starts a response and never finishes it, and Cloudflare reports 520.
- Connection reset between Cloudflare and origin: a firewall, fail2ban rule, or host-level rate limiter drops the edge server's connection (TCP reset), or keeps alive connections get severed. The reply simply stops.
- Oversized response headers: dozens of cookies or long custom headers push the header block past what the Cloudflare-to-origin exchange tolerates, and the response is rejected as invalid.
- Origin overload or memory pressure: the server is out of memory, swap-thrashing, or queued past its limits — the kernel's out-of-memory killer may take down the very worker handling your request.
- Broken server or middleware configuration: a bad .htaccess rule, a redirect loop, a misconfigured reverse proxy, or disabled keep-alive behavior can all produce responses Cloudflare cannot interpret.
How to fix Error 520 — step by step
Steps 1 through 3 are for visitors. Steps 4 through 6 are for site owners.
- Visitor: wait a minute and do a hard refresh. 520 errors are frequently transient — a crashed PHP worker, a brief database lock, or a momentary overload that clears itself. Wait 60 seconds, then hard-refresh the page: Ctrl+Shift+R on Windows or Cmd+Shift+R on Mac, which skips the browser cache and requests a fresh copy. If the page loads, the origin stumbled once and recovered; nothing on your side needs fixing.
- Visitor: test the site from another device or network. Open the same page in a private or incognito window, on your phone over mobile data, or through a down-detector service like Down for Everyone or Just Me. If the site loads for anyone else, the failure is specific to your connection — clear your browser cache and cookies for that site and try again. If nobody can reach it, the problem is at the site's server and only the owner can fix it.
- Visitor: clear cookies for the site if the error persists. An oversized cookie jar is a real cause of 520s: the server rejects the request because the response headers it would generate are too large, and Cloudflare shows you 520 instead of the underlying failure. Open your browser settings, find Cookies and site data, search for the site's domain, and delete its cookies. Reload the page — if it loads, a bloated cookie was the trigger.
- Site owner: read the origin server's error log first. Error 520 means Cloudflare connected to your origin but received an empty, incomplete, or otherwise invalid response. On the origin server, open the error log — /var/log/nginx/error.log for Nginx, the Apache error log, or the PHP-FPM error log — and look at the timestamps matching the 520 reports. The common findings: a crashed PHP worker (segfault), an out-of-memory kill, a database connection failure, or an application exception that aborted the response mid-stream. Fix what the log names — 520 is a symptom, and the log holds the diagnosis.
- Site owner: check for oversized response headers and disabled keep-alives. Response headers larger than roughly 8 to 16 KB break the Cloudflare-to-origin exchange and surface as 520 — the usual culprits are dozens of cookies being set, or long custom headers. Trim what the application sends: set fewer cookies, shorten their values, and strip unnecessary custom headers. In Nginx, confirm that keepalive connections to upstreams are enabled and increase fastcgi_buffers and proxy_buffer_size if your application legitimately sends large headers; for Apache behind a proxy, check that the proxy can buffer the response. Restart the web server and retest through Cloudflare.
- Site owner: verify Cloudflare is not being blocked, then test the origin directly. Confirm your origin firewall, fail2ban rules, or host's rate limiter is not dropping Cloudflare's edge IP ranges — allowlist Cloudflare's published IPs if in doubt, since a reset connection from a blocked edge node produces exactly this error. Then bypass the proxy to isolate the fault: in Cloudflare DNS, grey-cloud (DNS only) the record, wait for propagation, and load the site directly. If the direct origin also fails, the fault is entirely on your server; if the direct origin works but orange-clouded requests still 520, the breakage is in the Cloudflare-to-origin path — re-check TLS settings, keep-alive behavior, and any middleware sitting between them.
Did this fix it? Quick checklist
- A hard refresh after waiting 60 seconds loads the page (transient hiccup)
- Another network or a down-detector shows the site works for others
- The site's cookies have been cleared and the page was retried
- Owner-side: the origin error log names the fault, and Cloudflare's edge IPs are allowlisted
If the 520 appears at the same time every day, suspect a scheduled job — backups, cron tasks, and traffic spikes from a newsletter send all create brief overloads that produce exactly one or two 520s and then vanish. Owners should correlate the timestamps with their cron schedule and server load graphs; visitors experiencing a daily 520 can simply retry after a few minutes. And if a 520 has persisted for hours with no change, stop retrying from your side — the origin is down in a way only the site's team can repair, so use their contact page or social channels instead of wearing out your refresh key.
Frequently asked questions
What does Cloudflare Error 520 mean?
Error 520 — "Web server is returning an unknown error" — means Cloudflare successfully reached your website's origin server, but the server replied with something empty, incomplete, or malformed that Cloudflare could not turn into a page. It is an origin-server problem wearing a Cloudflare mask: the site itself failed to produce a valid response, and Cloudflare is only the messenger.
Is Error 520 my fault as a visitor?
Almost never. A 520 means the site's server hiccuped or misbehaved — a crashed script, a database lock, a firewall rule, or oversized headers — none of which live on your device. The only visitor-side triggers are rare: a bloated cookie for the site, or a flaky connection that drops mid-request. Try a hard refresh, wait a minute, clear the site's cookies, and if it still fails, the fix belongs to the site owner.
How is Error 520 different from 521, 522, and 523?
They are four different ways the origin handshake fails. 521 means the origin refused the connection outright (server down or blocking Cloudflare). 522 means the origin accepted the connection but never answered in time (a timeout). 523 means the origin is unreachable at the network level. 520 is the odd one: the origin answered, but its answer was empty or broken. That distinction matters for owners — 520 points at the application and response, not the network.
How do I tell whether a 520 is transient or persistent?
Wait a full minute and hard-refresh. If it loads, it was transient — one crashed request among healthy ones, common after deployments, traffic spikes, or a brief database stall. If the 520 repeats on every refresh, from every device and network, it is persistent: something in the server's current state is broken for every request, and the owner needs to read the error log. Transient 520s that recur daily at the same time usually mean a cron job, backup, or traffic pattern is overloading the server on a schedule.
I'm a site owner — where do I look first for a 520?
The origin error log, matched to the time of the 520 reports — it almost always names the crashed worker, killed process, or failed database query. Next, check whether your application is emitting oversized response headers (cookie bloat is the classic), then verify your firewall is not blocking Cloudflare's edge IPs, since a reset connection produces a 520. Finally, grey-cloud the DNS record and test the origin directly: if it fails without Cloudflare too, the fault is entirely on your server.