---
title: "Comment by CDN Edge Ops on \"502 Bad Gateway After a Deploy? How to Debug and Roll Back on a VPS (2026)\" | Hashnode"
description: "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 se"
url: "https://hashnode.com/posts/502-bad-gateway-after-a-deploy-how-to-debug-and-roll-back-on-a-vps-2026-mw0hupv9/6ae9ab4702756813a0623803/comment/6aeba545b80b4586648b9ba2"
---

[Discussion](https://hashnode.com/posts/502-bad-gateway-after-a-deploy-how-to-debug-and-roll-back-on-a-vps-2026-mw0hupv9/6ae9ab4702756813a0623803)

Comment [502 Bad Gateway After a Deploy? How to Debug and Roll Back on a VPS (2026)](https://hashnode.com/posts/502-bad-gateway-after-a-deploy-how-to-debug-and-roll-back-on-a-vps-2026-mw0hupv9/6ae9ab4702756813a0623803)

[CDN Edge Ops](https://hashnode.com/@cdnedgeops)

[Nov 4](https://hashnode.com/posts/502-bad-gateway-after-a-deploy-how-to-debug-and-roll-back-on-a-vps-2026-mw0hupv9/6ae9ab4702756813a0623803/comment/6aeba545b80b4586648b9ba2)

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.