Skip to content
novasean.

VPS access and diagnosis

Nginx 502 after PHP-FPM restart on a VPS? Check the service and socket

Diagnose an Nginx 502 after a PHP-FPM or VPS restart by checking the authorised service, FastCGI socket, logs and owner.

By Team Novasean · Published

Confirm what failed after the restart

If an Nginx 502 began immediately after restarting PHP-FPM or rebooting a VPS, first check whether the error affects PHP requests only. Try one affected dynamic URL and one known static file, note the response codes and record the time with its time zone. If a CDN or reverse proxy is involved, identify which layer returned the 502.

Nginx uses fastcgi_pass to connect to a FastCGI server. A 502 means the gateway did not receive a usable response for that request; it does not by itself prove that PHP-FPM is stopped or that the VPS needs more memory. Preserve the matching error before restarting anything again.

Check who is authorised to inspect the VPS

These checks require the correct guest-OS and service permissions. Before running administrative commands, check the order and service terms that apply to this VPS. Hosting, guest operating-system maintenance and application support can have different owners. Do not assume that root access, a managed label or a support request transfers responsibility for your application or authorises a service change.

On Novasean shared hosting, customers should not use VPS service commands. Send the hosting operator the hostname, failing URL, time and visible status instead. On a VPS, follow the steps below only if you administer the guest or the agreed service scope authorises you to do so. The guide to managed VPS access boundaries explains why the accepted order controls who changes which layer.

Find the exact PHP-FPM service unit

Do not guess a unit name from a PHP version shown in a control panel or from an old command. Linux distributions and DirectAdmin installations can run different PHP releases or version-specific PHP-FPM services. An authorised operator can list the installed service units, identify the unit serving the affected site and record its exact name before checking it.

systemctl list-unit-files '*fpm*.service'
systemctl status VERIFIED-UNIT --no-pager
journalctl -u VERIFIED-UNIT --since "30 minutes ago" --no-pager

Replace VERIFIED-UNIT with the service actually mapped to the site, and adjust the time window to include the restart and first failed request. For example, DirectAdmin documents version-specific units such as php-fpm82.service; that is an example, not a default for every server. If the unit or site mapping is unclear, stop and ask the server operator rather than restarting several PHP services.

Compare the FPM listener with Nginx’s upstream

PHP-FPM pool configuration defines a listen address, which can be a Unix socket or a TCP address. Nginx’s effective fastcgi_pass must point to the matching listener. A PHP update, changed pool or generated configuration can leave the two sides referring to different paths or addresses.

Ask the authorised operator to compare the active pool and Nginx configuration with the socket or TCP listener that exists now. Do not create a socket by hand, change ownership, expose a TCP listener publicly or copy a path from another server. A missing socket, permission denial and refused TCP connection point to different checks; none alone justifies increasing a queue or worker limit.

Use the error to choose the next check

Match the Nginx error-log line and PHP-FPM journal entry to the same request time. A “no such file or directory” socket error points towards a missing or mismatched socket path. “Permission denied” calls for a review of the socket’s configured owner and access. A refused TCP connection means the configured endpoint is not accepting the connection. A timeout can involve a busy pool, a slow application or a dependency; it is not proof that a longer global timeout is the right fix.

DirectAdmin’s version 1.689 notes document that PHP-FPM service journals contain FPM configuration and process messages, not PHP code exceptions; logging can vary by installation. If the service is running but the page still fails, the application owner should check the separately configured PHP or application error log for the same time. For a general 502 on shared hosting, use the Nginx 502 guide for shared hosting; it covers the customer/operator hand-off rather than guest-level service commands.

Test a correction before restoring traffic

If you own the VPS service and the evidence identifies a specific configuration fault, preserve the current file and exact error before making one narrow correction. Validate the relevant Nginx or PHP-FPM configuration with the version-matched test command for that installation, then use its documented service procedure. Do not make repeated restarts, raise pm.max_children, loosen socket permissions or extend timeouts without evidence and a rollback path.

After the authorised correction, verify the exact service state and repeat the same PHP request and static-file check. Confirm whether the failure cleared and whether the logs show a new error. If a change fails, restore the known-good configuration or use the agreed recovery owner. The systemd service-status guide covers how to preserve the first failure and compare it with the recovery attempt.

Send a useful support hand-off

If you cannot inspect the guest or the service belongs to the provider, send the hostname, the failed URL with private query parameters removed, the time and time zone, the HTTP status, whether static files still load, and when the restart occurred. Include a short, redacted error excerpt only if you are authorised to read it. Do not send passwords, private keys, session tokens or a full customer-data log.

State whether the issue affects all PHP sites or one application, and note any deployment or PHP-version change immediately before the outage. This helps the responsible operator distinguish a stopped service, listener mismatch and application failure without asking you to change a layer you do not control.

Common questions

Does a 502 prove PHP-FPM is stopped? No. It means the gateway did not receive a usable upstream response. Check the exact service, listener and matching logs before deciding.

Should I restart PHP-FPM again? Not until the unit, site mapping and error are known. Repeated restarts can remove useful evidence and may disrupt other sites or pools.

Is PHP-FPM log output the same as a PHP application error log? No. DirectAdmin notes that its FPM service logs cover service and configuration issues, while application exceptions are recorded separately according to the configured PHP or application logging.

Can I expose the FPM status page or FastCGI port to test it? No. PHP warns that an exposed FastCGI listener can permit unsafe control of request configuration, and an FPM status page can reveal operational details. Use only an existing authorised, access-restricted check.

Sources and technical references

Prepared by Team Novasean from the references above. Menus and available features depend on your installed version and service permissions.

Related guides

Was this guide helpful?

If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .

Need help with your service?

Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.