Error 520 may be due to multiple causes.  Learn how to identify the causes and troubleshoot this error.


Error 520 is essentially a catch-all response when something unexpected happens or when the origin

server incorrectly interprets or does not tolerate a request due to a protocol violation or an empty response.



Cloudflare Error 520


If Always Online is enabled on your site, this status code will trigger an Always Online page to be served.

Common causes

While it can be triggered by unique or strange edge-case scenarios, Error 520 is commonly caused by:

  • Connection resets after a successful TCP handshake
  • Headers that exceed Cloudflare’s header size limit (8kb)
  • An empty response from the origin server
  • An invalid HTTP response
  • An HTTP response without response headers


If you can confirm that any of the conditions above come from the origin web server hosting the site, we recommend consulting with the host provider or administrator for assistance with web server configuration to avoid further interruption and errors.  


This type of error generally occurs at the application layer (OSI layer 7). This means that it results from a bad response coming back from the application.


Cloudflare Rate Limiting rules or other filtering requests (e.g., by connecting IP or volume/frequency) may sometimes cause issues with your application. It is important to review and test these aspects of your overall configuration. Also, be sure to allowlist Cloudflare's IPs in the origin server. See a list of Cloudflare IP ranges.

Troubleshoot Error 520

Due to the nature of an Error 520 response, it is best to test against the origin web server.  You can use cURL and generate HTTP Archive files (HAR) as described below.


Use a cURL command

With cURL, you confirm if any of the conditions outlined above have triggered the error. This is especially true to determine if the origin server is returning an empty reply, invalid HTTP response, or extremely large response headers.


Below is an example command used to force the Host HTTP header while sending the request to the source IP address where the domain is hosted. In this example, we are sending a request for a login page:

curl -vso /dev/null --user-agent "Mozilla 5.0" -H "Host: example.com" http://123.123.123.321/login


Below is an example output where the origin response with an empty reply, which would normally trigger a 520 error if the request was proxied by Cloudflare:

* Hostname was NOT found in DNS cache
*   Trying 123.123.123.321...
* Connected to 123.123.123.321 (123.123.123.321) port 80 (#0)
> GET /login HTTP/1.1
> User-Agent: Mozilla 5.0
> Accept: */*
> Host: example.com
>
* Empty reply from server
* Connection #0 to host 123.123.123.321 left intact


A successful response header might look something like this:

* Hostname was NOT found in DNS cache
*   Trying 123.123.123.321...
* Connected to 123.123.123.321 (123.123.123.321) port 80 (#0)
> GET /login HTTP/1.1
> User-Agent: Mozilla 5.0
> Accept: */*
> Host: example.com
>
< HTTP/1.1 200 OK
< Content-Type: text/html
< Date: Day, DD, Month Year Hour:Minute:Second Timezone
{ [14240 bytes data]
* Connection #0 to host 123.123.123.321 left intact


Generate an HAR file

Another troubleshooting task is to generate an HTTP Archive file (HAR) for a request going both direct to the origin web server and through Cloudflare.  See How do I generate a HAR file?


HAR files are useful for comparing the response headers coming from the origin server and from Cloudflare as the proxy; for example, to confirm if the response header is too large. 

Need additional help?

If the problem persists after following the troubleshooting advice above, you can file a support ticket and include the following information:

  • The steps to reproduce the error
  • HAR files for both direct origin and Cloudflare-proxied requests
  • rayIDs from errors seen