Start with the error log
A 502 from Nginx means the proxy received an invalid response or could not use its upstream as expected. Record the affected site, time and request, then inspect the corresponding Nginx error log. A missing socket, permission denial, refused TCP connection and a failing PHP application need different fixes.
Find the active virtual host and its fastcgi_pass target. Check that the intended PHP-FPM pool is running and listening on that exact Unix socket or address. Multiple PHP versions can have different pool paths; changing the wrong pool will not fix the site.
Check access and capacity
For a Unix socket, inspect ownership, mode and the user under which Nginx connects. Consider access-control lists and mandatory access controls where enabled. Avoid making the socket world-writable. If the service is running but requests queue, inspect worker utilization, slow-request evidence and memory headroom.
Look at PHP-FPM and application logs for crashes or startup failures. A PHP upgrade may require extensions or configuration changes; confirm compatibility before switching the production pool.
Validate the correction
Make one change, test the Nginx configuration and PHP-FPM configuration using their supported checks, then reload the relevant service. Request the original page and a representative authenticated operation, and watch both logs.
Keep a rollback path and monitor error rate and worker saturation. Increasing workers without a memory budget can turn an intermittent 502 into an out-of-memory outage.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.