Overview the 520 ERROR
Think of the 520 error as a bit of a "catch-all." It basically happens when the origin server sends back something weird—something the system just doesn't know how to deal with, like a protocol violation or a totally empty response.
While you can run into some pretty bizarre edge cases, most of the time it boils down to a few common culprits:
Connections getting reset right after a successful TCP handshake
Headers hitting the Akamai limit (anything over 8kb)
The origin server sending nothing back
An invalid HTTP response
An HTTP response that's missing its headers entirely
If you can pin down one of these issues on your actual webserver, your best bet is to reach out to your hosting provider. They can help tweak the server config so things stop breaking.
Common Causes 520
These errors usually live at Layer 7—the Application Layer. In plain English, that means the app itself is spitting out a bad response. Sometimes, things like rate limiting or aggressive request filtering (like blocking certain IPs or high-volume traffic) can trip this up.
Troubleshooting due to the nature of the 520 response
Since the 520 is such a vague error, I'd suggest testing the origin server directly. Using a cURL command is a solid way to see if the server is actually sending back an empty reply, a messed-up HTTP response, or headers that are just way too massive.
Here’s a quick example of how to force the Host HTTP header when hitting the source IP where the domain lives (I'm using a login page for this example):
curl -vso /dev/null --user-agent "Mozilla 5.0" -H "Host: example.com"
http://123.123.123.321/loginCheck out this example output where the origin gives an empty reply. If this were being proxied by Akamai, it'd trigger that 520 error immediately:
* 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
On the flip side, a healthy header should look more 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
Since rate limiting can be a factor, make sure you've whitelisted our IP ranges. You can grab the full list here.
Another move is to grab an HAR (HTTP Archive File) from a user who's actually seeing the error. Comparing a request made directly to the origin versus one going through the proxy is super helpful for seeing if those headers are getting too bloated.
If you end up opening a support ticket, try to include:
The exact steps to recreate the error
Any HAR files you've collected
The Request IDs from the errors you're seeing
