520 Web Server Returns an Unknown Error

Cloudflare uses 520 as its catch-all: the TCP connection to the origin worked, but what came back was not a valid HTTP response it could forward. Cloudflare lists origin crashes, firewalls or security plugins that cut Cloudflare off mid-stream, response headers over 128 KB (often from piling up cookies), responses missing a status line, a broken HTTP/2 setup at the origin, and Authenticated Origin Pull enabled without the origin configured to accept the client certificate.

Because the category is so broad, the useful first step is to reproduce the request against the origin directly. If curl to the origin IP gets a normal response, compare headers and protocol; if it gets "Empty reply from server" or a reset, the problem is inside your server.

If you are visiting the site

• The website’s own server is failing behind Cloudflare. Your browser, network and Cloudflare are working; the page will show that the host is the part in error.

If you run the server

• The application process (PHP-FPM, Node, Gunicorn) crashed or was killed by the OOM killer while writing the response.
• Response headers above 128 KB, typically a Set-Cookie loop or a huge CSP or session cookie.
• The origin advertises HTTP/2 through ALPN but does not actually handle it correctly.
• A security plugin or firewall resets connections from Cloudflare IPs after they start.

If you are visiting the site

• Wait a minute and reload. If it persists, contact the site owner and include the Ray ID from the bottom of the error page.

If you run the server

• Request the page from the origin directly (curl --resolve, below) and read the application and web server error logs at the timestamps of the 520s.
• Measure the response header size; trim cookies and oversized headers below 128 KB.
• If the origin speaks HTTP/2, test it, or turn off HTTP/2 to Origin in the Cloudflare dashboard (Speed, Protocol Optimization) to confirm.
• Check that no firewall rule or plugin rate limits or resets Cloudflare IP ranges.

Cloudflare generates this code at its edge when it cannot get a usable answer from your origin; your server never sends it. The commands below talk to the origin directly, skipping Cloudflare, so you can see what Cloudflare sees.

# Hit the origin directly, skipping Cloudflare (replace ORIGIN_IP)
curl -sv -o /dev/null --resolve example.com:443:ORIGIN_IP https://example.com/page

# Size of the response headers in bytes (Cloudflare's limit is 128 KB)
curl -s -D - -o /dev/null --resolve example.com:443:ORIGIN_IP https://example.com/page | wc -c

# Same request forcing HTTP/2 to the origin
curl -sv --http2 -o /dev/null --resolve example.com:443:ORIGIN_IP https://example.com/page

520 vs 502

502 is a generic invalid-response-from-upstream error from any gateway; 520 is Cloudflare’s own label for the same situation when the upstream is your origin and the response was empty or unrecognizable.

520 vs 521

With 521 the origin refused the connection outright; with 520 it accepted the connection and then sent back something unusable.

Is error 520 Cloudflare’s fault?

Almost never. Cloudflare reached your origin and got back a response it could not use. The fix is on the origin: logs, header size, HTTP/2 or firewall.

What is the header size limit that causes 520?

Cloudflare documents 128 KB for response headers. Sites usually hit it through many or very large Set-Cookie headers.

Why does error 520 happen only on some pages?

Page-specific 520s usually mean that route crashes the app, sets unusually large cookies or headers, or takes a code path that closes the connection early. Reproduce that exact URL against the origin.

What should I send Cloudflare support about a 520?

The full URL, the Ray ID from the error page, the output of /cdn-cgi/trace on your domain, and two HAR files: one with Cloudflare enabled and one with it paused.