What a 502 actually means
A 502 Bad Gateway error means that a server acting as a gateway or proxy received an invalid or no response from an upstream server it was trying to reach. In other words, the front-facing component (like a proxy or load balancer) is up, but the thing behind it failed to respond properly. This points the investigation toward the connection between the proxy and the application behind it, rather than at the proxy or CDN itself, which is often wrongly blamed first.
Work the path in layers
The best approach is a layered checklist, tracing the request path from the outside in: DNS, the load balancer or proxy, and then the application upstream. Checking each layer in order isolates where the chain breaks. Resisting the urge to assume the CDN or web server is at fault, and instead methodically following the path to the upstream, is what efficiently narrows a 502 to its real cause, which usually lies in the application or the proxy-to-app connection.
Check DNS and load balancer health
Start by confirming DNS resolves correctly to the right place, since a DNS problem can misroute requests. Then check the load balancer's health: is it up, and crucially, does it consider its backends healthy? A load balancer that has marked all its upstreams unhealthy, or cannot reach them, will return a 502. Verifying DNS and that the load balancer sees healthy backends addresses common front-layer causes and tells you whether the problem is reaching the application at all.
Read proxy logs and check the app
The proxy or load balancer logs are invaluable: they typically record why it returned a 502, such as a connection refused, a timeout, or an upstream that closed the connection. Then check the application processes: are they actually running and accepting connections, or have they crashed, hung, or run out of capacity? Very often a 502 means the application upstream is down or not responding, so confirming the app is alive and healthy is central to the diagnosis.
Sockets and upstream timeouts
Dig into the connection details: check that the application is listening on the expected socket or port the proxy is trying to reach, since a mismatch or a not-listening app causes a 502. Also consider upstream timeouts, if the application is too slow to respond, the proxy may give up and return a 502, so a slow or overloaded app can trigger it even while technically running. Checking sockets and timeout behavior pins down whether the issue is connectivity or the app being too slow.
The bottom line
A 502 Bad Gateway means a proxy got a bad or no response from upstream, so diagnose it with a layered checklist from the outside in: verify DNS, check load balancer health and backend status, read proxy logs for the specific reason, confirm the application processes are running and listening on the right socket, and consider upstream timeouts. This methodical path narrows the fault to its real cause, usually the application or its connection, rather than wrongly blaming the CDN or web server.
Related on Skillo
See also: Application load balancer vs reverse proxy: what is the difference?, How to use logs, metrics and traces to find latency.
Sources
Published date reflects the original event date (2026-10-23). This article is original Skillo editorial written from the sources above; facts were verified in September 2026.
Leave a Reply