What is the difference between 502 and 504

Both errors mean that Nginx could not get a proper response from the backend — PHP-FPM, a Node.js application, or another proxy server. But the causes differ. 502 Bad Gateway means the backend responded incorrectly or the connection dropped. 504 Gateway Timeout means the backend did not respond within the allotted time — it simply took too long to think.

The first diagnostic step is always the same: open /var/log/nginx/error.log and look at the last lines around the moment of the error.

How to read error.log for a 502

Typical lines for a 502 and what they mean:

Log line	Cause
connect() failed (111: Connection refused)	PHP-FPM or the backend is not running, or is listening on a different socket
recv() failed (104: Connection reset by peer)	The backend crashed while processing the request, most often due to low memory
upstream sent too big header	The backend's response headers exceeded the Nginx buffer

Check whether the backend process is even alive: systemctl status php8.3-fpm. If the service crashed, check its own log: /var/log/php8.3-fpm.log.

How to read error.log for a 504

The line upstream timed out (110: Connection timed out) while reading response header from upstream means PHP-FPM accepted the request but did not respond within the time set by proxy_read_timeout or fastcgi_read_timeout. This usually happens because of a slow SQL query, an external API call without a timeout, or a lack of free PHP-FPM workers.

Check the PHP-FPM queue: systemctl status php8.3-fpm | grep -A2 active and the pool status via fpm-status, if it is enabled in the configuration.

How to set timeouts correctly

Timeouts should be raised selectively, only for slow routes, not globally for the entire site:

location /api/export/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_connect_timeout 5s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;
}

For the PHP-FPM connection, the equivalent parameters are called fastcgi_connect_timeout, fastcgi_send_timeout, and fastcgi_read_timeout. The default value is 60 seconds, and raising it above 120 seconds is almost never needed: it is a sign that the slow code should be fixed rather than masked with a timeout.

What to check on the PHP-FPM side

A common cause of both 502 and 504 is exhaustion of the PHP-FPM worker pool. Check the pool settings in /etc/php/8.3/fpm/pool.d/www.conf:

pm.max_children — too low a value creates a queue and timeouts under load
pm.max_requests — periodic worker restart against memory leaks
the slow request log slowlog and request_slowlog_timeout — shows exactly which code is slow

A step-by-step diagnostic checklist

The order of actions when 502 or 504 appears in production:

open error.log and find the exact error line for the time of the incident
check whether the backend process is alive: systemctl status
if the backend is alive, check the queue and slow requests via slowlog
if the problem is a single slow route, raise the timeout selectively for it
if the problem is systemic, increase pm.max_children and add memory monitoring

Summary

502 means the backend responded incorrectly or crashed, 504 means it did not manage to respond in time. In both cases the solution is found not in Nginx, but in the backend's logs and settings. If the errors are related specifically to the Nginx and PHP connection, see the article Nginx and PHP-FPM: sockets, pools, and fastcgi_params, and the basic proxy principles are covered in the article reverse proxy with Nginx.

Nginx 502 and 504 Errors: How to Find and Fix the Cause