Nginx Returning a 502 Error While the Application Process Is Running

One confusing server problem is getting a 502 Bad Gateway error from Nginx even though your application process appears to be running. You check the server, confirm that Node.js, PHP-FPM, Python, or another application service is active, and still cannot access your website.

This situation often happens when Nginx cannot communicate properly with the application server behind it. The application may be running but listening on the wrong port, using a different socket path, rejecting connections, or taking too long to respond.

The important thing to understand is that a running process does not automatically mean the application is reachable. Nginx must be able to connect to the correct address and receive a valid response.

This guide explains how to identify the cause of a 502 error, test communication between Nginx and your application, and fix common configuration problems without restarting every service unnecessarily.

1. Check the Nginx Error Log First

Before changing your configuration, inspect the Nginx error log. It often reveals exactly why the upstream request failed.

On many Linux systems, you can run:

sudo tail -n 50 /var/log/nginx/error.log

To watch new errors while reproducing the problem, use:

sudo tail -f /var/log/nginx/error.log

Look for messages similar to these:

• connect() failed (111: Connection refused) while connecting to upstream
• connect() to unix:/run/php/php-fpm.sock failed
• upstream timed out
• upstream prematurely closed connection
• no live upstreams

These messages point to different causes. A connection refusal usually means nothing is accepting connections at the configured address. A timeout suggests the upstream is not responding quickly enough. A prematurely closed connection can indicate an application crash, worker failure, or another problem that terminates the response.

Log locations can differ depending on your Linux distribution, container setup, hosting provider, and Nginx configuration. If the file does not exist, inspect your Nginx configuration for the active error_log directive.

2. Verify That the Application Is Listening on the Expected Port

A process can be running without listening on the port Nginx expects. This commonly happens after changing an application's configuration, updating an environment variable, or deploying a new version.

First, check the application service. For example, if it is managed by systemd:

sudo systemctl status myapp

Replace myapp with the actual service name. If the application is running directly through Node.js or another runtime, inspect the relevant process using your system's process tools.

Next, check which ports are listening:

sudo ss -ltnp

This displays listening TCP sockets and, where permitted, the processes associated with them.

Suppose your Nginx configuration contains:

location / {
    proxy_pass http://127.0.0.1:3000;
}

Nginx expects the application to accept connections on port 3000 at the loopback address. If the application actually listens on port 4000, Nginx may return a 502 error even while the process remains active.

Either update the Nginx upstream address to match the application or correct the application's listening configuration. Make sure both services use the intended address and port.

3. Test the Application Directly Without Nginx

One of the most useful troubleshooting steps is to bypass Nginx temporarily and contact the application server directly.

If the application is supposed to listen on port 3000, run:

curl -v http://127.0.0.1:3000/

Check the result:

• Connection refused: The application is not accepting connections at that address and port, or the connection is actively rejected.
• Connection timed out: The request is not receiving a response within the expected time. Check the network path and application logs.
• An HTTP response appears: The application is reachable through that address, so investigate the Nginx configuration and differences between the direct request and proxied request.
• A 500 error appears: The application is reachable, but it is returning an internal server error. Inspect the application's own logs.

A direct response does not prove that every request will succeed. The application might respond to the root URL but fail on a particular route, HTTP method, host header, or large request body.

If your application depends on a specific hostname, test that condition too:

curl -v -H "Host: example.com" http://127.0.0.1:3000/

Replace example.com with your actual hostname. This helps identify applications that behave differently depending on the incoming host header.

4. Check Whether Nginx and the Application Use the Same Address

A common cause of a 502 error is a mismatch between the address used by Nginx and the address on which the application listens.

For example, your application might listen only on the IPv6 loopback address, while Nginx tries to connect to the IPv4 loopback address. Alternatively, a service may listen on a private network interface instead of localhost.

Inspect the application's startup configuration and the relevant Nginx proxy_pass directive.

For an application that listens on IPv4 localhost, this might be appropriate:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

This is an example configuration, not a complete production-ready HTTPS setup. Replace the hostname and port with your actual values, and preserve any existing TLS, security, WebSocket, or application-specific settings.

Do not change the listening address blindly. If the application is intentionally isolated inside a container or private network, configure Nginx to reach it through the correct network instead.

5. Fix Unix Socket Path and Permission Problems

Applications such as PHP-FPM can communicate with Nginx through a Unix socket instead of a TCP port. If Nginx points to the wrong socket path, it may return a 502 error.

For example, a configuration might contain:

fastcgi_pass unix:/run/php/php-fpm.sock;

However, your PHP-FPM service may create a version-specific socket such as:

/run/php/php8.3-fpm.sock

Check which sockets actually exist:

sudo find /run/php -maxdepth 1 -type s -ls

Then inspect the PHP-FPM pool configuration, often found in a directory such as /etc/php/8.3/fpm/pool.d/. The exact path depends on the operating system and installed PHP version.

Make sure the socket path in the Nginx configuration matches the path PHP-FPM creates.

Also check socket permissions and ownership. Nginx must have permission to access the socket. On many systems, the PHP-FPM pool settings include options such as listen.owner, listen.group, and listen.mode.

Do not solve this by setting overly broad permissions such as 777. Configure the correct owner, group, and minimum required permissions instead.

6. Investigate Upstream Timeouts

If the error log contains upstream timed out, Nginx may be able to reach the application but is not receiving a response quickly enough.

Possible causes include:

• A database query taking too long.
• An external API that is slow or unavailable.
• An application worker blocked by another operation.
• Insufficient application workers for incoming requests.
• A large report, upload, or export that takes longer than usual.

Check the application logs and database performance before increasing Nginx timeouts.

For a legitimate long-running request, a location-specific setting might look like this:

location /reports/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 5s;
    proxy_read_timeout 120s;
}

This example gives the upstream connection five seconds and allows up to 120 seconds between successive upstream reads. It does not guarantee that every request will finish within two minutes, and it does not fix a stalled application.

Use longer timeouts only when the workload genuinely requires them. Otherwise, they can cause clients to wait longer while an underlying problem continues.

7. Check Whether the Application Is Crashing or Running Out of Resources

Sometimes the application starts successfully but crashes when it receives a particular request or too many requests arrive at once. Nginx may then report that the upstream connection was closed prematurely.

If your application runs under systemd, inspect its recent logs:

sudo journalctl -u myapp -n 100 --no-pager

To inspect system-level messages that may reveal memory pressure or process termination, you can also use:

sudo journalctl -k -n 100 --no-pager

Look for out-of-memory events, worker crashes, application exceptions, and repeated service restarts.

Check the server's available memory and current resource usage as well:

free -h
uptime
ps aux --sort=-%mem | head

If the application is repeatedly being terminated because of memory exhaustion, increasing Nginx timeouts will not fix the underlying issue. You may need to address a memory leak, reduce the application's resource requirements, tune worker counts, or provide additional capacity.

8. Check Docker Networking When the Application Runs in a Container

Docker introduces another common source of 502 errors: Nginx may be using an address that works on the host but not from inside its own container.

For example, if Nginx runs in one container and Node.js runs in another, this configuration may be incorrect:

proxy_pass http://127.0.0.1:3000;

Inside the Nginx container, 127.0.0.1 refers to the Nginx container itself, not the Node.js container.

If both containers share a Docker network, Nginx can often reach the application using its service name. For a Compose service named app, the upstream could look like this:

location / {
    proxy_pass http://app:3000;
}

The service name and port must match your actual Docker Compose configuration. Both containers must be attached to a network that allows them to communicate.

Useful diagnostic commands include:

docker compose ps
docker compose logs nginx
docker compose logs app

Replace nginx and app with the actual service names in your Compose file. If necessary, test connectivity from inside the Nginx container using a diagnostic tool available in that container.

9. Validate the Configuration Before Reloading Nginx

After changing the configuration, test it before applying the changes:

sudo nginx -t

If the test succeeds, reload Nginx:

sudo systemctl reload nginx

On systems using a different service manager or container deployment, use the appropriate method for applying the configuration. If the configuration test fails, fix the reported error before reloading.

Afterward, repeat the original request and check the Nginx error log again. If the 502 error remains, confirm that the active server block is the one you edited and that no other upstream configuration is handling the request.

Common Mistakes to Avoid

• Restarting every service immediately: Inspect the logs and test the upstream first so you do not lose useful diagnostic information.
• Assuming a running process is reachable: Verify the actual listening port, socket, and network path.
• Changing permissions to 777: Correct the socket ownership and permissions instead.
• Increasing timeouts without investigating: A timeout may indicate a slow database, blocked worker, or external dependency.
• Using localhost incorrectly in Docker: Remember that localhost refers to the current container's own network namespace.
• Editing the wrong Nginx configuration: Check which configuration file and server block are actually active.

Conclusions

A 502 Bad Gateway error does not necessarily mean your application process has stopped. It means Nginx has failed to obtain a valid response from the upstream for that request.

Start with the Nginx error log, verify the application's listening address, and test the upstream directly with curl. Then investigate socket permissions, network configuration, slow requests, application crashes, and container networking according to the error message.

Once you identify where communication breaks down, you can fix the actual cause instead of repeatedly restarting services or changing settings that have nothing to do with the problem.