The 520 error code means Cloudflare usually receives an empty or invalid response from your website’s origin server.
The first time a visitor hits a white page with “Web server is returning an unknown error,” it can feel like everything just broke at once. If your site runs behind Cloudflare, that message usually maps to a 520 status, a catch-all signal that something between Cloudflare and your origin server went wrong.
This guide walks you through what this status actually means, how it differs from other 5xx responses, what tends to cause it, and the step-by-step checks that help you clear it fast and keep it from coming back.
What Is The 520 Error Code?
In Cloudflare’s world, the 520 error code is a generic server-side problem. Cloudflare forwards a visitor’s request to your origin server, expects a standard HTTP response, and instead gets something empty, malformed, or unexpected. Because the reply does not match a normal status code, Cloudflare wraps it in a 520 and shows that to the user.
The response still sits in the 5xx family, which means it points to the server side instead of the visitor’s browser or connection. Clearing cache in the browser or switching Wi-Fi usually does nothing for a real 520. The root cause almost always lives on the origin server, in hosting, or in the way Cloudflare sits in front of that server.
Cloudflare’s own dashboards describe 520 as “Web server is returning an unknown error.” In plain terms, the proxy asked the origin for a page, the origin replied in a way that did not make sense, so Cloudflare fell back to this generic status.
Handling 520 Website Error Code On Cloudflare
For visitors, the page looks like a Cloudflare error, so the first instinct is to blame the proxy. For site owners, that can send you on a wild chase through account settings while the real issue sits inside your hosting panel. In most cases, the proxy only passes along the symptom of the underlying server problem.
To keep your response calm and effective, treat a 520 as a signal that you need to test two channels: how Cloudflare sees your site, and how the origin server behaves when Cloudflare is out of the way. Once you have that split view, each common symptom maps neatly to a likely cause.
| What You See | Likely Cause | Where To Fix It |
|---|---|---|
| 520 only when Cloudflare proxy is on | Firewall or security tool blocking Cloudflare IPs | Origin server firewall or security plugin |
| Random 520s under load or traffic spikes | Origin server resource limits or crashes | Hosting plan, PHP limits, database tuning |
| 520 after recent config change | Bad .htaccess rule, plugin, or app update | Application code or .htaccess in document root |
| 520 plus a long wait before error | Slow backend response or timeout | Origin performance, long-running scripts |
| 520 only on some URLs or users | Oversized headers, many cookies, or WAF rules | App configuration, HTTP headers, Cloudflare rules |
Common Causes Between Cloudflare And The Origin Server
Most 520 responses trace back to a handful of patterns. You rarely need exotic debugging; you need a clear way to test each layer, cross-check logs, and rule out guesses.
Origin Server Resource Limits
Shared hosting and small virtual servers run within strict memory, CPU, and process limits. When PHP workers, database connections, or web server threads run out, the origin may return an empty reply, crash mid-response, or restart. Cloudflare then sees a broken or missing HTTP message and wraps it as a 520.
Watch for clues such as slow admin pages, frequent 500 or 502 codes in server logs, or panels that show CPU pegged at 100%. In that state the fix might be as simple as reducing heavy plugins, raising PHP max_execution_time, or moving to a plan with more consistent resources.
Firewall Or Security Rules Blocking Cloudflare
Many hosting firewalls flag Cloudflare’s IP ranges as suspicious bulk traffic if they are not whitelisted. Tools such as mod_security, fail2ban, or WordPress security plugins can block or throttle those IP ranges, especially when you see many requests from the same subnet.
When that happens, Cloudflare’s data center reaches out, the origin blocks or drops the connection, and the proxy reports a 520. The cure is to import the latest Cloudflare IP ranges into your firewall allow list and adjust automated rules so that legitimate proxied requests are not treated as abuse.
Invalid Or Oversized HTTP Headers
Some sites send big cookies, long custom headers, or debugging information with every request. HTTP headers that exceed Cloudflare’s limits, or contain malformed characters, can lead to broken responses that do not parse cleanly.
Browser developer tools or a captured HAR file reveal this pattern. Look for many cookies, repeated user tracking data, or header values that run far longer than typical. Trimming unused cookies, reducing debug output, or adjusting application code so it sends leaner headers often stops repeat 520 responses on specific paths.
Faulty .htaccess Or Application Code
A single misplaced directive in .htaccess, an endless redirect loop, or a fatal error in a plugin can leave the origin server sending either no data or a half-finished response. To Cloudflare that looks like an unknown error and triggers the generic status.
Rolling back the last plugin install, theme change, or code deployment is one of the fastest ways to test for this. If the error clears the moment you revert, review that change carefully before rolling it out again. A staging environment that mirrors Cloudflare’s setup helps you catch these problems before they reach real visitors.
How Site Owners Can Fix A 520 Response
Once you understand that a 520 connects to origin behavior, the fix turns into a checklist. Work through the steps in order, and you usually land on the cause without guesswork.
- Bypass The Proxy Temporarily — In the DNS tab, switch the orange cloud to gray for the affected record, or use Cloudflare’s development mode. This routes traffic directly to the origin so you can see the raw response without the proxy layer.
- Inspect Server Error Logs — Open the error log in your hosting panel or on the server itself. Look for PHP fatal errors, segmentation faults, or repeated restarts that line up with the timestamps when 520 responses appeared.
- Review Firewall And Security Tools — Check web application firewalls, rate-limit tools, and security plugins. Make sure Cloudflare IP ranges are whitelisted and that no rule is blocking or challenging them in bulk.
- Verify DNS And SSL Settings — Confirm that the DNS records in Cloudflare point to the correct origin IPs and that SSL mode matches your certificate setup. Mixed or outdated settings can cause handshake problems that look like unknown errors.
- Roll Back Recent Changes — Disable new plugins, revert rules in .htaccess, or undo recent deployment steps one by one. After each change, reload the affected page to see whether the 520 disappears.
- Contact Your Hosting Provider With Details — If the issue persists, open a ticket with timestamp samples, affected URLs, and any error log entries you captured. Hosting support can match those times against resource spikes or network issues on their side.
Quick Checks For Visitors Seeing A 520
If you are browsing a site and run into a 520, you have less direct control, but a few quick checks still help confirm where the problem lives.
- Refresh The Page Once Or Twice — Short network blips between Cloudflare and the origin sometimes clear on a second try, especially during brief host restarts.
- Try Another Browser Or Device — Switching to a different browser or phone confirms whether a local extension or cache is involved, while 520s rarely start in the client.
- Use An External Status Checker — Tools that fetch the site from several regions show whether others also receive a 520 status or if the issue sits only on your side.
- Contact The Site Owner — If the site belongs to your team or a partner, send a quick note with the time, URL, and a screenshot. That gives the owner enough detail to match against logs.
Beyond those steps, visitors mostly need to wait while the site owner and hosting provider repair the upstream fault. Because the 520 sits in the 5xx range, retrying too often rarely helps and can even add more pressure to an already busy origin.
Preventing Future 520 Responses With Simple Hygiene
Once a 520 is gone, it is tempting to move on and forget about it. A short review of your setup pays off later by turning one noisy outage into a learning moment instead of a pattern.
- Monitor Server Health Regularly — Keep an eye on CPU, memory usage, and disk space in your hosting panel so you can upgrade or tune limits before traffic peaks.
- Keep Software Lean And Updated — Remove unused plugins or modules, apply patches on a schedule, and test updates in staging before you push them live.
- Limit Cookie And Header Size — Avoid stuffing many values into cookies or custom headers; store long tracking data server-side when possible.
- Whitelist Cloudflare IP Ranges — Refresh the IP list in your firewall or security tools so proxy traffic never looks like a brute-force attack.
- Use Caching Wisely — Combine Cloudflare caching rules with application-level caching to reduce load on the origin and keep responses quick.
Small steps like these raise the odds that even traffic spikes or brief host issues only cause a soft slowdown instead of a full 520 error response across your site.
When To Contact Hosting Or Cloudflare Support
Most 520 problems come down to server resources, configuration, or security rules, and those clear once you walk through the checklist above. There are times, though, when extra eyes from hosting or Cloudflare support save you hours of guesswork.
Reach out when you see frequent 520 responses across many visitors, the problem jumps between different pages with no clear pattern, or you suspect a deeper network issue inside the data center. Attach screenshots, HAR files, and time ranges so the support team can trace the path of the request.
During that conversation, ask whether they see crashes, packet drops, or blocked connections that line up with your reports. Joint visibility between your monitoring tools, server logs, and Cloudflare’s network view gives the cleanest answer.
Once you reach that shared picture, the phrase “520 error code” turns from a vague red banner into a clear signal: a clear reminder to check the origin first, confirm how Cloudflare reaches it, and keep both layers tidy so visitors simply see the page they came for.