Treat Cloudflare 520 as an “origin behaved strangely” error, not as a normal bad gateway error. Cloudflare says Error 520 appears when the origin server returns an empty, unknown, or unexpected response to Cloudflare [source: Cloudflare]. That makes it harder to troubleshoot than HTTP 502, which usually points to a clearer gateway or upstream failure.
TLDR: A 520 means Cloudflare reached your origin, but the response was weird, broken, or missing. A 502 means a gateway or proxy got an invalid response from an upstream server, which is often easier to trace. For example, if an online store sees 312 failed checkouts in 20 minutes and 78% show 520, start with origin logs, headers, firewall rules, and crashes. If most errors are 502, check reverse proxies, load balancers, PHP FPM, Node workers, or upstream health.
What Error 520 actually means
Error 520 is Cloudflare’s “something went wrong at the origin, but not in a clean way” code. It is not a standard HTTP status code created by your web app. It is Cloudflare’s wrapper for a response it cannot classify.
That vague wording is what makes 520 annoying. Your server may be online. DNS may be correct. SSL may look fine. Yet visitors still see a Cloudflare error page. Honestly, it feels like the server is shrugging at you.
Common causes include:
- Empty response from the origin server.
- Malformed headers, often from custom middleware or plugins.
- Oversized response headers, such as huge cookies.
- Origin process crashes before completing the request.
- Firewall or security software blocking Cloudflare IPs.
- Connection resets caused by Apache, Nginx, PHP FPM, Node, or a load balancer.
How HTTP 502 is different
HTTP 502 Bad Gateway is a standard HTTP status code. It means a server acting as a gateway or proxy received an invalid response from an upstream server. That proxy could be Cloudflare, Nginx, Apache, HAProxy, AWS ALB, a CDN, or an API gateway.
In plain English: one server asked another server for help, and the second server sent back junk, timed out, or failed.
Typical 502 causes include:
- Upstream app is down, such as a crashed Node.js or Python service.
- PHP FPM is overloaded or stopped.
- Nginx proxy settings are wrong, including port or socket paths.
- Load balancer cannot reach healthy targets.
- Backend timeout after slow database or API calls.
The key difference is this: 502 usually tells you the proxy chain broke. A 520 says Cloudflare got a response it did not know how to handle.
Cloudflare 520 vs HTTP 502 at a glance
| Issue | Cloudflare 520 | HTTP 502 |
|---|---|---|
| Type | Cloudflare specific error | Standard HTTP status code |
| Main meaning | Unexpected or empty origin response | Bad response from upstream server |
| Best first check | Origin logs and headers | Proxy and upstream service health |
| Common culprit | Firewall, crash, malformed headers | App server, gateway, timeout |
| Debug clarity | Often messy | Usually more direct |
Start troubleshooting where the error is born
The fastest path is to separate Cloudflare symptoms from origin symptoms. Do not start by changing five settings at once. That just makes the outage harder to read.
- Check the timestamp. Match the visitor error time with origin access logs and error logs.
- Record the Cloudflare Ray ID. It helps connect a user report with Cloudflare events.
- Bypass Cloudflare briefly. Test the origin directly with curl or a hosts file entry.
- Compare paths. If only /checkout fails, inspect app code, cookies, sessions, and payment API calls.
- Check server resources. CPU, RAM, disk IO, and process limits can create random failures.
Expect to waste time on false leads if logs are missing. It drives me crazy that many hosts keep short log windows or hide upstream errors behind a tidy dashboard. If you run a busy site, centralize logs before the next outage.
When it is probably a 520
A 520 often appears when the origin breaks the rules in a subtle way. The server may accept the TCP connection, then return nothing useful. Cloudflare then shows a 520 because it cannot map the failure to a regular status code.
Look for these signs:
- Requests reach the origin, but access logs show strange status values or no completed response.
- Error logs mention header problems, segmentation faults, worker exits, or upstream resets.
- Only Cloudflare traffic fails, while direct origin tests work from your office IP.
- Large cookies appear after login, cart updates, or A B testing scripts.
- Security plugins or WAF rules block Cloudflare IP ranges.
For WordPress, 520 errors often follow plugin updates, caching changes, or bloated cookies. For custom apps, check middleware that edits headers. A single bad header can turn a valid response into a mystery error.
When it is probably a 502
A 502 usually has a cleaner trail. The gateway asked an upstream service for a response and got a bad one. In many stacks, Nginx talks to PHP FPM, Node, Ruby, Java, or a container behind it. If that upstream is down, overloaded, or slow, 502 appears.
Check these first:
- Nginx error log for “connect failed,” “upstream prematurely closed connection,” or timeout messages.
- PHP FPM status for max children reached, slow scripts, or crashed pools.
- Container health if Docker or Kubernetes runs the app.
- Load balancer target health and backend ports.
- Database latency, especially during traffic spikes.
A simple example: Nginx proxies to an app on port 3000. The app crashes during a deploy. Nginx still receives browser requests, but port 3000 refuses connections. That is classic 502 territory.
A practical troubleshooting workflow
Use this order when production is on fire:
- Confirm the code. Is the user seeing Cloudflare 520, Cloudflare branded 502, or an origin generated 502?
- Test from multiple locations. If only some regions fail, suspect routing, firewall, or Cloudflare edge variation.
- Run curl against Cloudflare. Capture status, headers, and response time.
- Run curl against the origin IP. Use the correct Host header so the web server serves the right site.
- Inspect headers. Remove giant cookies and unusual custom headers during testing.
- Restart safely. Restarting Nginx, PHP FPM, or app workers can help, but save logs first.
- Review recent changes. Deploys, plugin updates, firewall edits, SSL renewals, and CDN settings matter.
Fixes that often work
For Cloudflare 520, allow Cloudflare IP ranges through your firewall, reduce cookie size, disable suspicious plugins, and check malformed headers. Also review origin TLS settings if failures began after certificate or cipher changes.
For HTTP 502, restart failed upstream services, fix proxy_pass targets, increase sensible timeouts, and review worker limits. If the app is slow because the database is stuck, raising the timeout only hides the real fault.
Good monitoring makes both errors less painful. Track 5xx rate, origin response time, CPU steal, memory pressure, PHP FPM queue length, and container restarts. A graph that shows 5xx errors rising from 0.2% to 6.8% at 14:05 is far more useful than “site is broken.”
The useful rule of thumb
If the error is 520, ask: “What did my origin send that Cloudflare could not understand?” If the error is 502, ask: “Which upstream server failed to answer the gateway properly?”
That split saves time. It keeps you from blaming Cloudflare for a crashing app, and it keeps you from digging through app code when the proxy target is simply dead. The codes look similar to users. For engineers, they point to different failure paths.
Fix the path first. Then clean up the cause. That is how you turn a vague 5xx outage into a short, contained incident instead of a long afternoon of guesswork.
