HTTP 504 Gateway Timeout: Causes and Solutions

Intermediate

The HTTP 504 Gateway Timeout error means a proxy or gateway server did not receive a timely response from an upstream server. In CDN architectures, this typically means the CDN edge server waited for the origin to respond, hit its timeout limit, and gave up. Unlike 502 Bad Gateway (where the origin responded with something invalid), a 504 means the origin did not respond at all within the allowed time.

504 errors are often symptoms of deeper performance problems — slow database queries, overloaded application servers, or network issues between CDN and origin. Solving 504s requires both adjusting timeout configurations and addressing the root cause of slow origin responses.

What Causes 504 Errors in CDN Environments?

Slow origin response is the primary cause. When the origin takes longer to respond than the CDN's timeout setting (typically 30-120 seconds), the CDN returns 504 to the client. Common scenarios include heavy database queries, complex page generation, slow third-party API calls, and resource contention under load.

Network issues between CDN and origin can add enough latency to trigger timeouts. This includes congested network links, routing problems, and geographic distance between the CDN edge PoP and the origin server. An origin in a single data center may be 200ms away from CDN PoPs on the other side of the world — eating significantly into the timeout budget.

DNS resolution delays occur when the CDN needs to resolve the origin hostname and the DNS server is slow or unreliable. While CDNs cache DNS lookups, cache misses or TTL expiry can introduce delays that contribute to timeouts.

Connection pool exhaustion happens when the origin has too many active connections and cannot accept new ones. The CDN waits for a connection to become available, eventually timing out. This is common with PHP-FPM (limited worker pool), database connections (limited connection count), and Node.js (event loop blocking).

How Do You Configure Timeouts in Nginx?

Nginx provides three timeout directives for proxy connections, each controlling a different phase of the upstream communication:

# Connection timeout (time to establish TCP connection)
proxy_connect_timeout 10s;   # Default: 60s

# Read timeout (time between two reads from upstream)
proxy_read_timeout 120s;     # Default: 60s — increase for slow origins

# Send timeout (time between two writes to upstream)
proxy_send_timeout 60s;      # Default: 60s

# Complete example for a slow origin
location /api {
    proxy_pass http://backend;
    proxy_connect_timeout 10s;
    proxy_read_timeout 120s;
    proxy_send_timeout 60s;
    proxy_next_upstream error timeout http_504;
    proxy_next_upstream_timeout 30s;
    proxy_next_upstream_tries 2;
}

proxy_connect_timeout controls how long Nginx waits to establish a TCP connection with the upstream. This should be relatively short (5-10s) because TCP connections typically establish in milliseconds. A long connection time indicates the upstream is unreachable or overloaded.

proxy_read_timeout controls how long Nginx waits for a response after sending the request. This is the most commonly adjusted timeout for 504 errors. Set it based on your origin's maximum expected response time plus a safety margin. For dynamic content that requires database queries, 60-120s is common.

proxy_next_upstream tells Nginx to try the next upstream server if the current one times out (504). Combined with proxy_next_upstream_tries, this provides automatic failover for 504 errors.

How Do You Optimize Origin Response Time?

Rather than simply increasing timeouts (which only delays the 504), address the root cause of slow responses:

Database optimization — slow queries are the #1 cause of slow origin responses. Use EXPLAIN to identify missing indexes, avoid SELECT * on large tables, implement query caching, and consider read replicas for heavy read workloads. Set query timeouts at the database level to prevent runaway queries.

Application caching — cache expensive computation results in Redis or Memcached. A database query that takes 5 seconds can be served from cache in under 1ms. Identify your slowest endpoints and cache their results with appropriate TTLs.

Asynchronous processing — for operations that take more than a few seconds (report generation, image processing, data exports), process them asynchronously. Return 202 Accepted with a status endpoint immediately, process in the background, and let the client poll for completion.

CDN caching — the most effective way to prevent 504s is to prevent requests from reaching the origin. Aggressive Cache-Control headers and cache hit ratio optimization reduce origin load significantly. A well-configured CDN can serve 90%+ of requests from cache, reducing origin requests to a manageable level.

How Do CDNs Mitigate 504 Errors?

CDN-specific strategies for 504 mitigation include:

Stale-if-error — the Cache-Control directive stale-if-error=86400 allows CDN edge servers to serve stale cached content when the origin returns 504 or times out. Users see slightly outdated content instead of an error page.

Origin shield — an origin shield consolidates requests from all edge PoPs through a single intermediate PoP. This reduces the number of concurrent requests to the origin, preventing connection pool exhaustion and reducing the probability of 504 timeouts.

Configurable edge timeout — CDN providers allow customizing the edge-to-origin timeout. Cloudflare defaults to 100 seconds (Pro plan) or 600 seconds (Enterprise). Fastly defaults to 60 seconds. Adjust based on your origin's response time characteristics.

Automatic retry — some CDNs automatically retry a timed-out request once before returning 504 to the user. This handles transient timeouts (momentary network glitch, brief origin overload) without user-visible errors.