502 Bad Gateway
Published 17 September 2026
A 502 bad gateway is two of somebody else's servers failing to talk to each other. Almost none of it is about you, and the error itself is the proof, because a server had to receive your request and compose a reply in order for you to be reading the number at all.
What the words mean
A gateway is a machine in the middle: a reverse proxy, a load balancer, a CDN edge, an API gateway. It does not generate the page you asked for. It takes your request, hands it to a backend server behind it, and relays whatever comes back.
Bad gateway means the answer it got back was unusable. The backend either replied with something that was not valid HTTP, or closed the connection mid-sentence, or was not there to reply at all. The gateway, having nothing sensible to relay, tells you 502.
So the sentence to hold onto is: the front server worked well enough to answer you, and the server behind it did not.
Why this cannot be your network
Every HTTP status code is evidence of a completed round trip. For a 502 to appear on your screen, the name resolved, a TCP connection opened, TLS negotiated if it was https, your request was delivered, and a response came back. All five worked.
Had your network been the problem, you would have no status code: a refused connection, a timeout with no reply, or a DNS failure. Those look and behave differently, and none of them produce a numbered error page.
| Leg of the journey | Whose | Worked? |
|---|---|---|
| You → their gateway | You and the internet | Yes |
| Their gateway → their backend | Them | No: this is the 502 |
| Their gateway → you | You and the internet | Yes |
502 or 504? They are not the same
Both come from the gateway, and the difference tells you what to look for.
- 502: the backend said something, and it was unusable. Garbage, a truncated response, a connection reset, or a refusal to accept the connection in the first place.
- 504: the backend said nothing in time. It accepted the connection and then went quiet.
- 503: no backend was involved. A server that is running declined to serve you, and unlike the other two that is often deliberate.
Nonsense versus silence. A 502 usually means something is down or crashing; a 504 usually means something is slow.
If you own the server
Work backwards from the gateway. It is reporting honestly, so the fault is behind it.
- Is the backend running? The most common cause by a distance. The application crashed, failed to restart after a deploy, or is in a crash loop.
- Is it listening where the proxy expects? A port change, a socket path that moved, or a container that came up on a different address. The proxy config and reality have drifted apart.
- Is it dying mid-request? A worker that is killed by the OOM killer part way through a response produces a 502 rather than a clean error, because the connection closes with the reply half-sent.
- Check both logs, in order. The proxy log says it got a bad answer; the application log says why. If the application log has no entry at all, the request never reached it: that is a connectivity or configuration problem between the two, not an application bug.
- Upstream TLS. If the proxy speaks https to the backend, an expired or mismatched certificate on the backend produces a 502. That one is easy to miss because the public certificate is perfectly fine.
If you do not own it
- Retry. A meaningful share of 502s are a backend restarting, and they clear in seconds.
- Check whether it is universal. The same URL from another network and another device settles it. If it fails everywhere, it is theirs and reporting it is the only useful action.
- Read the headers. A
cf-raymeans Cloudflare generated the error, which puts the failure between Cloudflare and the origin. Cloudflare's own numbers are more precise if you see them: 521 is the origin refusing the connection, 522 is a connection timeout to the origin, and 523 is the origin being unreachable at all. - A 502 on one path only usually means one backend service among several is broken, rather than the whole site.
Get the verdict in one request. The
HTTP status checker fetches the URL,
follows the redirect chain, and states whether the fault is yours, theirs
or actually the network, and surfaces the headers that change the
answer, including cf-ray and retry-after.
What a 502 is never
- Your browser. Clearing the cache cannot change what a backend server said to a proxy. Nor can a different browser.
- Your DNS. If DNS were wrong you would reach the wrong server or none, not a gateway that answers you. Flushing it changes nothing here: see what flushing actually clears.
- Your firewall. A blocked connection does not produce an HTTP reply.
- Your ISP. They carried the request there and the answer back. That is the whole job, and the 502 is evidence they did it.
The one honest exception: if you sit behind a corporate proxy, that proxy is a gateway too, and it can generate a 502 of its own about a backend it could not reach. The tell is the error page: it will look like your company's, not the site's. That case is worth raising internally, and it is the only version of this where the network team is the right audience.