Deployment rescue guide

Fix Nginx 502 Bad Gateway without guessing

VPSNext.js

Short answer

Nginx proxies to a healthy app process, logs show the real failure, and the domain returns the app instead of a gateway error.

Why this matters

The domain opens, Nginx responds, but every request ends in 502 while the app seems fine locally.

Walkthrough

01
Check whether the app is alive
Do not start with Nginx config. First confirm the upstream app is running and listening where Nginx expects it.
- Check process status in PM2, systemd, Docker, or your supervisor.
- Curl the app from the VPS using localhost and the expected port.
- Read app logs for crashes caused by missing env vars or build files.
02
Verify the proxy target
The most common 502 is a mismatch between Nginx `proxy_pass` and the actual app port or socket.
- Confirm the app port matches `proxy_pass` exactly.
- Avoid proxying to `0.0.0.0`; use `127.0.0.1` or a socket.
- Reload Nginx only after `nginx -t` passes.
03
Find the real error in logs
Nginx error logs usually tell you whether the upstream refused, timed out, or returned invalid headers.
- Use `/var/log/nginx/error.log` for proxy errors.
- Use app logs for runtime crashes and env failures.
- Check firewall rules only after local curl fails.

Where RepoAssistant fits

If the 502 is blocking launch, RepoAssistant can diagnose the server, fix the upstream, and ship the app.