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
504 Gateway Timeout, NGINX’s backend was reached but no response header or data was received within the specified time. This guide explains how to find PHP-FPM, database, external API, import, and application bottlenecks without adjusting timeout settings.
2026/07/17 03:22:51 [error] 2190#2190: *1147 upstream timed out (110: Connection timed out) while reading response header from upstream
upstream: "fastcgi://unix:/run/php/php8.3-fpm.sock"504 indicates that NGINX’s upstream target was reached but no timely available response was received. The root cause could be slow PHP code, a locked database, external API, full worker pool, or internal infinite wait.
The 'while connecting to upstream' phrase in the log indicates a problem with delayed backend responses during connection establishment; 'while reading response header from upstream' indicates a problem with delayed backend responses after connection establishment.
proxy_read_timeout and fastcgi_read_timeout do not limit the total processing time, but rather the waiting time between two consecutive reads. Increasing its value may allow some long-running processes to complete, but it will not eliminate the slow query or blocked worker issue.
If long tasks such as WordPress import, WooCommerce report, large backup, video processing, or external API call are executed within an HTTP request, it is more healthy to move them to a queue, cron, or background worker architecture.
If the 504 only occurs during peak hours, investigate PHP-FPM max_children, application worker count, MySQL slow query, CPU load, and disk delay together.
Measure how long it takes for the same request to be sent directly to the backend before increasing the timeout value; wait time should be optimized, not the duration.
Search for the phrase you see in the email, browser, or SSH log. Each card includes meaning, probable cause, and safe initial action.
Meaning: Backend accepted connection but did not produce initial response header within time.
Possible cause: Slow application, DB lock, full worker or external API.
Meaning: TCP/socket connection to backend could not be established within the specified time.
Possible cause: Network, backlog, service density, or unreachable target.
Meaning: Response started but exceeded data flow wait time limit.
Possible cause: Slow stream, large output, or backend hang.
Meaning: There are no idle workers in the PHP-FPM pool.
Possible cause: Insufficient max_children or long-running PHP requests.
Meaning: PHP has reached its execution time limit.
Possible cause: Slow code, large import, or external service wait.
Meaning: Database connection dropped during long process.
Possible cause: Timeout, packet size, restart, or network issue.
Meaning: Browser general timeout page is showing.
Possible cause: Proxy, FastCGI, or upstream response delay.
Meaning: Client request was not completed due to time out.
Possible cause: Slow upload or client connection; upstream 504 should not be confused.
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 -sk -o /dev/null -w 'origin connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n' https://example.com/
curl -s -o /dev/null -w 'backend start=%{time_starttransfer} total=%{time_total}\n' http://127.0.0.1:3000/Shows whether the delay is in front of NGINX or inside the backend.
grep -R "upstream timed out" /var/log/nginx 2>/dev/null | tail -n 100It collects which URL and upstream target has a timeout.
nginx -T | grep -nE 'proxy_(connect|read|send)_timeout|fastcgi_(connect|read|send)_timeout'Include files with actual execution times.
uptime
vmstat 1 5
iostat -xz 1 3 2>/dev/null
free -hMonitors CPU, RAM, run queue, and disk latency.
ps -eo pid,etimes,%cpu,%mem,cmd --sort=-etimes | head -n 30
mysqladmin processlist 2>/dev/null | head -n 50Displays long-running processes and queries.
nginx -t && systemctl reload nginx
curl -skI --max-time 30 https://example.com/After changes, secure reload and result test.
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 504 Gateway Timeout for systemd, package path, and journald controls.
grep -R 'upstream timed out' /var/log/nginx | tail -n 50
systemctl status nginx php8.3-fpm --no-pager
journalctl -u php8.3-fpm -n 100 --no-pagerNGINX 504 Gateway Timeout for SELinux, PHP-FPM pool, and RHEL-based service controls.
grep -R 'upstream timed out' /var/log/nginx | tail -n 50
systemctl status nginx php-fpm --no-pager
journalctl -u php-fpm -n 100 --no-pagerNGINX virtual host files generated by Plesk: nginx 504 gateway timeout control.
grep -R 'upstream timed out' /var/www/vhosts/system/example.com/logs /var/log/nginx 2>/dev/null | tail -n 50
plesk repair web example.com -nFirst, determine whether the delay occurs at the connection, initial response, data transfer, or application-level processing stage.
Log which endpoint is causing the 504, the entire site, or how many seconds it takes for a 504 to occur.
curl -sk -o /dev/null -w '%{http_code} %{time_starttransfer} %{time_total}\n' https://example.com/islemClassify connecting, reading response header, or reading upstream expressions
grep 'upstream timed out' /var/log/nginx/error.log | tail -n 50Send the same request directly to the application port.
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' http://127.0.0.1:3000/islemExamine slowlog, long query, API call, and full worker pool.
ps -eo pid,etimes,%cpu,%mem,cmd --sort=-etimes | head -n 30Set the duration according to the expected time of the task in the narrowest location block.
nginx -T | grep -nE 'proxy_read_timeout|fastcgi_read_timeout'Observe worker and time behavior alongside a single request and several concurrent requests.
for i in {1..5}; do curl -sk -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/islem & done; waitThe import process may be delayed due to PHP time, memory, DB, and external media download.
tail -f wp-content/debug.log /var/log/nginx/error.logLarge tables and lack of indexes can produce slow queries.
mysqladmin processlistUpload timeout and request body limit should be controlled separately.
nginx -T | grep -nE 'client_max_body_size|client_body_timeout'The timeout given by the application to the external service can be longer than NGINX.
curl -v --max-time 15 https://api.example.net/healthExamine worker pool, DB connection limit, and CPU saturation.
uptime; free -h; ss -sBackend is not responding without restart or readiness might be incorrect.
docker stats --no-stream; docker psNGINX can reach the backend but fails to respond within the specified time. Slow PHP, database, external API, full worker queue, or network latency are common causes.
No. It may help if the process is expected to take a long time; but it can only hide slow query, lock, or crashed worker issues.
Measures the waiting time between two consecutive reads from the FastCGI server; does not directly limit the total time of the entire request.
502 mostly indicates a failure to connect to the backend or an invalid response; 504 indicates that a connection was established but no response was received in time.
NGINX error_log, PHP-FPM slowlog, WordPress debug.log and MySQL processlist should be compared within the same time frame.
It should be run independently of HTTP requests if possible, using WP-CLI, cron, queue, or background worker.
Examine max_children, application worker count, DB connection limit, CPU load, RAM, and disk latency together.
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.