Get faster and more secure web presence in China. Join the webinar to learn how to address China's Internet challenges - Dec. 13 at 10am PT.

Error 520: Web server is returning an unknown error

error520.png

Overview

The 520 error is essentially a “catch-all” response for when the origin server returns something unexpected or something that is not tolerated/interpreted (protocol violation or empty response).

While the 520 error can be triggered by very unique and strange edge-case scenarios, they are generally caused by:

  • Connection resets (following a successful TCP handshake)
  • Headers exceed CloudFlare’s header size limit (over 8kb)
  • Empty response from origin
  • Invalid HTTP response
  • HTTP response missing response headers

 If any of these conditions above can be confirmed from the webserver hosting the site, then it is recommended to consult with the host provider for assistance with the webserver configuration to avoid further interruption and errors.  

Common Causes

520 errors are generally caused at Layer 7, which is the Application Layer. This means that a 520 error is the result of a bad response coming back from the application. Rate limiting, or filtering requests (e.g. by connecting IP, or volume/frequency) can sometime cause issues with your application.

Troubleshooting

Due to the nature of the 520 response, it is best to test against the origin server response using a cURL command to confirm if any conditions have been met to trigger the error. This especially true to determine if the origin server is returning an empty reply, invalid HTTP response, or extremely large response headers.

Here is an example command used to force the Host HTTP header while sending the request to the source IP 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

Here is an example output where the origin response is 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 good 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

Because rate limiting can also cause this issue, you will want to whitelist our IPs. A list of CloudFlare IP ranges can be found here.

Another effective troubleshooting step would be to obtain an HAR (HTTP Archive File) for a request direct to origin and through CloudFlare from an impacted user. HAR files provide a useful source of information to compare the response headers from origin, and while CF is proxying the request (useful to confirm if header response are too large). 

When submitting a support ticket, please provide:

  • steps to reproduce the error
  • HAR files
  • rayIDs from errors seen
Still not finding what you need?

The CloudFlare team is here to help. 95% of questions can be answered using the search tool, but if you can’t find what you need, submit a support request.

Powered by Zendesk