Nginx 502 Bad Gateway on WordPress: Diagnosing a PHP-FPM Crash

A 502 Bad Gateway on a WordPress server running Nginx means Nginx received no usable response from PHP-FPM, the process actually running your PHP code. Nginx itself is fine; the problem sits one layer behind it. Restarting PHP-FPM often clears the symptom for a few minutes, which is exactly why the same 502 keeps coming back, since restarting fixes nothing about why PHP-FPM failed in the first place.

Confirm it is actually PHP-FPM and not something else

Check Nginx's own error log first, since it usually names the upstream directly:

tail -100 /var/log/nginx/error.log

Look for lines mentioning upstream sent too big header, connect() failed, or recv() failed while reading response header from upstream. Each points to a different cause, so read the specific wording rather than assuming every 502 is the same failure.

Cause 1: PHP-FPM ran out of worker processes

Under a traffic spike, PHP-FPM's pm.max_children limit can be reached, leaving new requests with nowhere to go until a worker frees up. Check the PHP-FPM pool log for this specific signal:

tail -100 /var/log/php-fpm/www-error.log
grep "max_children" /var/log/php-fpm/www-error.log

A log entry stating the server reached pm.max_children confirms this cause directly. The fix is not simply raising the number blindly, since each worker consumes real memory and an oversized pm.max_children on a small server invites the OOM killer instead. Calculate it from available RAM divided by average worker memory use, verified with:

ps --no-headers -o "rss,cmd" -C php-fpm | awk '{sum+=$1} END {print sum/NR/1024 " MB avg"}'

Cause 2: a single slow request exceeded the upstream timeout

If only specific pages 502, usually ones doing a large query, an external API call, or a heavy plugin action, PHP-FPM may simply be taking longer than Nginx is willing to wait:

location ~ \.php$ {
    fastcgi_pass unix:/var/run/php-fpm/www.sock;
    fastcgi_read_timeout 60s;
}

Raising fastcgi_read_timeout helps only if the underlying request is legitimately slow and cannot be sped up. If a specific plugin or query is the actual cause, our guide on reducing CPU usage on servers covers finding and fixing the process actually consuming the time, which is the more durable fix than extending timeouts indefinitely.

Cause 3: PHP-FPM was OOM killed

On memory constrained servers, the kernel's OOM killer terminates PHP-FPM workers directly when memory runs out, and every in-flight request 502s at once. Confirm with:

dmesg | grep -i "killed process"
journalctl -k | grep -i "oom"

If PHP-FPM workers are the target, the fix is reducing pm.max_children to a sustainable number for available RAM, or adding memory, not increasing timeouts or restarting the service, since restarting only delays the next OOM event under the same load.

Cause 4: the Unix socket or port PHP-FPM listens on is misconfigured

A 502 with connect() failed (111: Connection refused) in the Nginx log usually means Nginx is pointing at a socket or port PHP-FPM is not actually listening on, often after a PHP version change or a pool configuration edit:

grep "listen" /etc/php-fpm.d/www.conf
ls -la /var/run/php-fpm/

Confirm the socket path in the PHP-FPM pool configuration matches exactly what Nginx's fastcgi_pass directive points to, including ownership and permissions on the socket file itself, since a permissions mismatch produces the identical connection refused error.

Cause 5: it correlates with a load spike, not a configuration problem

If 502s appear specifically during traffic spikes and disappear once traffic drops, the server may simply be resource constrained for its actual traffic level rather than misconfigured. Our guide on finding the exact cause of high load on a cPanel server covers isolating which process or site is driving the load before deciding whether the fix is configuration, caching, or more resources.

Set up alerting before the next spike

A 502 that only shows up during a traffic spike at 2am is much easier to diagnose with monitoring already in place than by reconstructing what happened from logs after the fact. Our server performance monitoring guide covers what to track so the next spike shows up as a graph, not a support ticket.

Putting it together

A 502 Bad Gateway on Nginx is always a PHP-FPM problem one layer behind the visible error, and the fix depends entirely on which of worker exhaustion, a slow request, an OOM kill, or a socket misconfiguration actually caused it. Read the Nginx and PHP-FPM logs together rather than restarting services and hoping, since the same 502 will return under the same conditions if the underlying cause was never addressed.

iServerSupport provides server optimization services including PHP-FPM tuning, Nginx configuration and load investigation, so a recurring 502 gets traced to its real cause and fixed rather than temporarily cleared with a restart.