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
- 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.
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://22.214.171.1241/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 126.96.36.1991...
* Connected to 188.8.131.521 (184.108.40.2061) 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 220.127.116.111 left intact
Typically, connection resets following a TCP handshake are also a common cause of a 520 error. Given that any Layer 7 based security can cause a 520 to trigger, especially if rules are in place that filter/limit specific request/client parameters (such as connecting IP, or volume/frequency).
Checking security applications at the host network and requesting webserver access/error logs are key in troubleshooting 520 errors if connection resets are occurring for requests. Verifying that CloudFlare IP ranges are whitelisted will also help in preventing these types of connection resets from occurring in the future.
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