Error guide

520 Web Server Returns an Unknown Error

Cloudflare reached your origin and got back a response it could not use: empty, malformed or cut off.

520 is Cloudflare's catch-all for an origin response it could not use. Cloudflare connected to your origin and sent the request, and what came back was empty, cut off by a reset, or not a valid HTTP response. It is not a standard HTTP code: Cloudflare's edge generates it and writes the error page itself.

It tells you less than 521, 522 or 523, because the part that usually fails worked. The connection opened and the request went out; the response is what went wrong. The common shapes are an application process that crashed or was killed mid-request, a firewall or security plugin resetting Cloudflare's connections, and response headers Cloudflare will not accept.

The header case is the one that surprises people. Cloudflare refuses a response whose headers exceed 128 KB, and headers can grow that large through accumulated cookies or verbose debug headers without the application changing at all. That is why a 520 can hit one page, or one visitor with a large cookie jar, while the rest of the site loads normally.

Common causes

  • The application process crashing, restarting or being killed partway through a request.
  • A firewall, security plugin or intrusion prevention system resetting connections from Cloudflare's IP ranges.
  • Response headers larger than Cloudflare's 128 KB limit, often from accumulated cookies.
  • An application returning an empty or malformed response instead of valid HTTP.
  • HTTP/2 to origin enabled in Cloudflare while the origin's own HTTP/2 support is broken.

How to diagnose it

  1. Establish whether every request fails or only some: all of them points at the server, one page or one visitor points at that response.
  2. Read the origin's error log and the process supervisor's restart history for crashes at the times of the errors.
  3. Request the failing URL from the origin directly, bypassing Cloudflare, and check whether a complete response arrives and how large its headers are.
  4. Review firewall and security plugin rules for anything that resets or blocks Cloudflare's IP ranges.
  5. If HTTP/2 to origin was recently turned on, turn it off and retest.

Whose fault is it? The server's side

Origin-side in nearly every case. Cloudflare writes the error page, but it is reporting what your origin sent back: an empty answer, a reset connection or headers it will not accept.

What monitoring sees

A monitor on the public hostname receives the 520 as an HTTP response. By default Uptimely's check passes only on a status from 200 to 399, so it fails, and the code is recorded with the check. The code alone will not name which cause it is. If the origin accepts connections from outside Cloudflare, a second monitor on the origin directly narrows it: an origin check that passes while the edge check fails points at something only Cloudflare's requests trigger.

Related error guides

Terms used on this page

Questions

What causes a Cloudflare 520 error?

Something on the origin side returned a response Cloudflare could not use. The usual causes are an application that crashed mid-request, a firewall or security plugin resetting Cloudflare's connections, and response headers over Cloudflare's 128 KB limit.

Is a 520 error Cloudflare's fault?

Almost never. Cloudflare generates the page, but it is reporting what your origin sent back. Requesting the same URL from the origin directly shows whether it misbehaves for everyone or only for requests arriving through Cloudflare.

One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.