How to Fix 502 Bad Gateway in Node.js and Nginx (Step-by-Step)

A 502 Bad Gateway error means Nginx is running and accepting your request, but when it tries to forward that request to the upstream application (your Node.js server), it gets back a bad response or no response at all. Nginx itself is fine. The problem is between Nginx and your app.

This is different from a 503 Service Unavailable (the service is explicitly down) and a 504 Gateway Timeout (the upstream responded too slowly). A 502 means the connection was refused, reset, or the upstream sent a response that Nginx could not parse as valid HTTP.

In a typical Node.js stack, Nginx listens on port 80 or 443, receives your request, and forwards it to localhost on whatever port PM2 is running your app on. If that forwarding step fails for any reason, you get a 502. The error always comes from Nginx, not from Node, because Node never got the chance to respond.

The most common cause of 502 is a crashed or stopped Node.js process. Run pm2 list first. If the process status shows errored or stopped, or if the restart count is climbing rapidly, the app has a problem at the Node level and nothing in Nginx can fix it until the app itself is healthy.

Use pm2 logs to see the last output from the process before it crashed. Common things to look for: a missing environment variable causing an undefined reference, a database connection failure at startup, or an EADDRINUSE error meaning another process is already on that port.

After fixing the root cause, restart the app and watch the log output for a few seconds to confirm it stays up before testing the public URL. A process that restarts successfully but then immediately errors again has a startup crash, not a proxy problem.

A very common cause of 502 is a port mismatch: Nginx is configured to proxy to port 3000, but the Node.js app is actually listening on port 3001, or not listening at all. This is straightforward to verify with ss and curl from inside the server.

Run ss -tulpn to list all listening sockets and which process owns them. If nothing is on the expected port, the app is either not running or using a different port. Then run curl directly against that port from the server itself. If curl returns a valid response, the problem is purely in the Nginx proxy_pass — not in the app. If curl returns connection refused, the app is the problem and you should go back to PM2.

The Nginx error log at /var/log/nginx/error.log contains the exact reason for every 502. Do not guess when the log tells you precisely what failed. This is the most valuable diagnostic step and most developers skip it.

The most common 502 message is: connect() failed (111: Connection refused) while connecting to upstream. This means Nginx tried to open a connection to the proxy_pass address and was refused — nothing was listening on that port. Error 111 is the Linux ECONNREFUSED code. Fix: start the app process or correct the proxy_pass port number.

The second most common is: upstream timed out (110: Connection timed out) while reading response header from upstream. This means the app is running and accepting connections but not returning a response within the allowed time window (default 60 seconds). The request is hanging inside Node.js — usually from a slow or blocked database query, an unresolved promise, or a CPU-heavy operation blocking the event loop. Increase proxy_read_timeout as a short-term fix while you find and fix the slow code path.

If the app is healthy and listening on the correct port but you still see 502, the Nginx configuration is the likely cause. The most common mistake is a wrong proxy_pass value — wrong port number, wrong address, or an unintended trailing slash.

A trailing slash on proxy_pass changes how Nginx rewrites the request URI. proxy_pass http://127.0.0.1:3000 passes the full request path to the app unchanged. proxy_pass http://127.0.0.1:3000/ strips the location prefix from the URI before forwarding. For Node.js apps, omit the trailing slash unless you specifically need URI rewriting.

The proxy headers matter too. Missing proxy_http_version 1.1 disables HTTP keep-alive and prevents WebSocket upgrades. Missing X-Forwarded-Proto causes apps that check for HTTPS to see HTTP even on a secure connection, which can trigger redirect loops or authentication errors that Nginx surfaces as 502. Use the complete config below as your starting point.

On a VPS with UFW enabled, port 80 and 443 must be open for external HTTP and HTTPS traffic. However, internal traffic between Nginx and Node on 127.0.0.1 is not subject to UFW rules, so the app port (3000, 5000, etc.) does not need to be open in the firewall — and should not be, since direct external access to your app port would bypass Nginx.

If your Node.js app binds to 127.0.0.1 explicitly, it is only reachable from within the server, which is the correct setup for a proxied deployment. If it binds to 0.0.0.0, it is reachable from any IP. Both work fine for the Nginx proxy — Nginx uses the loopback address regardless. If you are on AWS EC2, also check the security group inbound rules to confirm port 80 and 443 allow 0.0.0.0/0.

Two scenarios produce a 502 that seems mysterious because nothing in the config has changed: immediately after a server reboot, and immediately after a new deployment. Both have specific fixes.

After a reboot: PM2 does not auto-start unless you have run pm2 startup and pm2 save. Without those two commands, the server reboots, Nginx starts and begins accepting traffic, and immediately returns 502 because PM2 has not restarted your app yet. Run pm2 startup once — it prints a system command to run as sudo. Execute that command, then run pm2 save to write the current process list to disk. After the next reboot, PM2 starts your apps automatically before any requests arrive.

After a deployment: 502 usually means the app was restarted before the build completed, or the build failed silently. For Next.js specifically, if npm run build is interrupted or fails, the .next directory is incomplete. The app crashes immediately on startup with a production build error, and PM2 keeps cycling through failed restarts while Nginx returns 502 for every request. Always wait for the full build output to confirm success before running pm2 restart.

When you hit a 502 in production, run these checks in order. Each step eliminates one class of cause. Stop when you find the problem, fix it, and restart in the order shown.

Always reload Nginx with systemctl reload rather than restart when you only change the config — reload applies the new config without dropping existing connections. Use pm2 reload instead of pm2 restart in production to achieve zero-downtime process cycling.