502 Bad Gateway: Is It the CDN or Your Origin? How to Tell

A 502 means one server, acting as a gateway or proxy, received an invalid response (or none) from the server behind it. When your site sits behind a CDN, a load balancer and a reverse proxy, there are several gateways, and the first question is not "how do I fix it" but "which layer produced it". Changing origin settings when the CDN generated the error wastes hours.

For the general meaning and generic fixes, read fix 502 Bad Gateway and the HTTP 502 reference. This page is a method for isolating the layer.

Step 1: capture the response, not the browser's page

curl -sS -D - -o /tmp/body.html https://example.com/ | head -n 25
head -c 600 /tmp/body.html

Record three things: the status line, the server, via, cf-ray, x-cache and similar headers, and the first lines of the body. The HTTP Header Checker shows headers from outside your network, and the CDN Detector identifies the provider in front.

Step 2: read the fingerprints

Header names vary by product, and some CDNs pass through the origin's own error page unchanged, so treat the table as a starting point.

If Cloudflare is involved, note that many problems have their own 52x codes with more detail than a bare 502. Use the Cloudflare Error Checker and read Cloudflare errors 520-526. A CDN-generated 502 normally means the CDN could not get a valid response from your origin, so the fault may still be the origin even though the CDN printed the message.

Step 3: bypass the CDN and test the origin directly

Send a request straight to the origin IP while keeping the real Host header and SNI:

curl -sS -D - -o /dev/null \
  --resolve example.com:443:203.0.113.10 \
  https://example.com/

Replace the IP with your origin's address (find it in your hosting panel; keep it private). Interpret the result:

• Origin returns 200 but the CDN returns 502. The CDN cannot talk to the origin properly: wrong origin port or protocol, SSL mode mismatch, firewall blocking the CDN's IP ranges, an origin certificate problem, or the CDN's health check marking the origin down.
• Origin also returns 502. The fault is behind your first proxy. Continue inward: proxy to app server.
• Origin times out or refuses. Server down, firewall, or the service is not listening; see connection refused, timed out and reset.

If the origin answers differently for different paths, test the failing URL specifically, including query strings and headers such as cookies and authorization that the CDN might add or drop.

Step 4: check each layer's logs

1. CDN logs or analytics. Look at the origin status the CDN received and its error category. Some providers expose origin response codes per request.
2. Load balancer. Check target health, health-check path and status, and access logs. Targets marked unhealthy cause 502 or 503 depending on the product. See load balancer health checks.
3. Reverse proxy. sudo tail -f /var/log/nginx/error.log. Typical lines: connect() failed (111: Connection refused) while connecting to upstream (see nginx connect failed 111), upstream prematurely closed connection, upstream sent too big header (details).
4. Application server. Process crashed or restarting, worker killed by the OOM killer, PHP-FPM socket missing. Check systemctl status, app logs and dmesg.

Step 5: common CDN-versus-origin culprits

• Protocol mismatch. The CDN connects over HTTPS to an origin that speaks only HTTP, or the reverse. The SSL mode in your CDN dashboard must match what the origin serves.
• Origin firewall blocks the CDN. A WAF, fail2ban or security group that bans the CDN's edge IPs after a burst of requests.
• Origin rate limits. The CDN's traffic all appears to come from a few IPs and hits per-IP limits.
• Wrong or changed origin address. DNS for the origin hostname changed after a migration, and the CDN still points at the old target.

Step 6: check regional or intermittent patterns

If only some visitors see the error, test from several places with Down From Where, since CDN edges and load balancer nodes fail independently. The Outage Root Cause Finder walks through DNS, network, TLS and HTTP layers in order. Intermittent 502s that line up with deploys, cron jobs or memory spikes are origin symptoms. Errors tied to one region or edge location suggest the CDN path.

Verify and monitor

When fixed, both the CDN URL and the direct-origin test should return the same successful status. Watch it with an uptime monitor that records response codes, and check the status with the HTTP Status Checker.

Next steps

• Read the full fix 502 Bad Gateway guide.
• Tune proxies in nginx 502 and 504 timeout tuning.
• Learn the CDN layer in CDN explained.
• See timeouts by layer in 504 Gateway Timeout by layer.

FAQ

Can the CDN cause a 502 on its own?

Yes, if its own infrastructure fails, but more often it reports a problem it found at your origin. Test the origin directly to see which.

Why does the origin work in my browser by IP?

Browsing by IP skips the Host header and SNI. Use curl --resolve so the origin sees the same hostname the CDN sends.

Is 502 different from 520 on Cloudflare?

Yes. Cloudflare uses 52x codes for specific origin failures. A plain 502 can still appear, so read the page and the Ray ID.

Should I purge the cache to fix a 502?

Rarely. Error responses are not usually cached for long, and the cause is a failed fetch from the origin, which a purge does not repair.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.