The short version
- 01Check the site's status and note whether other pages fail too.
- 02Record the error time and any gateway or request identifier.
- 03Compare another permitted connection if the failure is isolated to a custom proxy.
- 04Locate the gateway that generated 502 and inspect its upstream error logs.
- 05Correct the demonstrated connection, TLS or response-format problem.
- 06Retest the same public route and verify any submitted action before repeating it.
Raw message
502 Bad Gateway
Likely causes
- The upstream closes or resets a connection before the gateway receives a usable response.
- The upstream sends malformed HTTP response headers.
- A gateway-to-upstream TLS handshake fails.
- A proxy in the request path encounters a backend communication failure.
The failure sits between two serving components
502 describes an invalid upstream response encountered by a gateway or proxy. The gateway can be a load balancer, reverse proxy or another intermediary. A valid HTTP error from an upstream is different from a response the gateway cannot use.
Keep the neighboring codes distinct: 504 concerns waiting too long upstream, while 503 reports service unavailability. Provider implementations add specific causes, so inspect the actual response and gateway logs before choosing a remedy.
If you see Bad Gateway in a browser
Our first check is the site's status notice and whether a normal page view also fails. Report a persistent failure with the URL, time and request identifier. Repeated refreshes add little diagnostic value once the same service-side failure is established.
If the service works elsewhere and your connection uses a custom proxy or VPN, compare another connection permitted by your organization. This can distinguish a local intermediary from the site's serving path. Preserve required workplace network settings and pass the result to the relevant administrator.
For an error after a submission, check whether the intended record exists before repeating the action.
If you manage the gateway or backend
AWS Application Load Balancer documentation lists target resets, invalid response headers and TLS handshake errors among 502 causes. A target closing an outstanding connection can also implicate its keep-alive duration. These are AWS examples, not a universal diagnosis.
Our diagnostic sequence is to correlate one failure across gateway and backend logs. Identify the selected upstream, whether connection establishment succeeded, and whether the response failed during headers or later processing. Compare the failing request with a working request using the same route.
Repair the evidenced layer, then retest through the gateway. A successful backend health check alone does not exercise the original response or routing conditions. Confirm that the public operation succeeds and that gateway errors fall back to the expected baseline.
Sources and review notes
Checked on . Based on MDN, AWS and HTTP retry semantics. AWS causes are platform-specific; tracing a request across components is editorial diagnostic guidance.