Had a client’s WordPress site go down mid-afternoon with nothing but a Cloudflare error page and a Ray ID staring back at me — no site changes that day, no plugin updates, nothing obvious. That’s usually how error 520 shows up: sudden, vague, and completely unhelpful about what actually broke. Here’s what it means and how to actually track down the cause instead of just guessing.
Quick Answer
- Error 520 means Cloudflare successfully connected to your origin server but got back an empty, invalid, or unreadable response — it’s not a Cloudflare outage, it’s almost always something on your server’s side.
- Start by pulling your server error logs from the exact timestamp of the 520, since that tells you far more than the Cloudflare error page does.
- Deactivating all plugins and reactivating one at a time catches most WordPress-specific causes, since a PHP fatal error mid-request is the single most common trigger.
- Check that your server’s TCP idle timeout is 300 seconds or higher — anything shorter can cause intermittent 520s under normal load.
- If nothing on your server looks wrong, verify Cloudflare’s IP ranges are whitelisted in your firewall or security plugin.
Why It Happens
So the important thing to understand first: 520 isn’t a standard HTTP status code. Cloudflare generates it itself when it gets a response from your origin server that it can’t parse into anything sensible — meaning the connection worked, but whatever came back afterward didn’t. That’s different from a 521 or 522, which mean Cloudflare couldn’t reach your server at all.
PHP fatal errors or crashes mid-request. This is the most common WordPress-specific cause by a wide margin. A plugin conflict, a broken theme function, a WooCommerce hook that fails partway through, or a caching plugin doing something it shouldn’t — any of these can cause PHP to die before it finishes generating a response, and Cloudflare has nothing usable to relay back.
Server resource exhaustion. When CPU or memory gets maxed out — a traffic spike, a runaway cron job, an inefficient database query running in a loop — the server can return a garbled or empty response right before the process gets killed. This tends to be intermittent rather than constant, which makes it trickier to pin down than a straightforward crash.
Cloudflare IPs blocked at the firewall level. So a security plugin, a fail2ban rule, or a server-level firewall can end up blocking Cloudflare’s own IP ranges without anyone realizing it — sometimes this happens automatically after a plugin misidentifies Cloudflare’s proxy requests as suspicious traffic. When that happens, your server effectively refuses to respond properly to the very requests Cloudflare is trying to relay.
Oversized headers or cookies. Cloudflare enforces limits on total header and cookie size. If a plugin is stacking up cookies, or your site has an unusually large number of custom headers, you can cross that threshold and get a 520 instead of a normal response — this one’s easy to miss because it doesn’t show up as an obvious server error, just a response Cloudflare refuses to pass through.
TCP idle timeout set too short. Web servers have a default idle timeout, and it’s supposed to be 300 seconds. If yours is set lower — sometimes through a hosting panel default or a misconfigured Nginx/Apache setting — connections can get cut before a slower request finishes, especially on pages with heavier PHP processing.
An overlooked cause worth mentioning: SSL/TLS mode mismatches between Cloudflare and your origin. If Cloudflare’s SSL/TLS setting is on Full or Full (Strict) but your origin server’s certificate is expired, self-signed, or doesn’t match, the handshake between Cloudflare and your server can fail in a way that surfaces as a 520 rather than a more obvious certificate warning.
Step-by-Step Fixes
Step 1: Check your server error logs first
Before changing anything, find the exact timestamp of the 520 and check your logs around it. If your host uses cPanel, go to Metrics > Errors. On SSH, something like:
tail -f /var/log/apache2/error.logor the Nginx equivalent. Look for PHP fatal errors, segmentation faults, or connection reset entries right around when the error occurred. This step alone tells you which category of fix to focus on instead of working through everything blindly.
Step 2: Deactivate all plugins and test
Deactivate every plugin at once, then reload the site. If the 520 clears up, reactivate them one at a time, checking the site after each one, until it reappears — that’s your culprit. And if you’re on a live site, do this during low-traffic hours, or better, replicate it on a staging copy first.
Step 3: Check your .htaccess file
A syntax error or conflicting rule in .htaccess can cause Apache to return an empty or malformed response. Rename it temporarily to .htaccess_backup to disable it, then check if the error clears. If it does, go to Settings > Permalinks in WordPress and save — this regenerates a clean version.
Step 4: Verify Cloudflare’s IP ranges are whitelisted
Pull the current list from cloudflare.com/ips and make sure your firewall allows traffic from those ranges on ports 80 and 443. On UFW that’s something like ufw allow from [ip-range]; on iptables it’s iptables -I INPUT -s [ip-range] -p tcp --dport 443 -j ACCEPT. Some hosts whitelist these automatically, so check with your host before assuming you need to do this manually.
Step 5: Check your SSL/TLS mode in Cloudflare
In the Cloudflare dashboard under SSL/TLS, confirm the mode matches what your origin actually supports. If it’s set to Full or Full (Strict), your origin needs a valid, non-expired certificate. If you’re not sure your origin’s certificate is solid, an SSL checker tool will confirm quickly.
Step 6: Pause Cloudflare temporarily to isolate the problem
Set the affected DNS record to DNS-only (the gray cloud instead of orange) or pause Cloudflare entirely for the domain. If the site loads fine directly against your server, that confirms the issue is between Cloudflare and your origin rather than a WordPress problem on its own — which narrows your troubleshooting considerably.
What Actually Worked For Me
I started by assuming it was a Cloudflare-side issue, since the error page makes it sound that way, and spent a while checking Cloudflare’s status page and poking at DNS settings that were already fine. That went nowhere, obviously, since the problem was never on Cloudflare’s end.
What actually cracked it was going straight into the server error log instead of trusting the Cloudflare error page to tell me anything useful — and there it was, a PHP fatal error from a plugin update that had gone out earlier that day, silently, without me noticing. Rolled back the plugin version, and the 520 was gone immediately. Kind of embarrassing in hindsight that I checked everything except the actual server logs first, but that’s usually where the real answer is with this error, not in Cloudflare’s dashboard.
Advanced Fixes and Edge Cases
Rocket Loader breaking the WordPress or Elementor editor. If you’re specifically seeing 520 errors while trying to edit a page in the Elementor site editor, this is a known interaction — Rocket Loader changes how scripts load asynchronously in a way that conflicts with the editor. Create Cloudflare page rules to exclude editor URLs (something like yoursite.com/*elementor*) from Rocket Loader.
Check Cloudflare’s OriginResponseStatus vs your origin’s actual response. If you have access to Cloudflare Logpush or Origin Analytics, compare what your origin actually returned against what Cloudflare served the visitor. If your server logged a 200 but Cloudflare shows a 520, that’s a strong signal of a malformed response — oversized headers or a connection that closed early — rather than an outright crash.
Rule out network hardware resets. If a firewall, load balancer, or other piece of networking equipment between Cloudflare and your origin gets updated or restarts mid-connection, headers from the existing session can go stale and produce intermittent 520s that don’t correlate with anything in your WordPress or PHP logs. This is rarer, but worth checking if your logs are clean and the error still recurs.
Prevention Tips
- Keep WordPress core, your theme, and all plugins updated — outdated code is consistently the leading cause of the PHP fatal errors behind this error.
- Test major plugin or PHP version updates on a staging environment before pushing to production.
- Monitor server resource usage over time so a slow creep toward exhaustion doesn’t blindside you during a traffic spike.
- Re-check your firewall’s Cloudflare IP whitelist periodically — Cloudflare’s ranges do shift occasionally, and a stale whitelist can silently start blocking legitimate traffic.
FAQ
Is Error 520 the same as Error 502? No — 502 is a standard HTTP status usually pointing to a misconfigured proxy or gateway layer, while 520 is Cloudflare’s own catch-all for any response it can’t parse, which covers a broader range of causes.
Does Error 520 mean my site was hacked? Not inherently, no. It’s almost always a server-side software or configuration issue — a plugin conflict, resource exhaustion, or a misconfigured setting — not a sign of compromise on its own.
Can I fix this from the WordPress dashboard alone? Sometimes, if it’s a plugin conflict you can deactivate through wp-admin. But if wp-admin itself is inaccessible because of the error, you’ll need FTP, SSH, or your hosting control panel to disable plugins manually.
How long does it take Cloudflare DNS changes to fix this? If the cause was DNS-related, propagation can take anywhere from a few minutes up to 72 hours depending on your host, though most WordPress-specific causes resolve much faster since they don’t involve DNS at all.
Editor’s Opinion
should’ve checked the server error log before doing literally anything else, that’s the real lesson here. cloudflare’s error page just isnt gonna tell you anything useful, it’s your own logs that have the actual answer almost every time. save yourself the detour and start there.
