When your WordPress site on Nginx starts throwing 502 Bad Gateway errors while other non-PHP sites continue working normally, PHP-FPM (FastCGI Process Manager) is likely the culprit. The key indicator is Nginx error logs showing:

connect() failed (111: Connection refused) while connecting to upstream,
client: 127.0.0.1, server: example.com, request: "GET / HTTP/1.1",
upstream: "fastcgi://127.0.0.1:9000"

First verify if PHP-FPM is running:

sudo systemctl status php7.4-fpm  # Adjust version as needed
# or
ps aux | grep php-fpm

If it's crashed, you'll see "inactive (dead)" or no processes in the output.

The standard restart command is:

sudo systemctl restart php7.4-fpm

For more thorough troubleshooting, try this sequence:

sudo systemctl stop php7.4-fpm
sudo pkill -9 php-fpm  # Force kill any remaining processes
sudo systemctl start php7.4-fpm
sudo systemctl status php7.4-fpm

Inspect your PHP-FPM pool configuration (typically at /etc/php/7.4/fpm/pool.d/www.conf):

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.max_requests = 500

Key values to monitor:

• pm.max_children - Set based on available RAM (each child ~30-50MB)
• pm.max_requests - Helps prevent memory leaks by recycling processes

Essential log files for debugging:

# Nginx error log
/var/log/nginx/error.log

# PHP-FPM error log (configured in php-fpm.conf)
/var/log/php7.4-fpm.log

# Slow PHP execution logging
;slowlog = /var/log/php-fpm.log.slow
;request_slowlog_timeout = 5s

Create a watchdog script to automatically restart PHP-FPM when it fails:

#!/bin/bash

RESPONSE=$(curl -I http://localhost/wp-admin/ 2>&1 | grep "502 Bad Gateway")

if [ ! -z "$RESPONSE" ]; then
    echo "$(date) - PHP-FPM crash detected" >> /var/log/php-monitor.log
    systemctl restart php7.4-fpm
fi

Add to cron (runs every 5 minutes):

*/5 * * * * /usr/local/bin/php-fpm-monitor.sh

Add these to your Nginx server block to prevent premature timeouts:

location ~ \.php$ {
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_connect_timeout 300;
    # ... other fastcgi params
}

---

When dealing with 502 Bad Gateway errors in Nginx-PHP setups (especially WordPress), the first diagnostic step is checking the error logs:

# Check Nginx error logs
tail -f /var/log/nginx/error.log

# Common error pattern:
# upstream prematurely closed connection while reading response header from upstream
# connect() failed (111: Connection refused) while connecting to upstream

Depending on your PHP processor implementation, here are the restart commands:

# For PHP-FPM (most common):
sudo systemctl restart php-fpm
# or
sudo service php-fpm restart

# For spawn-fcgi:
sudo killall php-cgi && spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/php-cgi

# For standalone PHP FastCGI:
sudo pkill php-cgi && php-cgi -b 127.0.0.1:9000 &

Create a monitoring script (/usr/local/bin/check_fastcgi.sh):

#!/bin/bash
RESPONSE=$(curl -I http://localhost/wp-admin/ 2>&1 | grep "HTTP/1.1 502")
if [ ! -z "$RESPONSE" ]; then
    logger "FastCGI restart triggered by 502 error"
    systemctl restart php-fpm
fi

Add to cron (every 5 minutes):

*/5 * * * * /usr/local/bin/check_fastcgi.sh

Modify your PHP-FPM pool configuration (/etc/php/7.x/fpm/pool.d/www.conf):

[www]
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500

Ensure proper timeout settings in your Nginx configuration:

location ~ \.php$ {
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_connect_timeout 300;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
}