A 502 means the proxy (nginx, an ALB, an ingress controller) got a response from upstream, but it wasn't a valid HTTP response — usually because upstream crashed, closed the connection, or never accepted it in the first place. This is a proxy-side error, not an application error page.
Confirm which layer returned the 502
curl -i https://example.com/Check response headers — a 502 from nginx carries a Server: nginx header; one from an AWS ALB carries none of nginx's headers at all. This tells you which hop to investigate first.
Check the upstream process is actually running
systemctl status appIf the upstream process crashed or never started, the proxy has nothing to connect to — this is the most common cause of a 502.
ss -tlnp | grep :8080Confirms something is actually listening on the port the proxy is configured to forward to.
Read the proxy's own error log
tail -n 100 /var/log/nginx/error.lognginx logs the specific reason for a 502 — connection refused, upstream timed out, or upstream sent an invalid response — which curl alone won't show you.
Kubernetes ingress
For an ingress controller, kubectl logs -n ingress-nginx deploy/ingress-nginx-controller shows the same class of
upstream connection errors.
Check for a timeout mismatch
If the log shows upstream timed out, the application is slower than the proxy's patience. Either the app has a
performance problem, or the proxy timeout needs to be raised to match a genuinely slow but correct endpoint (large
report generation, a slow downstream dependency).
grep -i timeout /etc/nginx/nginx.confCheck proxy_read_timeout / proxy_connect_timeout against how long the upstream actually takes to respond.
Check load balancer health checks
On an ALB or ingress, a 502 can also mean the health check is marking every target unhealthy, so there's no valid upstream to route to at all — check the target group's health check path and status, not just the request path.
Common causes
- Upstream application process crashed or is still starting up (common right after a deploy).
- Upstream is listening on a different port or interface than the proxy is configured to forward to.
- Proxy timeout is shorter than a legitimately slow upstream response.
- Upstream is sending a malformed or oversized response header the proxy rejects.
- Load balancer target group has no healthy targets.
502 vs. 504
A 504 Gateway Timeout means the proxy successfully connected but the upstream never responded in time. A 502 means the connection itself failed, or the response was invalid — a narrower and usually more urgent signal that the upstream is actually down, not just slow.
Quick multi-step check
systemctl status app
ss -tlnp | grep :8080
tail -n 50 /var/log/nginx/error.log