Confirm a real 502 on the intended stack
A 502 means the proxy could not get a usable upstream response; capture the failing request and operator-side error before restarting services.
Identify the failed hostname, URL and time before asking the hosting operator to inspect the upstream. A 502 Bad Gateway means a gateway or proxy could not obtain a usable response from an upstream for that request; it is not the same as an application-generated 500 error. First confirm that this service actually uses Nginx and the relevant upstream, such as PHP-FPM. DirectAdmin supports several web-server and PHP configurations, so a generic Nginx fix is unsafe for an unverified stack.
Check whether the response is intermittent, limited to dynamic PHP routes, or also affects static files. A CDN may show its own 502; identify which layer generated the response before asking the hosting operator to change anything.
Correlate request and error evidence
Retest one failing URL and one static asset, saving their timestamps and status codes. If customer-visible error logs are provided, look for an entry at the same time without changing log levels. Nginx can write error and access logs to configured locations, which vary by installation; the operator can find the effective path and correlate upstream errors with PHP-FPM state and application logs. Send a redacted excerpt or request identifier, not a dump of private customer traffic.
DirectAdmin’s Nginx troubleshooting notes one socket-queue tuning example for Nginx with PHP-FPM. That is a possible operator hypothesis, not a universal customer fix. The log may instead point to a stopped upstream, a socket path mismatch, saturation or another cause.
Distinguish PHP-FPM service faults from PHP code faults
If the effective Nginx error entry names a PHP-FPM upstream, the authorised operator can identify the exact FPM service unit and read its current state and incident-time journal before restarting it. A DirectAdmin installation can have version-specific units such as php-fpm82.service; that name is an example, not an instruction to guess the customer’s unit. The related systemd guide explains how to capture the first failure. Compare the unit state with the Nginx upstream error and the time of the failed request. A running unit does not prove its pool, socket or application request is healthy.
DirectAdmin 1.689 changed the default PHP-FPM service logging to syslog. On a server using that configuration, an operator reads the unit journal with journalctl -u UNIT --since "INCIDENT_TIME" --no-pager, substituting the verified unit and time. Older or customised installations can log elsewhere. These service logs describe FPM configuration and process issues; DirectAdmin explicitly says they do not contain PHP code errors. The application owner and operator should check the separately configured PHP or application error log for exceptions after a deployment. A missing socket, refused connection or pool-capacity warning calls for a different investigation; none alone justifies a blanket increase in workers, queue size or timeouts.
If an FPM status page is already configured, only an authorised operator should inspect it through an access-restricted route. PHP warns that it can reveal request URLs and resource details. Do not enable a public status page or expose the FastCGI listener to the internet to debug a 502.
Use the evidence to choose the owner
If static files succeed but PHP routes return 502, ask the operator to inspect the configured upstream, PHP-FPM availability and matching error messages. The application owner should supply the deployment time and any PHP or plugin change, then test a safe rollback if the issue began with that release. If all routes fail or the response comes from an outer proxy, broaden the operator investigation to that layer. If the application returns its own 500 after the upstream connects, use the separate 500 guide.
Do not raise kernel socket limits, change global worker pools or restart shared services from a customer account. These actions require privileged context and may affect other sites.
For example, a proxy log naming a refused PHP-FPM socket gives the hosting operator a specific upstream to inspect. A refusal can still reflect a crashed process, wrong socket path or permission, so do not guess a restart.
Confirm recovery against the original failure
After the operator’s scoped correction or an application rollback, repeat the same failing request and static comparison. Check the final HTTP status, useful page content, response time and relevant error log interval. A single successful request after a restart may conceal a recurring capacity issue; observe the agreed period and record whether the error returns under normal load. If it does, restore the known-good application state where appropriate and reopen the case with the exact recurrence times.
Frequently asked questions
Does a 502 prove PHP-FPM is down? No. It identifies a gateway/upstream failure path; the actual upstream and error log decide the cause.
Should I increase a timeout? Not from the status alone. A 504 timeout and a 502 response can indicate different failures, and global tuning belongs to the operator.
Sources and technical references
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.