How to Increase Request Timeout in Nginx

A long-running request can fail with 504 Gateway Timeout when NGINX is acting as a reverse proxy and does not receive an upstream response in time. The relevant proxy timeouts default to 60 seconds, but the fix is not always to make every timeout larger. First identify which stage is timing out, then change only the necessary directive at the narrowest practical scope.

The examples below allow a slow upstream response to remain idle for up to 300 seconds and explain why the other timeouts should usually remain much shorter.

Increase Request Timeout in NGINX

For a reverse-proxied application, the three main directives are proxy_read_timeout, proxy_connect_timeout, and proxy_send_timeout. To apply a policy to all proxied virtual hosts, add the directives inside the existing http block, usually in /etc/nginx/nginx.conf:

http {
    proxy_connect_timeout 5s;
    proxy_send_timeout 60s;
    proxy_read_timeout 300s;
}

Do not create a second http block if one already exists. This example allows five minutes between reads from the upstream, but keeps connection establishment short. Setting all three directives to 300 seconds is rarely useful, especially for connection establishment.

For one server or subdomain, place the same directives in its server block instead. For a single slow endpoint, prefer a location so other routes keep their existing failure behavior:

location /slow-report/ {
    proxy_pass http://127.0.0.1:8000;
    proxy_connect_timeout 5s;
    proxy_send_timeout 60s;
    proxy_read_timeout 300s;
}

Add that location inside the appropriate existing server, and adapt proxy_pass to your upstream. Preserve any required headers, access controls, and other existing proxy settings. Values in a more specific server or location override inherited values for the requests they handle.

What each timeout controls

• proxy_read_timeout is usually the directive involved when an application takes too long to respond. It limits the silent interval between two successive reads from the upstream, not the total request duration. A response that regularly sends data can continue longer than the configured value. The default is 60 seconds.
• proxy_connect_timeout limits how long NGINX waits to establish a TCP connection to the upstream. Connection failures should normally surface quickly, so a small value such as 5 or 10 seconds is generally more useful than 300 seconds. A larger value will not repair an unreachable or overloaded upstream.
• proxy_send_timeout limits the interval between two successive writes while NGINX sends the request to the upstream. It can matter for large request bodies or an upstream that stops reading, but it is not the main setting to change when NGINX is merely waiting for a response.

These directives apply to proxy_pass. Other upstream modules have their own settings; for example, a fastcgi_pass application may need fastcgi_read_timeout instead.

Test and reload safely

Validate the configuration, then reload only if the test succeeds:

sudo nginx -t && sudo systemctl reload nginx

A reload gracefully applies valid configuration and is normally preferable to a full restart. On a system without systemd, use sudo nginx -s reload. If the test fails, read the reported file and line, fix the error, and run the test again; do not reload a broken configuration. If a reload fails, inspect sudo systemctl status nginx --no-pager and the recent NGINX service logs.

Diagnose a 504 before increasing anything

Start with the error log at the time of the failed request:

sudo tail -n 100 /var/log/nginx/error.log

A message such as upstream timed out ... while reading response header from upstream points toward the upstream response or proxy_read_timeout. A failure while connecting suggests an upstream address, listener, network, or capacity problem rather than a slow response. Check whether the request reached the application and whether its logs show slow database queries, exhausted workers, CPU or memory pressure, or an application-level timeout.

Also confirm which proxy generated the 504. In a chain containing a cloud load balancer, another reverse proxy, and NGINX, the first layer with an expired timeout can terminate the request even if NGINX is configured correctly.

Check upstream and application timeouts

NGINX is only one deadline in the request path. Application servers, PHP-FPM, application frameworks, databases, HTTP clients, and load balancers may have their own limits. For example, raising NGINX to 300 seconds does not help if the application worker is killed after 60 seconds or an upstream load balancer has a shorter idle timeout.

Map the full request path and give each layer a deliberate, compatible value. Avoid simply copying the largest value everywhere: short connection timeouts still provide fast failure, while application and database limits can protect resources from runaway work.

Avoid blindly huge values

Very large timeouts keep connections, workers, and upstream capacity occupied for longer. On a public endpoint, that can make resource exhaustion and denial-of-service abuse easier. Scope exceptions to the routes that need them, retain authentication and rate limits where appropriate, and monitor upstream resource usage.

A timeout increase is appropriate for a known, bounded operation that legitimately needs more time. It is not a durable fix for an indefinitely hung database or an unbounded job. For work that may take many minutes, consider a background job with a job identifier and polling or webhook completion. Streaming periodic progress can also prevent an idle read timeout when the application architecture supports it.

Common mistakes

• Editing a file that is not included in the active configuration. Use sudo nginx -T to inspect the effective configuration, and review its output before sharing it because configuration can reveal internal paths and hostnames.
• Increasing proxy_send_timeout to fix an upstream that is slow to send a response; that case normally concerns proxy_read_timeout.
• Assuming proxy_read_timeout 300s is a hard five-minute total request limit. It is an inactivity interval between reads.
• Using proxy directives with fastcgi_pass, or changing only NGINX while a shorter upstream timeout still fires first.
• Restarting without running nginx -t, or applying a long timeout globally when one location would suffice.

Conclusion

For a slow reverse-proxied response, proxy_read_timeout 300s is often the relevant change, but 504 diagnosis should come first. Keep proxy_connect_timeout short, adjust proxy_send_timeout only for upstream write stalls, choose the narrowest configuration scope, and check every upstream deadline. Finish with nginx -t and a graceful reload so the change is both effective and safe.