Fix Nginx 502 Bad Gateway with PHP-FPM Socket Connection

Resolve the common Nginx 502 Bad Gateway error caused by misconfigured PHP-FPM UNIX sockets, incorrect permissions, or crashed service workers.


A 502 Bad Gateway error in Nginx indicates that Nginx, acting as a reverse proxy, received an invalid response or no response from the backend application gateway (in this case, PHP-FPM).

If you are running WordPress, Laravel, or any other PHP stack and encounter this error, it almost always points to a socket communication issue.


Symptom & Error Signature

When you inspect the Nginx error logs (usually located at /var/log/nginx/error.log), you will see an entry resembling:

2026/06/27 08:32:15 [crit] 1234#1234: *567 connect() to unix:/run/php/php8.2-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.1.1, server: butitworkedlocal.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "butitworkedlocal.com"

Or:

2026/06/27 08:34:02 [crit] 1234#1234: *580 connect() to unix:/run/php/php8.2-fpm.sock failed (13: Permission denied) while connecting to upstream...

Root Cause Analysis

There are three common reasons for this failure:

  1. PHP-FPM is not running: The socket file /run/php/php8.2-fpm.sock does not exist because the service is crashed or stopped.
  2. Socket Path Mismatch: Nginx is configured to look for the socket at one path (e.g., /run/php/php8.2-fpm.sock), but PHP-FPM is listening on a different socket or TCP port (e.g., 127.0.0.1:9000).
  3. Permissions Issues: The socket file exists, but Nginx (running as the www-data user) does not have read/write access to it.

Step-by-Step Resolution

1. Check if PHP-FPM is Running

Verify the status of your PHP-FPM daemon:

sudo systemctl status php8.2-fpm

If it is stopped or inactive, start it:

sudo systemctl start php8.2-fpm

If it fails to start, inspect the PHP-FPM systemd journal for configuration syntax errors:

sudo journalctl -xeu php8.2-fpm

2. Match the Upstream Socket Configuration

Open your Nginx virtual host configuration (e.g., /etc/nginx/sites-available/butitworkedlocal.com or /etc/nginx/nginx.conf):

sudo nano /etc/nginx/sites-available/butitworkedlocal.com

Look for the fastcgi_pass directive inside your PHP location block. It should point to the socket:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Next, check what socket PHP-FPM is actually listening on. Open the default PHP-FPM pool configuration file:

sudo nano /etc/php/8.2/fpm/pool.d/www.conf

Find the listen directive:

listen = /run/php/php8.2-fpm.sock

[!IMPORTANT] If they do not match, update either Nginx or PHP-FPM so they point to the exact same path. If you change the PHP-FPM configuration, you must restart the service: sudo systemctl restart php8.2-fpm.

3. Fix Socket Permissions

If the log output said Permission denied, Nginx cannot access the socket file. Open the PHP-FPM pool config again:

sudo nano /etc/php/8.2/fpm/pool.d/www.conf

Uncomment or update the following lines to make sure the socket is owned by www-data (the default user for Nginx on Ubuntu/Debian):

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Restart PHP-FPM to apply changes:

sudo systemctl restart php8.2-fpm

4. Test Nginx and Reload

Always test Nginx configurations before reloading to avoid bringing down the entire server:

sudo nginx -t

If the test is successful, reload Nginx:

sudo systemctl reload nginx