A Cloudflare 520 means Cloudflare got a weird or empty reply from your origin server, while a 502 means Cloudflare got a clear bad gateway failure. That is the fastest way to split the two. A 520 is the “something strange happened” box. A 502 is the “the gateway chain broke” box.

TLDR: HTTP Error 520 is Cloudflare saying, “Your server answered me in a way I cannot use.” HTTP 502 is usually a bad gateway, failed proxy, crashed upstream app, or blocked origin path. For example, if 18% of checkout users hit a 520 after a deploy, check origin logs, headers, and crashes first. If they hit a 502, check your web server, app server, load balancer, and port health first.

520 vs 502: the snack sized version

Think of Cloudflare as a waiter.

• 520: The kitchen sent back a plate with no food, no note, and maybe a sock on it.
• 502: The waiter reached the kitchen, but the kitchen door was jammed or the chef yelled “nope.”

Both errors feel bad to users. Both can kill signups. Both make support chats spicy. But they point to different parts of the stack.

520 is vague by design. Cloudflare uses it when the origin server response does not fit a normal error bucket. It may be empty. It may be malformed. It may close too early. It may include broken headers. Annoying? Yes. Useful? Also yes, if you treat it as a clue.

502 is cleaner. It says a gateway or proxy failed while trying to get a valid response. This often happens between Nginx and PHP FPM, Apache and an app worker, Cloudflare and your load balancer, or a reverse proxy and your API.

What HTTP Error 520 really means

Error 520 is Cloudflare’s “unknown error” for the origin. The browser talked to Cloudflare. Cloudflare then talked to your server. Your server did something odd.

Common 520 causes include:

• Empty response: The origin accepted the connection, then sent nothing back.
• Origin crash: The app died mid request. Classic. Painful. Familiar.
• Malformed headers: Headers are too large, broken, duplicated, or not valid.
• Firewall blocks: The origin blocks Cloudflare IPs or rate limits them.
• Connection reset: The server drops the connection before finishing.
• Bad HTTP behavior: The origin speaks in a way Cloudflare does not accept.

Honestly, it feels like the server slammed the door, then blamed the hallway.

A 520 often appears after a code deploy, plugin update, security rule change, or traffic spike. It can also show up when a site works from your office but fails through Cloudflare. That is a big hint. Cloudflare is seeing a different path than you are.

What HTTP 502 really means

HTTP 502 Bad Gateway means a server acting as a gateway received a bad response from another server. Simple enough. The mess starts when you ask which server.

In a Cloudflare setup, a 502 can come from:

• Cloudflare: Cloudflare cannot get a valid response from your origin.
• Your web server: Nginx or Apache cannot reach the upstream app.
• Your app server: Node, PHP FPM, Python, Ruby, or Java workers are down.
• Your load balancer: It has no healthy targets.
• Your hosting platform: The container or instance is restarting.

A 502 is usually less mysterious than a 520. It says the chain broke. You just need to find the snapped link.

How to tell them apart fast

Start with the error page. Cloudflare branded pages often include useful labels. A Cloudflare 520 page usually says “Web server is returning an unknown error.” A 502 page may say “Bad gateway” or show a host error.

Then check the timing.

• Instant error: Often firewall, DNS, bad port, or refused connection.
• Error after 10 to 30 seconds: Often timeout, app hang, or overloaded worker pool.
• Random failures: Often one bad origin behind a load balancer.
• Only POST requests fail: Check body size, WAF rules, and app crashes.
• Only logged in users fail: Check cookies, session storage, and cache bypass routes.

Expect to waste time on guesswork if you do not compare Cloudflare logs with origin logs. That extra five minutes often saves an hour.

The best first checks for a 520

If you see a 520, do not start by blaming DNS. Start at the origin.

1. Check origin access logs. Did the request arrive?
2. Check origin error logs. Look for crashes, memory errors, and killed workers.
3. Review response headers. Remove strange custom headers and huge cookies.
4. Allow Cloudflare IPs. Your firewall may be blocking real traffic.
5. Test direct origin access. Use the origin IP with the right Host header.
6. Disable recent changes. Plugins, rules, and deploys love causing chaos.

Here is a tiny test case. A store gets 520 errors on product pages only. The homepage works. Checkout works. Logs show PHP memory exhaustion on pages with 80 or more product variants. That is not a Cloudflare problem. That is an app problem wearing a Cloudflare mask.

The best first checks for a 502

If you see a 502, think upstream health.

1. Check if the app server is running. Sounds basic. Saves lives.
2. Check ports. Nginx may point to port 3000, while Node moved to 3001.
3. Check proxy config. Bad upstream names cause instant pain.
4. Check worker limits. PHP FPM or app workers may be maxed out.
5. Check load balancer targets. One dead node can spoil random requests.
6. Check SSL mode. Mismatched certificates can break origin connections.

Example: A SaaS dashboard shows 502 errors for 7% of users after a release. The load balancer has three targets. One target fails health checks. Users hitting that target get errors. Remove it, and the error rate drops under 0.2% in minutes.

Cloudflare 520 vs 502 in plain terms

Error	Meaning	First place to look
520	Unknown or invalid origin response	Origin logs, headers, crashes, firewall
502	Bad gateway or bad upstream response	Proxy, app server, load balancer, ports

The key difference is clarity. A 502 usually tells you a gateway failed. A 520 tells you Cloudflare got confused by the origin response. That means your job changes. With a 502, trace the chain. With a 520, inspect the response itself.

A simple troubleshooting flow

Use this order. It keeps panic low.

• Step 1: Confirm the exact code. 520 and 502 are not the same beast.
• Step 2: Check if all pages fail or only some routes.
• Step 3: Compare Cloudflare timestamps with origin logs.
• Step 4: Test the origin directly with the same URL and Host header.
• Step 5: Roll back the last change if the timing matches.
• Step 6: Watch live logs while reproducing the error.

If Cloudflare logs show requests but your origin logs show nothing, suspect firewall, network, or TLS issues. If origin logs show crashes, fix the app. If Nginx logs show upstream failures, chase the app server. If only one backend fails, remove it from rotation.

Final cheat sheet

Use 520 as a weird origin response clue. Look for empty replies, broken headers, crashes, and blocked Cloudflare IPs.

Use 502 as a broken gateway clue. Look for bad proxy settings, dead app workers, unhealthy load balancer targets, and failed ports.

The fix is rarely “clear cache and pray.” Nice try, though. Match the code to the failure type. Then check the closest logs. Your future self will be less grumpy.