When your proxy waits for a response that never comes
The HTTP 504 Gateway Timeout error occurs when a server acting as a gateway or proxy doesn't receive a response from the upstream server within the allotted time. It's a 5xx family error indicating a server-side problem, specifically in the communication chain between different infrastructure components.
Unlike the 502 Bad Gateway where the backend responds but invalidly, the 504 indicates a complete absence of response within the allocated time. The proxy successfully transmitted the request to the backend, but the backend didn't respond before the timeout was reached. The backend's silence is the problem.
In modern architectures with reverse proxies, CDNs and load balancers, the 504 is a common error that can have various causes: overloaded backend, requests taking too long, network issues, or simply misconfigured timeouts. MoniTao monitors your endpoints and alerts you immediately when 504 errors occur.
The 504 always indicates a response time problem. Here are the most common causes to investigate:
Identifying the component generating the 504 is the first diagnostic step:
Resolution depends on the identified cause. Here are the most effective approaches:
Here are recommended configurations for different components of your stack:
# Nginx - /etc/nginx/nginx.conf
location ~ \.php$ {
fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
fastcgi_read_timeout 300s; # 5 minutes max
fastcgi_send_timeout 300s;
fastcgi_connect_timeout 60s;
}
# For a proxy to HTTP backend
location /api/ {
proxy_pass http://backend;
proxy_read_timeout 300s;
proxy_connect_timeout 60s;
proxy_send_timeout 300s;
}
# PHP-FPM - /etc/php/8.2/fpm/pool.d/www.conf
request_terminate_timeout = 300
# MySQL - Slow query log to identify slow queries
slow_query_log = 1
long_query_time = 2These configurations set a 5-minute timeout, sufficient for most operations. Adjust according to your specific needs. MySQL slow query log helps identify queries to optimize.
MoniTao helps you detect and quickly resolve 504 errors:
The 502 Bad Gateway indicates the backend responded but with an invalid or malformed response. The 504 Gateway Timeout indicates the backend didn't respond at all within the allotted time. The 502 is a response content problem, the 504 is a response time problem.
Cloudflare timeout depends on your plan: 100 seconds (Free/Pro), 600 seconds (Business), up to 6000 seconds (Enterprise). For lower plans, you must optimize your backend or use Cloudflare Workers for long operations.
A 30-second timeout is sufficient for 99% of normal web requests. Beyond that, it's usually a sign of performance problems. For legitimately long operations (exports, reports), provide dedicated endpoints with higher timeouts.
Yes. Google interprets repeated 504s as a sign of unavailability. If Googlebot regularly encounters 504s, it can negatively affect crawling and ranking of your pages.
Test the backend directly without going through the proxy (curl on local IP or socket). If the backend responds correctly directly but not through the proxy, it's a proxy configuration issue. If the backend is slow even directly, it's an application performance problem.
Yes, but with caution. Nginx allows configuring proxy_next_upstream to retry on another backend. However, retrying POST requests can cause duplicates. Reserve automatic retry for idempotent requests (GET, HEAD).
The HTTP 504 Gateway Timeout error signals a response time problem in your infrastructure. The cause is usually an overloaded backend, slow requests, or misconfigured timeouts. Diagnosis involves identifying the faulty component and analyzing response times.
The sustainable solution is to optimize backend performance rather than simply increasing timeouts. MoniTao helps by monitoring not only response codes but also response times, alerting you before performance issues become 504 errors.
Start free, no credit card required.