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:
- PHP-FPM is not running: The socket file
/run/php/php8.2-fpm.sockdoes not exist because the service is crashed or stopped. - 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). - Permissions Issues: The socket file exists, but Nginx (running as the
www-datauser) 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
