A 520 error means a CDN reached your origin server but got an empty or invalid reply, usually due to server crashes or misconfiguration.
What Error Code 520 Actually Means
When visitors see a error 520 in the browser, they are seeing a message from a content delivery network such as Cloudflare. The CDN sits between the visitor and your origin, so the error tells you that the edge tried to talk to the origin but did not receive a normal HTTP response.
The origin server either returned no data, stopped the connection too early, or sent something that does not follow HTTP rules. Because the message is unclear, the CDN falls back to the generic error 520 code and shows “web server is returning an unknown error.” The code sits in the same broad group as other 5xx responses, which all signal problems on the server side, not in the visitor’s browser.
This error code is specific to Cloudflare and a few similar tools, so you will not see it in the official HTTP status list. Other providers often send a plain 500 error instead. The practical meaning is the same: your origin did something unexpected, and fixing the problem requires work on that side of the connection.
From a technical view, the main detail is that the CDN did reach your server. A classic timeout such as 522 means no full reply arrived in time, while a plain 500 hints at a crash inside the app. With error 520, the origin did send something back, yet the reply broke HTTP rules or arrived in a half finished state, so the edge has no choice except to raise this catch all message.
How 520 Differs From Related Errors
Cloudflare and similar tools use several custom codes that sit near 520. Telling them apart helps you pick the right repair plan for what your logs show.
- Error 521 — The origin refuses connections, often because a firewall blocks the CDN or closes ports too early.
- Error 522 — The CDN can reach the origin host, but the reply takes too long and the connection times out.
- Error 524 — The TCP link works, yet the origin spends so long on a reply that the edge gives up and breaks the session.
Symptoms You See When Error Code 520 Hits
A error 520 can appear in a few different ways. The browser might show the Cloudflare badge with a short message, or you might only see a plain text line that names the error code. Site owners often receive messages from visitors who report that “the site works sometimes and then suddenly shows error 520.”
Because the origin server sometimes responds correctly, the error can be hard to pin down. You might notice patterns such as more failures during traffic spikes, after a new plugin install, or during long running batch jobs on the server. Requests that send many cookies or custom headers can also fail more often than simple page loads.
On the operations side, you may see matching entries in server logs. These often show aborted requests, PHP or application crashes, memory errors, or firewall entries that mention Cloudflare IP ranges. When these server side clues line up with the times visitors saw a error 520, you know you are looking in the right place.
For a visitor, these symptoms show up as random slow pages and failed form posts. For you as the owner, they raise the risk of lost orders, broken signups, and search crawlers backing off. Treat every cluster of 520 style errors as a chance to harden the site, even if people can still load some pages in between.
Common Triggers Behind Error Code 520
The 520 label can seem vague, the underlying reasons tend to fall into a handful of patterns. Understanding where the problem starts will help you pick the right fix instead of guessing at random changes.
| Trigger | Where It Lives | Typical Clue |
|---|---|---|
| Origin crashes or restarts | Web server or app runtime | Spike of 5xx codes, gaps in logs |
| Firewall blocks CDN traffic | Host firewall or security plugin | Log entries that list CDN IP ranges |
| Oversized headers or cookies | Browser, app, or HTTP proxy | Large cookie strings, long header values |
| SSL or HTTP misconfiguration | Origin virtual host or control panel | Handshake errors or protocol warnings |
| Network drops between CDN and origin | Hosting network layer | Short outages, random connection resets |
Many articles group all of these together as “server issues,” which is true but not much help when you want a fast answer. By tying every error 520 you see to one of these buckets, you can work through checks in a steady order and stop once the site is stable.
Once you spot which row of the table fits your own data, narrow your work to that layer. A spike of process restarts points toward PHP or database settings, while repeated firewall hits that name Cloudflare IP ranges signal security rules. Keeping this short map nearby stops you from randomly changing DNS, cache, and code all at once.
520 Error Troubleshooting Steps That Work
This section walks through concrete steps you can take as a site owner or admin when a 520 error starts to appear. Start with the quick client side checks, then move to the origin and hosting layer.
- Refresh the page — Ask the visitor to reload once or twice. Short network blips or cached cookies sometimes clear on a fresh request.
- Test from another network — Have someone try the site from a mobile connection or a remote location to see if the error 520 is local to one provider.
- Bypass the CDN — Point a hosts file entry or temporary DNS record directly at the origin IP to see whether the origin responds correctly without Cloudflare in the path.
- Check origin logs — Check recent web server and application logs at the times error 520 responses occurred. Crashes, timeouts, or memory limits here usually point to the cause.
- Review recent changes — Turn off new plugins, modules, or code pushes that went live shortly before the error appeared, then test again.
- Trim headers and cookies — Clear cookies in the browser, reduce debug headers, and avoid sending large custom values that might push header size over Cloudflare limits.
If the error disappears when you bypass the CDN but returns as soon as you switch it back on, pay attention to how the origin behaves when requests come from Cloudflare IP ranges. Some firewalls treat these as suspicious, or rate limits might be too strict for a busy site.
Server-Side Changes To Prevent Error Code 520
Lasting fixes for a 520 error almost always live on the origin server. The goal is simple: send clear, standards based HTTP responses to the CDN on every request, even when your app fails. That way Cloudflare can either cache a valid response or return a more specific error code.
- Harden application stability — Patch your CMS or platform, remove outdated plugins, and add basic health checks so you see crashes before visitors do.
- Tune PHP and web server limits — Raise memory and execution time settings to match real traffic, then watch metrics to confirm that the origin no longer hits hard limits.
- Whitelist CDN IP ranges — Add the official Cloudflare IP ranges to server and host firewalls so that reverse proxy traffic is never blocked by mistake.
- Serve friendly error pages — Configure the origin to send custom 5xx pages instead of dropping connections. Even a simple HTML page is better than an empty response.
- Monitor header size — Keep cookies lean, clean up debug headers, and avoid packing session data into custom HTTP headers.
Along with these steps, make sure TLS settings and certificate chains on the origin line up with the mode you selected in the CDN dashboard. Mixed SSL modes or half migrated certificates can confuse both ends and push the request toward a generic error 520 result.
When Network And DNS Settings Feed This Error
Beyond pure server tuning, network and DNS settings can fuel a error 520, especially on new sites or fresh migrations. Cloudflare needs to know exactly which IP or hostname to reach, and every hop between the CDN and the origin has to allow that traffic.
- Verify DNS records — Confirm that A and CNAME records in the CDN panel match the real origin IPs. Old entries that point to retired servers often lead to intermittent 5xx responses.
- Check rate limits — Review any host side rate limiting tools that might see Cloudflare as a flood of single IPs and start blocking them.
- Test from the origin outward — Use curl or a similar tool on the origin server to load your own site through Cloudflare and watch for TLS or routing errors.
- Watch for brief network drops — Ask your host whether they see short outages on the link from their network to Cloudflare, and match any notes to your 520 error times.
DNS and routing fixes often take a little time to settle. During that window you might still see some error 520 responses while cached routes and resolver entries update around the internet.
Staying Ahead Of This Error Code
Once you have cleared the current 520 error, treat the incident as a signal to tighten your monitoring and change habits. The least pleasant time to learn about server stress or bad plugins is when your front page is already down.
- Track uptime and 5xx rates — Add a simple external monitor that pings your site through Cloudflare and alerts you when error rates rise.
- Log and review incidents — Keep short notes on what triggered each 520 error and how you fixed it so repeat cases are faster to handle.
- Plan safe change windows — Roll out big plugin updates, PHP bumps, or new code during quiet periods with someone ready to roll back.
- Keep host contacts handy — Store emergency numbers or chat links for your hosting provider so you can reach a technician when logs or graphs look wrong.
With these habits in place, a 520 error turns from a confusing message into a manageable incident. You know where to look, who to involve, and which levers to pull so visitors see your site again with minimal delay.
A short runbook helps as well. List which dashboards to open, how to switch the CDN to DNS only for tests, and who can restart services on the origin. When the next spike arrives, those notes keep the response calm, steady, and predictable.
