Turkey (Turkish)
Germany (German)
Worldwide (English)
Request flowClient, NGINX, and backend connection break point
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
502 Bad Gateway means that NGINX received the client request but couldn't get a valid response from the upstream server, such as PHP-FPM, Node.js, Python, Docker, or another. This guide separates the service, port, Unix socket, proxy_pass, permissions, and security layers in the correct order.
2026/07/17 03:14:28 [error] 2187#2187: *904 connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) while connecting to upstream
2026/07/17 03:14:28 [error] 2187#2187: *904 connect() failed (111: Connection refused) while connecting to upstreamNGINX produces a 502 when it cannot connect to the backend application service in front, or when the backend returns an invalid or partial response. Therefore, restarting NGINX alone is often not a permanent solution.
The first distinction, whether the error is seen in a single domain or in all applications behind NGINX. A single domain usually refers to a vhost, socket or application service; all domains point to a common PHP-FPM, NGINX, network or resource issue.
In PHP-FPM configurations using Unix sockets, the path, owner, and permissions of the socket file must match the fastcgi_pass line exactly. It is a common issue for the old socket path to remain in the vhost file when the PHP version changes.
If TCP upstream is being used, the target IP and port should actually be listened to. The port may have changed after the container, Node.js, or Python service was restarted, or the service may be connected to a different interface instead of localhost, or the firewall may be blocking the connection.
The 502 on the Cloudflare screen is not the same as the 502 produced by the origin NGINX. First, the origin IP and localhost backend should be tested directly to determine which layer the error started in.
Before increasing the timeout values in 502, it must be proven that the backend is up, on the correct port, and accessible by the NGINX worker user.
Search for the phrase you see in the email, browser, or SSH log. Each card includes meaning, probable cause, and safe initial action.
Meaning: Target IP and port connection is not being accepted.
Possible cause: Backend is closed, wrong port, or service is listening on a different interface.
Meaning: NGINX is using an unavailable socket path.
Possible cause: The PHP-FPM version, pool name, or socket path has changed.
Meaning: Socket exists but NGINX worker cannot access it.
Possible cause: Socket owner, group, mode, or SELinux context is mismatched.
Meaning: No available backends left in the upstream group.
Possible cause: All servers are marked as failed or have a DNS/health issue.
Meaning: Backend closed the connection before completing the response.
Possible cause: Application crash, process kill, memory exhaustion or protocol mismatch.
Meaning: The counter-party has forcibly reset the connection.
Possible cause: Backend restart, application error, or network security layer.
Meaning: Backend did not produce HTTP/FastCGI protocol-compliant header.
Possible cause: Incorrect proxy protocol, faulty application output, or FastCGI port HTTP transmission.
Meaning: The general error in the browser hides the root cause.
Possible cause: Verify the service, socket, port, permission, or application layer
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.
nginx -t
nginx -T | grep -nE 'server_name|proxy_pass|fastcgi_pass'Syntax is tested and active upstream targets are displayed.
systemctl status nginx php8.3-fpm --no-pager
ss -lntp
ss -lxnp | grep -E 'php|fpm'NGINX, PHP-FPM, TCP ports and Unix sockets are verified.
tail -n 150 /var/log/nginx/error.log
journalctl -u nginx -u php8.3-fpm -n 150 --no-pagerNGINX and backend service errors are compared within the same time frame.
curl -sv http://127.0.0.1:3000/ -o /dev/null
curl -skI https://example.com/Reverse proxy behind it tests the service independent of NGINX.
namei -l /run/php/php8.3-fpm.sock
stat /run/php/php8.3-fpm.sock
ps -eo user,group,cmd | grep '[n]ginx: worker'Shows access to all folders in the socket path and the worker user.
nginx -t && systemctl reload nginx
systemctl restart php8.3-fpmNGINX loads continuously; only the backend is restarted when necessary.
Although the root cause of the NGINX error is the same, package paths, service names, security layers and virtual host management vary depending on the Linux distribution or Plesk infrastructure used.
NGINX 502 Bad Gateway for systemd, package path, and journald controls.
systemctl status nginx php8.3-fpm --no-pager
nginx -t
tail -n 100 /var/log/nginx/error.logNGINX 502 Bad Gateway for SELinux, PHP-FPM pool, and RHEL-based service controls.
systemctl status nginx php-fpm --no-pager
nginx -t
tail -n 100 /var/log/nginx/error.logNGINX virtual host files generated by Plesk: nginx 502 bad gateway control.
plesk repair web example.com -y
systemctl status nginx sw-engine --no-pager
nginx -tInstead of randomly restarting the service, proceed by proving that the error occurred at the NGINX, socket, backend, or security layer.
Determine whether a single domain, a single PHP version, or all upstream applications are affected.
for u in https://example.com https://diger.example.com; do curl -sk -o /dev/null -w "$u %{http_code}\n" "$u"; doneClassify the root cause based on the upstream error line, not the browser message.
tail -f /var/log/nginx/error.logVerify that the socket or TCP port target is actually open.
ss -lntp; ss -lxnp | grep -E 'php|fpm'Match the fastcgi_pass or proxy_pass value with the actual server IP address.
nginx -T | grep -nE 'fastcgi_pass|proxy_pass'Check SELinux and firewall blocks for Socket access.
namei -l /run/php/php8.3-fpm.sock; getenforce 2>/dev/nullIf syntax is successful, reload and measure both origin and backend again.
nginx -t && systemctl reload nginx
curl -skI https://example.com/Old PHP-FPM socket path may be left in the vhost file.
grep -R 'fastcgi_pass' /etc/nginx /etc/plesk 2>/dev/nullContainer port, network name, or health status may have changed
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'The PM2/systemd process is stopped or the application is bound to a different port.
systemctl status application --no-pager; ss -lntpExamine socket group/mode or SELinux context mismatch.
stat /run/php/php8.3-fpm.sock; ausearch -m AVC -ts recent | tailDistinguish the Cloudflare layer with direct access to Origin.
curl -skI --resolve example.com:443:ORIGIN_IP https://example.com/Rebuild the generated NGINX/PHP handler configuration for the domain.
plesk repair web example.com -yThe most common reason for not being able to connect to NGINX's PHP-FPM or reverse proxy backend is a wrong socket/port, a stopped service, permission issues, or the application closing the connection prematurely.
If there is an NGINX process issue, it may resolve temporarily or ineffectively if the backend is closed or the fastcgi_pass is incorrect.
502 usually indicates that a connection couldn't be established or an invalid backend response was received; 504 indicates that a connection was established but no response was received in time.
Check the listen value in the PHP-FPM pool files and the output of ss -lxnp. This value should match the NGINX fastcgi_pass line.
Indicates that the target IP/port is not accepting the connection or has been actively blocked. The service, port, and bind address should be checked.
First, check the domain logs and handler settings; then, if necessary, recreate the web configuration for the relevant domain only with plesk repair web domainname -y.
Not always. You can also directly send requests to the origin IP using --resolve and separate Cloudflare and origin NGINX layers
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.