Quick answer: when Nginx returns 502 Bad Gateway, do not start by randomly changing configuration files. Start with the Nginx error log, then verify that the upstream service is alive, the port or socket is correct, PHP-FPM is running, permissions match, and timeout or process limits are not being hit.

What 502 Bad Gateway Usually Means in Nginx

When Nginx works as a reverse proxy or web entry point, a 502 response usually means Nginx received the client request but failed to get a valid response from the upstream service. That upstream may be PHP-FPM, a Node.js app, a Java service, a Docker container, or another HTTP service configured in an upstream block.

Step 1: Check the Nginx Error Log First

The fastest starting point is the error log. On many Linux hosting panels, common paths look like this:

/www/wwwlogs/example.com.error.log
/www/server/nginx/logs/error.log

If the log shows connect() failed, focus on the backend port, socket path, or service status. If it shows upstream timed out, investigate slow backend responses, timeout settings, and process pool saturation. If it shows permission denied, check socket file permissions and the user running Nginx or PHP-FPM.

Step 2: Verify That the Upstream Service Is Running

If your backend is PHP-FPM, check whether the correct PHP-FPM service is running:

systemctl status php-fpm
systemctl status php8.3-fpm
ps aux | grep php-fpm

On servers with multiple PHP versions, each version may have its own FPM service and configuration directory. If the site uses PHP 8.3, check the PHP 8.3 FPM service rather than the system default PHP binary.

Step 3: Check the Upstream, Port, and Socket

The upstream address in Nginx must match what the backend actually listens on. Common mistakes include using the wrong port, pointing Nginx at a container IP that changed, configuring a TCP port while PHP-FPM is listening on a Unix socket, or using the wrong socket path.

ss -lntp
ss -lx | grep php
curl -I http://127.0.0.1:8080

If you use a Unix socket, confirm that the socket file exists and that the Nginx worker user has permission to access it.

Step 4: Check Whether the PHP-FPM Pool Is Exhausted

For WordPress sites, slow plugins, slow database queries, or a traffic spike can exhaust the PHP-FPM process pool. Nginx may then fail to get a timely backend response, resulting in 502 or 504 errors. Look for messages such as server reached pm.max_children in PHP-FPM logs.

If this is the issue, identify slow plugins, slow SQL queries, or external HTTP calls before increasing pm.max_children. Raising the value blindly can exhaust server memory.

Step 5: Review Timeout Settings

If the log says the upstream timed out, review Nginx proxy or FastCGI timeout settings and PHP execution limits. Common settings include proxy_read_timeout, fastcgi_read_timeout, and max_execution_time.

Timeouts are often symptoms, not root causes. The better question is why the backend is slow: database load, external API calls, plugin overhead, insufficient memory, or CPU saturation.

Recommended Troubleshooting Order

1. Read the Nginx error log and identify the exact upstream error.
2. Confirm that the backend service is running.
3. Verify the upstream address, port, or socket path.
4. Check socket permissions and the Nginx/PHP-FPM runtime users.
5. Check whether the PHP-FPM process pool is exhausted.
6. Review timeout settings and slow backend requests.
7. After changing configuration, run nginx -t before reloading Nginx.

FAQ

Does Nginx 502 Always Mean the Nginx Configuration Is Wrong?

No. Many 502 errors are caused by a crashed backend service, an overloaded PHP-FPM pool, slow database queries, or socket permission problems. Nginx is often only reporting that the upstream did not respond correctly.

Can Restarting Nginx Fix a 502 Error?

Sometimes it may temporarily recover the site, but it does not prove that Nginx was the root cause. If PHP-FPM or the application backend is the issue, restarting only Nginx will not fix the underlying problem.

Where Should I Start on a Hosting Panel Server?

Start with the site-specific error log, then check the PHP version assigned to the site and the matching PHP-FPM service. On servers with multiple PHP versions, checking the wrong FPM service is a common mistake.

Practical Advice

On a production server, do not start by increasing every timeout or restarting every service. Save the error log, identify the time window, and follow a fixed order: logs, backend status, port or socket, permissions, process pool, then timeouts. That process keeps you from hiding the real cause.