---
title: "Discussion on \"502 Bad Gateway After a Deploy? How to Debug and Roll Back on a VPS (2026)\" | Hashnode"
description: "Discussion on \"502 Bad Gateway After a Deploy? How to Debug and Roll Back on a VPS (2026)\". You deploy, refresh the page and see 502 Bad Gateway. Users are hitting it too. The worst thing you can do now is start changing things at random over SSH.\nThis post is a playbook: first get the site"
url: "https://hashnode.com/posts/502-bad-gateway-after-a-deploy-how-to-debug-and-roll-back-on-a-vps-2026-mw0hupv9/6ae9ab4702756813a0623803"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [502 Bad Gateway After a Deploy? How to Debug and Roll Back on a VPS (2026)](https://vishvajeetshukla.hashnode.dev/502-bad-gateway-after-a-deploy-how-to-debug-and-roll-back-on-a-vps-2026-mw0hupv9?utm_source=hashnode&utm_medium=feed)

You deploy, refresh the page and see 502 Bad Gateway. Users are hitting it too. The worst thing you can do now is start changing things at random over SSH. This post is a playbook: first get the site

Nov 3 · 5 min read · vishvajeetshukla.hashnode.dev  
Read the article

-   [#nginx](https://hashnode.com/tag/nginx)
-   [#debugging](https://hashnode.com/tag/debugging)
-   [#devops](https://hashnode.com/tag/devops)
-   [#node](https://hashnode.com/tag/node)

## Written by

[Vishvajeet Shukla](https://hashnode.com/@vishvajeetshukla)

@vishvajeetshukla · Jaipur, India

  
[View profile](https://hashnode.com/@vishvajeetshukla)

Full Stack Developer | MERN, Next.js & DevOps

Building Shipown (shipown.com)

## Responses 1

Markdown supported · ⌘↵ to post

[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.