Cloudflare Error 520: How to Fix It Step-by-Step (2026)

Your site was fine an hour ago. Now every visitor sees a Cloudflare-branded page: "Web server is returning an unknown error." That's Cloudflare Error 520, and it's one of the nastiest errors to chase — your server still answers a ping, your DNS is fine, and the Cloudflare dashboard looks perfectly healthy.

Quick Answer: Cloudflare Error 520 means Cloudflare reached your origin server, but the response it got back was empty, malformed, or bigger than Cloudflare accepts. As of July 2026, the three most common triggers are a crashed PHP-FPM worker returning nothing, response headers or cookies exceeding Cloudflare's 32 KB limit, and origin firewall rules silently dropping Cloudflare's IP ranges.

Our team resolves 20-30 client issues every single day, and 520s come through often enough that we work them in a fixed order instead of guessing. This guide is that order, written so you can run it yourself without opening a ticket. Hostaccent, for one, treats a 520 as an origin fault until proven otherwise — and that assumption holds up the overwhelming majority of the time.

What Cloudflare Error 520 Actually Means

Error 520 is Cloudflare's catch-all. The edge opened a TCP connection to your origin, sent the request, and got back something it couldn't parse as valid HTTP. An empty reply. Truncated headers. A connection reset mid-stream. All of it collapses into one status code.

That's why the error feels so random. Cloudflare isn't withholding detail — it genuinely doesn't have any. The detail lives in your origin's logs, and nowhere else. Cloudflare's own developer documentation is clear that the 5xx range starting at 520 describes what the edge received, not what went wrong inside your application.

Here's the map that saves the most time:

| Error | What Cloudflare is telling you | Where the fault usually sits | |---|---|---| | 520 | Origin answered, but the response was empty or invalid | Origin app layer (PHP, Node, headers) | | 521 | Origin actively refused the connection | Web server stopped, or firewall dropping Cloudflare | | 522 | Origin never completed the handshake | Network, routing, or packet filtering | | 523 | Origin IP unreachable | DNS record points at nothing real | | 524 | Origin took longer than 100 seconds to respond | Slow queries, long-running scripts | | 525 | TLS handshake with the origin failed | Origin certificate or cipher mismatch |

If your error page says 525 rather than 520, stop here — that's a certificate problem with a completely different fix path. Start with Cloudflare Error 525: How to Fix SSL Handshake Failed instead.

Insider Insight: A 520 that appears only on POST requests, only on /wp-admin, or only for logged-in users is almost never a network problem. Intermittent-by-route means application. Constant-on-every-route means infrastructure. That one split cuts your diagnosis time in half before you've opened a single log file.

The 60-Second Origin Check (Run This First)

Before you touch a config file, prove whether the origin is broken in isolation. Bypass Cloudflare completely and hit your server directly:

bashCopy
## Swap in your real domain and your origin's IP address
curl -svo /dev/null https://example.com --resolve example.com:443:203.0.113.10

Three outcomes, three paths:

1. Clean 200 back. The origin is healthy on its own. Your problem is header size, cookie bloat, or a firewall rule that only fires for Cloudflare's IPs. Skip to causes 2 and 3.
2. curl: (52) Empty reply from server. The origin really is returning nothing. Go straight to your PHP-FPM and web server error logs — cause 1.
3. Connection refused or a timeout. You'd normally see a 521 or 522 for this, not a 520. You have a second problem stacked underneath.

Then grab the Ray ID from the Cloudflare error page and grep your access log for that timestamp. No matching log line at all? Your web server never finished writing a response, which points at a worker crash rather than a config mistake.

Cloudflare Error 520 Causes and Fixes, Ranked by How Often They Bite

1. A PHP worker died mid-response

This is the big one. When PHP-FPM hits a fatal error, gets killed by the kernel's OOM reaper, or segfaults, the socket closes with zero bytes written. Nginx passes nothing upstream. Cloudflare sees an empty reply and stamps 520 on it.

Check three places:

bashCopy
sudo tail -n 100 /var/log/php8.3-fpm.log
sudo grep -iE "segfault|out of memory" /var/log/syslog | tail -n 20
sudo journalctl -u php8.3-fpm --since "15 min ago"

The usual fix is memory. PHP ships with memory_limit at 128M, which a modern page builder plus a translation plugin will eat before breakfast. Open /etc/php/8.3/fpm/php.ini, raise it to 256M (or 512M for a busy store), then reload:

bashCopy
sudo systemctl reload php8.3-fpm

If the log shows a segfault rather than a memory exhaustion notice, an extension is the culprit — usually opcache or an outdated ionCube-style loader. Disable extensions one at a time and reload between each. The PHP manual documents which directives are safe to change at the FPM pool level rather than globally, which is the cleaner move if only one site is affected.

2. Response headers or cookies blew past Cloudflare's limit

Cloudflare caps total response headers at 32 KB, with a 16 KB ceiling on any single header. Cross it and the edge can't parse the response at all. Result: 520.

Measure it:

bashCopy
curl -sI https://example.com --resolve example.com:443:203.0.113.10 | wc -c

Anything creeping toward 32768 bytes is your answer. The usual offenders are a session cookie holding a serialized array, a Set-Cookie chain from a caching plugin, a security plugin writing an enormous Content-Security-Policy, or a Link header stuffed with preload directives. MDN's HTTP headers reference is the fastest way to work out which of yours are actually load-bearing and which are decoration.

Pro Tip: Cookie bloat compounds silently. Every cookie set on a host rides along on requests to that host, so a multisite running three analytics tools plus a consent manager can cross the ceiling only for logged-in users — while every anonymous visitor sees a perfectly fine site. If your 520 hits admins and nobody else, check cookies before you touch anything else.

3. Your origin firewall is silently dropping Cloudflare

This is the cause that produces the maddening intermittent 520s — the ones that "fix themselves" and come back an hour later. CSF, LFD, Fail2ban, ufw, or a cloud security group is blocking some of Cloudflare's edge IPs. Requests routed through allowlisted ranges succeed. The rest die.

Cloudflare publishes its IP ranges and rotates them. Allowlist the current set:

bashCopy
## Add every current Cloudflare IPv4 range to the CSF allow list, then reload
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do csf -a $ip "Cloudflare edge"; done
csf -r

Then audit what's already banned:

bashCopy
sudo fail2ban-client status
sudo tail -n 50 /var/log/lfd.log

Here's the part nobody mentions. Because Cloudflare proxies every request, your origin sees Cloudflare's IP as the client — unless you restore the visitor's real IP with Nginx's real_ip module or Apache's mod_remoteip. Skip that step, and the next brute-force attack makes Fail2ban ban a Cloudflare edge IP. You've just firewalled a slice of the internet off your own site. The Nginx documentation covers the set_real_ip_from and real_ip_header CF-Connecting-IP directives you need. In the tickets we work, this single misconfiguration explains most of the intermittent Cloudflare origin error reports we see.

4. Redirect or .htaccess rules returning a malformed response

A rewrite rule that loops, a Header always set directive with a stray character, or a mod_rewrite condition that returns nothing rather than a status — any of these can hand Cloudflare an unparseable response.

Rename .htaccess to .htaccess.bak, reload, and retest. If the 520 clears, the file is your problem. Rebuild it a block at a time. Loops usually announce themselves as a redirect error rather than a 520 — if that's what you're seeing, Too Many Redirects WordPress: Fix the Loop Fast (2026) is the closer match. If a rule starts returning a permission denial instead, 403 Forbidden Error: How to Fix It (Step-by-Step 2026) covers that branch.

5. The server simply ran out of resources

Least glamorous, more common than anyone admits:

bashCopy
free -h
df -h
sudo dmesg -T | grep -i "killed process"

A full disk is the sneaky one. When /tmp or the partition holding your session files hits 100%, PHP can't write a session and returns nothing at all — a textbook 520, with a completely healthy-looking web server sitting behind it. On the Cloudflare → Nginx → Apache stack Hostaccent runs on self-managed Ubuntu with NVMe SSD storage, the tell is always the same: the error log is empty and df -h shows a partition at 100%.

How to Confirm the Fix and Stop 520s Coming Back

Don't trust one page load. Hit the origin directly ten times in a row and watch for a single failure:

bashCopy
for i in $(seq 1 10); do curl -so /dev/null -w "%{http_code}\n" https://example.com \
  --resolve example.com:443:203.0.113.10; done

Ten clean 200s means the origin is stable. Then clear the Cloudflare cache and retest through the edge. If it's clean there too, purge your Ray ID sample and move to prevention.

Prevention comes down to four things:

• Restore real visitor IPs so your own firewall never bans Cloudflare. This is the single highest-value fix on this page.
• Set memory_limit deliberately, not by default. 256M is a sane floor for WordPress in 2026.
• Alert on disk usage at 85%, not 95%. By 95% you're already writing incident notes.
• Keep your headers lean. Audit curl -sI output quarterly.

From the Ticket Queue: Across Hostaccent's monthly support volume, our first-party numbers break down as WordPress issues 30%, brute-force and malware 25%, Linux server issues 25%, and SSL problems 20%. Origin-side 5xx errors like this one sit inside that Linux server slice — which is why the fix is nearly always at the server, not at the edge.

Pro Tip: Pausing Cloudflare is a diagnostic, not a fix. Grey-cloud the record, confirm the site loads directly, then turn the proxy back on. Leaving it paused just exposes your origin IP and hands attackers a direct route — and it doesn't repair whatever broke. If your instinct is to blame the SSL layer while you're at it, rule that out properly with SSL Certificate Errors: How to Fix 12 Common Issues (2026) and Certbot Renewal Failed? Fix Let's Encrypt SSL (2026) rather than guessing.

The Fastest Path Back Online

Five things to carry away:

1. Cloudflare Error 520 is an origin problem in almost every case. The edge is reporting, not failing.
2. Run the curl origin check first. Sixty seconds of measurement beats an hour of theorising.
3. Empty reply = worker crash. Clean 200 = headers, cookies, or firewall. That fork routes the whole diagnosis.
4. Intermittent 520s are usually your own firewall banning Cloudflare edge IPs because real visitor IPs were never restored.
5. The permanent cloudflare 520 fix is capacity and configuration, not a dashboard toggle.

Work the list in order and most 520s resolve inside fifteen minutes.

When the Server Underneath Is the Real Problem

If your origin keeps running out of memory, keeps filling its disk, or keeps dying under traffic you're actually happy to have, you're not fixing an error any more — you're outgrowing a box. That's the point where a managed VPS with headroom stops being a nice-to-have.

Hostaccent's VPS Hosting starts with the Basic plan at $7.99/mo (renews at $7.99/mo), on NVMe SSD storage across 15 datacenter locations worldwide, backed by a 99.9% uptime guarantee and a 30-day money-back guarantee. Honest limitation, though: a bigger server won't fix a plugin that leaks memory or an unindexed query. It buys you room while you fix the real thing — which is worth exactly that much, and no more.

FAQ Cloudflare Error 520

Is "web server returned unknown error" the same as Error 520?

Yes. "Web server is returning an unknown error" is the human-readable text Cloudflare prints on the 520 error page. Both refer to the same condition: Cloudflare connected to your origin, but the response it received was empty, truncated, or malformed enough that the edge couldn't parse it as valid HTTP.

Is Cloudflare Error 520 my fault or Cloudflare's?

Almost always yours — or more precisely, your origin server's. Cloudflare is reporting what it received, not causing it. In the rare cases where the edge is genuinely at fault, you'd see a Cloudflare status incident published publicly. Check your origin logs before you check Cloudflare's status page.

What's the difference between a 520 and a 502?

A 502 Bad Gateway is generated by your own web server when its upstream (PHP-FPM, Node, a proxied app) fails. A 520 is generated by Cloudflare when your entire origin returns something unparseable. If you're seeing 502 without Cloudflare in front, the fault is between Nginx and PHP.

Can too many cookies really cause a 520 error?

Yes, and it's underdiagnosed. Cloudflare rejects responses whose headers total more than 32 KB. Session cookies holding serialized data, plus caching-plugin cookies, plus consent-manager cookies can cross that line for logged-in users while anonymous visitors see no problem at all.

How long does a Cloudflare 520 error last?

Until you fix the origin. There's no automatic recovery and no timeout after which it clears itself. If a 520 appears to resolve on its own, the underlying condition — a memory spike, a firewall rule, a full disk — has receded temporarily and will return.

Does Cloudflare Error 520 hurt my SEO?

A short outage of a few hours does almost nothing measurable. Sustained 5xx responses do real damage: Googlebot reduces crawl rate when it repeatedly hits server errors, and pages can drop out of the index if the error persists across multiple crawl attempts. Fix it same-day and you'll be fine.

Will pausing Cloudflare fix Error 520?

No — it hides it. Pausing sends traffic straight to your origin, so the 520 page disappears while the underlying fault remains. Use it as a five-minute diagnostic to confirm the origin responds, then re-enable the proxy. Hostaccent engineers use exactly this test, but never as the resolution.