Cloudflare Error 520: what it means and how to fix it

What error 520 means

Cloudflare sits between the visitor and your web server as a reverse proxy. For a normal request it opens a TCP connection to your origin, sends the request, and relays whatever HTTP response comes back. Error 520 fires when that last step fails: the TCP connection succeeds, but the bytes that follow do not parse as a valid HTTP response, or no bytes arrive at all before the connection closes.

That puts 520 in a different category from Cloudflare's other 5xx codes. Error 521 means the origin refused the connection outright. Error 522 means the connection attempt timed out. Error 520 means the origin said something, and Cloudflare could not make sense of it or pass it along.

How error 520 appears

In a browser, Cloudflare shows its own error page, "Error 520: web server returned an unknown error", along with a Ray ID you will need if you contact Cloudflare support. A plain curl request against the domain shows the same status code:

curl -I https://example.com
HTTP/2 520

On the Cloudflare side, the dashboard's Security or Analytics tabs show a spike in 5xx responses, and Enterprise accounts with Logpull or Logpush access can pull the specific edge colo and Ray ID for each failed request. None of that tells you what the origin actually sent, though, so the next place to look is your own server.

On the origin, check the web server and application logs for the same timestamp as the failures. Look for a process restart, a segmentation fault, an out-of-memory kill in the system log (dmesg or journalctl -k), or an application error that crashed the request mid-response. If the app logs show nothing unusual at all, the problem is more likely a response that technically completed but broke an HTTP rule, such as an oversized header.

What causes error 520

• The origin process crashed or restarted while handling the request. The connection closes before a complete response goes out. This is the most common cause.
• The origin reset the TCP connection (RST) instead of closing it cleanly. Application servers under memory pressure or hitting a worker timeout often do this.
• Response headers over Cloudflare's 16 KB limit. A large set-cookie header, a stack of debug headers, or verbose CORS headers can push the total past what Cloudflare will accept.
• A cookie or combined cookie header too large. Session data, tracking cookies, or a misconfigured cookie jar can grow past browser and proxy limits over time.
• A missing or malformed status line. Some frameworks return a raw error string instead of a proper HTTP response when an unhandled exception reaches the web server layer.
• The origin returned non-HTTP data on the HTTP(S) port. This happens after a misconfigured reverse proxy, a wrong port mapping, or a service that binds the port before the real web server does.
• A security appliance or WAF in front of the origin killed the connection mid-response. Some on-premise WAFs and load balancers terminate connections that trip a rule, which looks identical to a crash from Cloudflare's side.

How to tell whose fault it is

Since Cloudflare did get a response from the origin, error 520 is a strong signal that the problem is on the origin's side rather than in Cloudflare's network, unlike error 521 or 522 where the connection itself failed. The open question is usually whether it affects every visitor or only some.

The fastest way to split that is to run an HTTP check from several locations at once. If a check against the public domain fails from every location at the same time users are reporting the error, the origin itself is down or crashing for everyone, not just one edge data center. If it only fails intermittently or from specific regions, the origin may be overloaded under load from that region, or a caching or load-balancing layer only present in part of your setup is involved. HostTracker's HTTP check runs from checkpoints in multiple countries and reports each one's result separately, which is the detail a single curl from your own desk cannot give you.

You can also isolate the origin from Cloudflare entirely by dialing it directly with the domain's Host header, bypassing the edge network so any error you see is unquestionably the origin's:

curl -v -H "Host: example.com" https://ORIGIN_IP/

Replace ORIGIN_IP with your server's real IP address. If this direct request also fails or returns the same broken response, the fault is confirmed at the origin.

How to fix error 520

If you are a visitor

1. Reload the page after a minute or two. Many 520 errors come from a brief crash or restart that the site's own process supervisor recovers from automatically.
2. Try a private or incognito window, or a different network. This rules out a stale local cache or a misbehaving browser extension, though a 520 is rarely caused by anything on your end.
3. Check whether the site publishes its own status page, if it has one, for a known outage.
4. There is nothing to configure on your side to fix a 520. It is generated by the site's own server, not by your browser, your ISP, or your DNS resolver.

If you run the site

1. Check the origin's web server and application logs for the exact timestamp of the failures, looking for a crash, an unhandled exception, or a worker restart.
2. Bypass Cloudflare and query the origin directly with the Host header (shown above), or use Cloudflare's "Pause Cloudflare on Site" option, to confirm the response is broken independent of the proxy.
3. Measure the size of your response headers and cookies. A single large set-cookie header or a pile of debug headers left on in production can push the total over 16 KB; trim what you do not need and move large session data server-side.
4. Check for malformed responses: a reverse proxy or load balancer pointed at the wrong upstream, an app returning plain text on an HTTP port, or a missing status line from a framework's default error handler.
5. Check for resource exhaustion on the origin: memory limits, connection pool limits, or a process manager (systemd, pm2, a Gunicorn or uWSGI worker pool) stuck in a restart loop.
6. If a WAF, antivirus proxy, or load balancer sits between the internet and your application server, check its own logs for connections it dropped or reset around the same time.

How to prevent it

Error 520 usually shows up first as a support ticket, not as an alert, because nothing at the origin necessarily logs a failed handshake with Cloudflare's edge the way it logs an application exception. An external availability check that runs from outside your own network catches the same failure a visitor sees, from the same vantage point, before someone has to report it. Running the check from multiple countries also shows immediately whether a 520 is global or limited to one region, which is the detail that decides where you start debugging.

Related errors

• Cloudflare error 521: web server is down - the origin refused the connection instead of responding.
• Cloudflare error 522: connection timed out - the TCP handshake to the origin never completed.
• 5xx server errors - the general status code family.
• 502 Bad Gateway - the non-Cloudflare-specific version of an invalid upstream response.

Frequently asked questions

Is error 520 Cloudflare's fault or mine?

Almost always the origin's. Cloudflare received a response and could not make sense of it or pass it on, which means the origin server, not Cloudflare's network, produced the broken response.

Does error 520 mean my whole site is down?

Not necessarily. It means the specific request that triggered it failed. If the origin is crashing under load, it may serve 520 to some requests and normal responses to others until the underlying issue is fixed.

Can I fix error 520 from the Cloudflare dashboard alone?

Rarely. Since the cause is almost always on the origin, dashboard settings will not fix a crashing application or an oversized response header. The exception is verifying your SSL/TLS mode and origin settings match what your server actually does, which at least rules out a Cloudflare-side misconfiguration.

What is the difference between error 520 and a plain 502 Bad Gateway?

502 is the general HTTP status for an invalid response from an upstream server, used by any reverse proxy. Cloudflare uses 520 specifically as its own catch-all for a response so broken it does not fit any of Cloudflare's other named 5xx codes, which is why the Cloudflare error page and Ray ID appear instead of a generic 502 page.

Can a large cookie really cause a 520?

Yes. Cloudflare enforces a limit on total response header size, currently around 16 KB, and cookies count toward that. An application that keeps appending to a session cookie, or that sets several large cookies at once, can cross that limit and trigger a 520 even when the application itself has no bug.

Will retrying the request fix it?

Sometimes, if the cause was a transient crash or restart on the origin that has already recovered. If the origin is consistently sending broken responses, for example because of an oversized header on every request, retrying will not help until the origin is fixed.