HTTP 502 Bad Gateway: What Broke Between Your Proxies

Jul 17, 2026 · HTTP Status Codes

Follow one request to a typical production site and you'll pass through more servers than most people expect: the browser talks to a CDN edge, the edge talks to a load balancer, the load balancer talks to nginx, nginx talks to an application process, and the app talks to a database. The 502 status code lives in the seams of that chain. It means one specific thing: a server acting as a gateway asked the next server upstream for a response and got back something unusable — a refused connection, a reset, half a response, or bytes that don't parse as HTTP.

Here's the counterintuitive part: the server that sent you the 502 is healthy. It did its job — it tried the upstream, the upstream failed it, and it reported honestly. The problem is always one hop further back than the thing that told you about it.

Anatomy of a 502: two servers, one bad handoff

Every 502 involves a pair: the gateway (nginx, HAProxy, a CDN, an AWS load balancer) and the upstream it couldn't get a valid response from (your app server, PHP-FPM, a backend pool). When nginx logs connect() failed (111: Connection refused) while connecting to upstream, it's telling you exactly which pair failed and how. That "how" is the diagnostic gold — a refused connection means nothing is listening at that address; a reset mid-response means the upstream process died while working; malformed bytes mean something answered that doesn't speak HTTP.

Note the distinction from a 504: a 502 means the upstream answered wrongly, a 504 means it didn't answer in time. Refused-versus-slow points you at completely different causes, which is why the two codes exist separately.

What causes the 502 status code most often

In practice, three scenarios cover most incidents. First, the app is simply down: PHP-FPM stopped, the Node process crashed and nothing restarted it, or the kernel's OOM killer picked your app as the sacrifice (check dmesg). Second, a config mismatch: the proxy forwards to port 3000 but the new deploy listens on 8080, or a container's internal port mapping changed. These 502s start at deploy time and affect 100% of requests. Third, capacity exhaustion: every PHP-FPM worker is occupied (often because each one is stuck waiting on a slow database), so new connections get refused. These 502s are intermittent, load-correlated, and the ones most likely to page you at night.

Tracing a 502 through the stack

Work backwards from the user, one hop at a time. First confirm what the world sees: curl -sI https://yoursite.com/. Then bypass the CDN and hit your origin directly (curl's --resolve flag lets you pin the domain to the origin IP) — if the origin serves 200 while the CDN serves 502, the broken handoff is between CDN and origin, which is CDN configuration territory. If the origin itself 502s, get on the box and ask nginx what it's mad about: the error log names the upstream address and the failure mode. Then check whether anything is actually listening there — ss -tlnp | grep 8080 — and whether the process manager thinks the app is running versus crash-looping (systemctl status, container restart counts).

The single most useful habit: read the gateway's error log before theorizing. It literally names the address it tried and what went wrong. Half of all 502 debugging time is wasted by people guessing at causes the log would have handed them in one line.

502s and search engines

Googlebot treats a 502 like any server error: temporary at first, meaningful if it persists. A brief 502 window during a bad deploy has no SEO consequence. Recurring 502s — the intermittent, load-correlated kind — are worse than they look, because Googlebot slows its crawl rate when it hits 5xx responses, and a site that errors under load errors precisely when crawlers visit during traffic peaks. Long-persistent 502s eventually get URLs dropped from the index, same as any sustained 5xx. The pattern to fear isn't the outage you noticed; it's the 2% background 502 rate you didn't. If unexplained 502s keep appearing, they often share a root cause with the errors described in our HTTP 500 guide — the same crashed worker produces different codes depending on when in the request lifecycle it dies.

Stopping the next 502 before users see it

• Health checks with automatic removal. Load balancers should probe upstreams every few seconds and stop routing to dead ones. A pool of two app servers with health checks turns a crash into a non-event instead of a 502 storm.
• Process supervision. Anything serving production traffic needs automatic restart — systemd, a container orchestrator, whatever fits. A crashed process that restarts in two seconds produces a blip; one that stays down produces an incident.
• Right-size worker pools. If PHP-FPM exhaustion is your recurring theme, raise pm.max_children to what your memory actually supports and fix the slow queries that make workers linger. Pool exhaustion is nearly always a symptom of slowness upstream of the pool.
• Deploy without gaps. Rolling restarts and health-gated deployments prevent the window where the proxy forwards to an app that isn't up yet.
• Watch from outside. Internal dashboards can look green while the CDN-to-origin path serves 502s to the world. Point an uptime monitor at your site from the public internet so you're measuring what users and crawlers actually receive.