Cloudflare Error 520: Web Server Returning an Unknown Error

A 520 is Cloudflare's catch-all. It connected to your origin server fine, but the response that came back was empty, malformed, or otherwise unreadable. The server isn't down; it's answering, just not coherently.

Whose fault is it

A 520 is generated at Cloudflare's edge, but the trigger is on your side. Cloudflare reached your server and got a reply it couldn't make sense of. That rules out DNS failures, total outages, and routing problems (those produce other codes) and points you straight at the application layer.

What a 520 actually means

When someone visits a Cloudflare-proxied site, the request goes to Cloudflare first, which forwards it to your origin and relays the response back. A 520 means that relay broke: Cloudflare made the connection, sent the request, and your server started to answer, but what it sent back was something Cloudflare can't parse into a valid HTTP response. Empty body where there should be content. Headers that don't conform. A connection that died halfway through writing the reply.

This is why 520 is the most annoying code in the family to debug. The others tell you something specific (521 is a refused connection, 522 is a failed handshake, 525 is an SSL problem). A 520 just says "the answer made no sense," which could come from a dozen different places.

The common causes, most likely first

1. The web application crashed mid-response This is the single most frequent cause. Your server starts building the response, begins sending headers, then something interrupts it: an unhandled exception, a process running out of memory, a script that dies partway through. Cloudflare receives a partial or empty response and rejects it. Check your application error log (PHP-FPM, your Node process, your Python WSGI worker) at the timestamp of the error.
2. Response headers exceed 16 KB Cloudflare enforces a hard 16 KB limit on total HTTP response header size. Oversized cookies, a pile of security headers, bloated session tokens, and third-party tracking headers all add up. Cross the limit and Cloudflare drops the whole response. Run curl -sI https://your-origin-ip/ -H "Host: yourdomain.com" against the origin directly and add up the header bytes.
3. A firewall or security rule is mangling the response Your origin's firewall, a security plugin, or a .htaccess rule can corrupt or truncate responses to certain requests. Temporarily disable .htaccess (rename it) and retest. If the 520 clears, reintroduce rules one block at a time to find the culprit.
4. An empty reply with no body Some misconfigurations cause the server to close the connection after sending status and headers but before sending any body. To Cloudflare that's an unknown error. This often traces back to a reverse proxy in front of your app (an Nginx or HAProxy layer) that's timing out or misrouting.

How to diagnose it

Work from the origin outward. The goal is to reproduce the bad response without Cloudflare in the path, which tells you immediately whether the problem is your server or the Cloudflare-to-origin link.

1. Pull your origin IP from the Cloudflare DNS settings, then hit it directly: curl -v --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com/. If you get the same broken response, the problem is purely your server and Cloudflare is just reporting it.
2. Tail your application and web server error logs while you reproduce the request. A crash, an out-of-memory kill, or a segfault will show up here with a matching timestamp.
3. Inspect the response headers for size with curl -sI and confirm nothing is near 16 KB.
4. If the origin responds cleanly when hit directly but Cloudflare still shows 520, the issue is in the relay: an intermittent crash under Cloudflare's specific request pattern, or KeepAlive behavior. Check whether the crash correlates with concurrency.

Does a 520 hurt your SEO

Yes, if it persists. Search engines treat 5xx responses as server errors. Frequent 520s waste crawl budget, push up bounce rates from people landing on error pages, and slow the indexing of new content. Google crawls a site that returns reliable responses more aggressively than one that intermittently errors. A one-off 520 from a transient crash is harmless; a recurring one is a ranking problem.