---
title: 502 Bad Gateway
description: What HTTP 502 means, why proxies and CDNs return it, and how to find which layer between the user and your app actually failed.
canonical: https://watchfor.io/docs/reference/http-status-codes/502
---

# 502 Bad Gateway

What HTTP 502 means, why proxies and CDNs return it, and how to find which layer between the user and your app actually failed.

**502 Bad Gateway** comes from a proxy — a load balancer, reverse proxy or
CDN — that asked an upstream server for the response and got garbage back: a
refused connection, a reset, a malformed reply, or nothing usable. The proxy is
fine; the thing *behind* it isn't.

Whenever you see a 502, mentally add the missing words: "**I**, the proxy, got
a bad response from **the origin**."

## Common causes

- **The app process is down** — crashed, OOM-killed, or mid-restart during a
  deploy; nginx can't reach the socket and 502s
- **Deploys without graceful handoff** — old workers killed before new ones
  listen; the seconds-long gap is a burst of 502s on every release
- **Upstream connection limits** — backend at max connections refuses new
  ones
- **Wrong upstream config** — proxy pointed at a dead port/IP after an
  infrastructure change
- **Response too large for proxy buffers** — oversized headers from the
  backend (nginx `upstream sent too big header`)
- **HTTPS mismatch** — proxy speaks plain HTTP to an origin expecting TLS, or
  can't validate the origin certificate (Cloudflare shows 525/526 for these)
- **Keep-alive races** — origin closes idle connections a hair before the
  proxy reuses them; sporadic, low-rate 502s that vanish when keep-alive
  timeouts are aligned

## Debugging

1. **Find the failing layer.** Hit the origin directly (bypassing the CDN/LB)
   — if it answers, the problem is between the proxy and origin: security
   groups, certificates, connection limits.
2. **Read the proxy's error log**, not the app's — the app may have never
   received the request. nginx's `connect() failed` vs `upstream prematurely
   closed` distinguish "down" from "crashed mid-response".
3. **Correlate with deploys.** 502 bursts aligned with releases mean the
   rollout isn't graceful — fix the handoff, don't tune the proxy.

A [multi-region HTTP monitor](/docs/monitors/web) timestamps every 502
precisely, which makes the deploy correlation obvious, and
[confirmed alerting](/docs/alerting/incidents) separates a one-request blip
from a dead backend. If only one region sees 502s, suspect the CDN PoP, not
your origin.

---

Canonical page: https://watchfor.io/docs/reference/http-status-codes/502 · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt