Troubleshooting
Nginx bad gateway: how to troubleshoot a 502
Nginx can be healthy enough to answer the browser while the application behind it is stopped or unreachable. A 502 therefore points toward the connection between the proxy and its upstream more often than toward DNS or the visitor’s browser.
Read both Nginx and upstream logs at the same time
Nginx may report connection refused, timeout, invalid response, or socket permission errors. The application, PHP-FPM, Node process, or other upstream can explain why it was unavailable at that exact moment.
Verify the configured upstream destination
Check the hostname, IP, port, Unix socket path, protocol, and whether the service is listening where Nginx expects it. A deployment can move an application to a new port while leaving the proxy config unchanged.
Check process health and resource failures
An upstream can crash because of memory pressure, a full disk, bad configuration, dependency failure, or application exception. Restarting it may restore traffic, but collect evidence before the restart when possible.
Tune timeouts only when the request should legitimately take longer
Increasing proxy timeouts is not a universal 502 fix. If the upstream is slow because of a bad database query or overloaded worker pool, a longer timeout can make users wait longer without removing the cause.