How to Fix 502 Bad Gateway with Nginx and PHP-FPM

If Nginx returns 502 Bad Gateway with PHP-FPM, the fastest explanation is usually this: Nginx cannot talk to PHP-FPM correctly. That can happen because the service is down, the socket path is wrong, the pool is overloaded, or the timeout is too short.

Start with the shortest path

Check whether PHP-FPM is running:

sudo systemctl status php8.3-fpm

If it is stopped or failed, restart it:

sudo systemctl restart php8.3-fpm

Step 1: Check the Nginx error log

sudo tail -f /var/log/nginx/error.log

This often tells you exactly what is wrong. Common clues include:

connect() to unix:/run/php/php8.3-fpm.sock failed
upstream timed out
No such file or directory

Step 2: Check the socket path

Make sure Nginx points to the same PHP-FPM socket that the pool actually uses.

grep -R "^listen" /etc/php/8.3/fpm/pool.d/
grep -R "fastcgi_pass" /etc/nginx/sites-enabled/

If Nginx points to php8.2-fpm.sock but the server runs php8.3-fpm.sock, you will get a 502.

Step 3: Restart both services after fixing the config

sudo nginx -t
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx

Step 4: Check whether PHP-FPM is overloaded

If PHP-FPM runs but cannot keep up, requests can fail under load. This is where worker limits matter.

Read PHP-FPM Tuning Explained Simply for Small and Medium Projects if you suspect the pool is too small.

Step 5: Look for permission problems

If the socket exists but Nginx still cannot use it, check ownership and permissions.

ls -lah /run/php/

Also confirm the pool settings allow the web server user to access the socket.

Step 6: Check for timeout issues

Some 502 errors happen because PHP is taking too long. This is common with heavy imports, slow external APIs, or bad database queries.

Look for timeout messages in logs and review:

Nginx fastcgi_read_timeout
PHP max execution time
slow queries in your database

Step 7: Test the PHP-FPM config

sudo php-fpm8.3 -t
sudo nginx -t

Common causes of 502 with PHP-FPM

wrong socket path
PHP-FPM service stopped
PHP-FPM crashed after a bad config change
worker exhaustion
request timeout
permissions on the socket or app files

The fastest recovery path in production

check Nginx logs
check PHP-FPM status
verify socket path matches
restart PHP-FPM
reload Nginx

Useful next reads

If you changed the app root recently, also read How to Fix 403 Forbidden After Changing Your Document Root. If permissions look suspicious, go next to How to Set Correct Linux Permissions for Web Projects.

Quick FAQ

Can a bad deploy cause 502?

Yes. A wrong socket path, broken PHP code, bad permissions, or a failed PHP-FPM restart can all trigger it.

Should I reboot the server?

Usually no. Check logs and services first. A reboot can hide the real cause.

Can 502 come from the app itself?

Yes, especially if the app crashes workers, uses too much memory, or triggers long-running requests.