Trace 502 through proxy, CDN, and upstream layers

When to use this guide

Use this guide when users see a 502 Bad Gateway and you need to find the failing layer without guessing. The request chain is usually browser -> DNS -> CDN/load balancer -> reverse proxy -> origin -> upstream app -> database or external dependency.

Before you start

• Capture the exact URL, timestamp, timezone, and response headers.
• Note whether the error page is branded by a CDN, host, nginx, Apache, or your application.
• Avoid bypassing CDN or cache on production traffic unless you know the origin is protected and ready.

Step 1: Capture headers from the public edge

curl -I https://www.example.com/problem-page

Expected output includes the status line and headers such as server, via, cf-ray, x-request-id, or provider-specific request IDs. If the response is CDN-branded, save that ID before purging or changing origin settings.

Step 2: Compare another network or location

Try a mobile network, a remote server, or a monitoring location. If only one network fails, DNS, ISP routing, firewall, or resolver behavior may be involved. If every location gets the same 502, continue toward CDN, origin, proxy, and upstream logs.

Step 3: Check CDN-to-origin vs origin response

When your setup allows a safe origin test, compare the CDN URL to the origin hostname or internal load balancer. Do not expose a private origin or bypass WAF rules on public internet just for testing. A safe origin check should be limited, authenticated, or run from trusted infrastructure.

curl -I https://origin.example.internal/problem-page
curl -I -H "Host: www.example.com" http://203.0.113.10/problem-page

If the origin returns 200 while the CDN returns 502, check CDN origin settings, TLS/SNI, firewall allowlists, health checks, and stale origin IPs. If origin also returns 502, move inward.

Step 4: Inspect the reverse proxy

grep "problem-page" /var/log/nginx/access.log | tail
grep "upstream" /var/log/nginx/error.log | tail -50

Expected output should show whether nginx received the request and whether it could talk to the upstream. Phrases such as connect() failed, no live upstreams, upstream prematurely closed connection, and upstream timed out all point to different fixes.

Step 5: Verify the upstream app and database

systemctl status php-fpm
systemctl status nginx
curl -I http://127.0.0.1:3000/health

Expected output is an active service and a health endpoint returning a successful status. If the app is healthy but pages still fail, check database health, connection limits, migrations, and slow upstream dependencies.

Decision table

Verify

After the fix, run the public curl -I again, test the origin if safe, and confirm proxy logs show successful upstream responses. Watch error rate for at least one cache TTL or deploy window.

Rollback or escalate

Rollback the smallest recent change: CDN origin setting, nginx upstream target, app deployment, PHP-FPM pool change, or database migration. Escalate with captured headers, request ID, timestamp, origin/proxy comparison, and exact log phrases.