Turkey (Turkish)
Germany (German)
Worldwide (English)
Proxy layerNginx and Apache connection
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
502 and 504 errors on Plesk server mean that the request has reached Nginx or Apache, but PHP-FPM, FastCGI, or the backend service has not responded in time with a healthy response.
502 Bad Gateway
connect() to unix:/var/www/vhosts/system/example.com/php-fpm.sock failed
(11: Resource temporarily unavailable) while connecting to upstream
upstream timed out (110: Connection timed out)502 Bad Gateway indicates that the proxy layer couldn't get a valid response from the backend; 504 Gateway Timeout indicates that the backend didn't respond within the specified time. Both errors seem similar, but the solution should be based on the log messages of socket, timeout, and process.
If only one domain is affected, the PHP handler selection of the related domain, the PHP-FPM pool, the application code, and the records in the /var/www/vhosts/system/domain/logs directory are examined.
If all sites are affected, Nginx, Apache, installed Plesk PHP-FPM services, global RAM, file identifiers, and the last update operations are checked.
php-fpm.sock failed: No such file or directory, which may indicate that the expected socket file for the domain has not been created or the domain is bound to a removed PHP handler.
Even if the service appears to be working, when the resource limit or heavy traffic causes the pool to be full, new requests cannot be forwarded to the back-end. Therefore, restarting alone is not a permanent solution.
Increasing the timeout value is useful for tasks that are truly supposed to take a long time. It should not be used solely to hide the wait time for a slow query, bot attack, or a locked PHP process for a normal page.
Search for the phrase you see in the email, browser, or SSH log. Each card includes meaning, probable cause, and safe initial action.
Meaning: Nginx or Apache failed to retrieve a valid HTTP response from the backend.
Possible cause: PHP-FPM is closed, socket lost, connection refused, or the process terminated abruptly.
Meaning: Proxy, response could not be obtained within the specified time from the backend.
Possible cause: Long-running PHP process, slow SQL query, external API wait, or low proxy timeout.
Meaning: The PHP-FPM socket path cannot be found in the file system.
Possible cause: PHP handler removed, missing pool file or web configuration is outdated.
Meaning: The socket or port is available, but the backend connection has not been accepted.
Possible cause: PHP-FPM service may be stopped, pool crashed or incorrect endpoint used.
Meaning: New connection or process cannot be temporarily separated.
Possible cause: PHP-FPM pool full, process limit high under heavy load or DDoS traffic
Meaning: The concurrent child process limit has been reached in the PHP-FPM pool.
Possible cause: High traffic, slow request, or low pool capacity.
Meaning: Back-end connection established but response header not received in time.
Possible cause: The application, database, or external service is experiencing a delay.
Meaning: The domain is bound to a non-existent or broken PHP handler.
Possible cause: PHP version has been removed, but the domain configuration remains the same
No records matching this expression were found.
Commands are for root access. Collect only status and logs first; Do not change the permanent setting without seeing the reason.
curl -skI https://example.com/
curl -skI https://example.com/test.htmlIt distinguishes whether the problem is a proxy or an application by comparing static and PHP responses.
tail -n 150 /var/www/vhosts/system/example.com/logs/proxy_error_log
tail -n 150 /var/www/vhosts/system/example.com/logs/error_logDisplays Nginx, Apache, and PHP backend messages on a domain basis.
systemctl status nginx --no-pager
systemctl status apache2 --no-pager 2>/dev/null || systemctl status httpd --no-pagerChecks the status of Nginx and Apache services based on distribution.
systemctl list-units --type=service 'plesk-php*-fpm.service' --no-pager
ps -eo pid,user,%cpu,%mem,etime,cmd --sort=-%cpu | grep 'php-fpm' | head -n 30Lists the installed PHP-FPM services and intensive processes.
plesk repair web example.comIt controls the web configuration of the related domain and suggests interactive repair.
free -h
journalctl -k --since '1 hour ago' | grep -Ei 'oom|out of memory|killed process'Shows global memory pressure or kernel OOM event.
tail -n 10000 /var/www/vhosts/system/example.com/logs/proxy_access_log | awk '{print $1}' | sort | uniq -c | sort -nr | headShows whether a single IP or bot group is consuming the pool.
Scope test, log matching, service and handler verification, application performance, and final check should be processed in order.
Test different domains on the same server and static files to isolate single site, single PHP version, or global service failure.
curl -skI https://example.com/In the browser, 502/504 results are unique. The same line in proxy_error_log and error_log nears the root cause, occurring at the same second.
tail -n 150 /var/www/vhosts/system/example.com/logs/proxy_error_logCheck in the Plesk panel if the domain is using an existing FPM handler. If a lost socket exists, re-select the handler and apply it.
If the PHP-FPM pool is full, RAM usage, average process size, and long-running requests should be measured.
ps -eo pid,user,%cpu,%mem,etime,cmd --sort=-%mem | grep php-fpm | headInstead of replacing the entire server for a single domain issue, check the web configuration of the related domain name using Plesk repair.
plesk repair web example.comMonitor HTTP code, service status, new log entries and resource consumption for at least 15 minutes.
curl -skI https://example.com/ && systemctl is-active nginxThe domain's PHP handler, socket file, proxy_error_log and application extensions are examined. Global Nginx restart is not the first option.
plesk repair web example.comNginx, Apache, PHP-FPM services, RAM, and the latest package updates are checked globally.
systemctl --failed --no-pagerNginx proxy timeout or PHP max_execution_time limit may be the case. First, determine why the process is taking so long.
time curl -sk https://example.com/ -o /dev/nullPool capacity, IP addresses sending the most requests, WAF, and rate-limit requirements will be examined.
PHP processes can fill the pool by waiting for the SQL response. MariaDB processlist and IO delay are checked.
mysqladmin processlist
iostat -xz 1 3502 indicates that no valid response was received from the backend, while 504 indicates that the response exceeded the time limit. Although both errors may have the same root cause, the log message shows a different solution layer.
The stuck connection can be temporarily cleared. If the lost PHP socket, full pool or slow application continues, the error repeats.
The selected PHP handler for the domain should be verified and rebuilt via web configuration Plesk to an existing FPM version.
There is no fixed number. It should be determined by calculating the available RAM, the average consumption of a PHP process, and the share of other services.
Control can be increased in report creation-like really long processes. Should not be used to hide slow code or SQL queries on a normal page.
The domain log, PHP-FPM pool, extensions, wp-cron, external API calls, and database queries should be checked.
It checks and re-generates web aspect configuration files; however, a current backup and command output should be obtained before each production server repair.
By analyzing cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim and security layers together, we fix the root cause of the failure instead of just removing the service.