A 502 right after a deploy almost always means nginx still has an upstream that is not accepting connections yet, not that TLS or the vhost suddenly broke. I separate three checks: is the new process listening on the exact host:port in proxy_pass, can nginx resolve that name from its own network namespace, and did the reload pick up a stale upstream block from an unfinished release.
Ops habit that saves rollbacks: keep the previous binary or container tag warm until the new upstream answers a cheap health path from the proxy host. If connect() failed shows in error_log, fix reachability before touching proxy_read_timeout. If upstream timed out, the process is up but slow — raise only that location's read timeout or fix the cold-start path. After rollback or promote, curl the public hostname and the upstream socket separately so a bad Location or wrong Host header does not look like another 502.
A 502 right after a deploy almost always means nginx still has an upstream that is not accepting connections yet, not that TLS or the vhost suddenly broke. I separate three checks: is the new process listening on the exact host:port in proxy_pass, can nginx resolve that name from its own network namespace, and did the reload pick up a stale upstream block from an unfinished release.
Ops habit that saves rollbacks: keep the previous binary or container tag warm until the new upstream answers a cheap health path from the proxy host. If connect() failed shows in error_log, fix reachability before touching proxy_read_timeout. If upstream timed out, the process is up but slow — raise only that location's read timeout or fix the cold-start path. After rollback or promote, curl the public hostname and the upstream socket separately so a bad Location or wrong Host header does not look like another 502.