504 Gateway Timeout by Layer: nginx, Load Balancer, CDN and App Timeouts

A 504 means a gateway or proxy waited for an upstream server and gave up. Most stacks contain several timers in a row, such as browser, CDN, load balancer, reverse proxy, application server and database. The one with the shortest timeout fires first and produces the error you see. Raising the wrong timer changes nothing, so the useful question is: which layer timed out, and why is the layer behind it so slow?

Generic fixes live in fix 504 Gateway Timeout और nginx 502/504 timeout tuning. The HTTP 504 reference covers the status itself. This page lists where each timer lives.

Step 1: measure how long the request takes before failing

curl -sS -o /dev/null -w "status=%{http_code} total=%{time_total}s\n" https://example.com/slow-endpoint

The elapsed time is a fingerprint. A 504 arriving at almost exactly 60 seconds points to a common 60-second default; one arriving at 30 seconds points to a different layer. Compare the number with the table below, then confirm with headers and logs. The HTTP Header Checker और CDN डिटेक्टर show who responded.

Step 2: known timers by layer

Values below are defaults or typical settings; versions, plans and platform changes alter them, so check current docs for your product.

A 524 on Cloudflare is its own code; see Cloudflare 524: a timeout occurred and the Cloudflare एरर चेकर. Notice that the 60-second group is very common, so a 504 at 60 seconds often means the app is slow, not that the proxy is misconfigured.

Step 3: find the proxy that timed out

Read the log of the layer closest to the user first.

nginx:

upstream timed out (110: Connection timed out) while reading response header from upstream

That line means nginx connected but received nothing within proxy_read_timeout. See nginx upstream timed out. If you see while connecting to upstream, the connect timer fired instead, a network or listening problem rather than a slow query.

Load balancer: check access logs for the target status and request processing time. A target response of - with a 504 from the balancer means the target never answered in time. Review load balancer health checks.

CDN: the response page and headers usually name the CDN. If the CDN's timeout is shorter than your origin's, raising the origin timer will not help until the CDN timer is increased, if your plan allows it.

Step 4: decide whether to raise the timeout or fix the slowness

Raise a timeout only for work that is legitimately long and cannot be shortened. Otherwise, fix the slowness:

1. Slow database queries. Enable the slow query log and check indexes. See MySQL error 2013 lost connection during query when queries are cut off.
2. External API calls inside the request. Add client-side timeouts shorter than the proxy's, with retries off the hot path.
3. Worker starvation. All app workers busy, so requests queue past the timeout. Add workers, or fix blocking calls.
4. Heavy work in the web request. Reports, exports, image processing, imports.

For long operations, return 202 Accepted with a job ID, process in a queue, and let the client poll or receive a webhook. Many cron-style jobs are better watched with cron monitoring than run on page loads.

Step 5: example changes

For nginx proxying to an app on a slow endpoint only:

location /reports/ {
    proxy_pass http://app;
    proxy_read_timeout 180s;
    proxy_send_timeout 180s;
}

For PHP-FPM behind nginx, raise fastcgi_read_timeout and PHP's own max_execution_time together, otherwise the lower limit still fires. For gunicorn, raise --timeout for the worker and the proxy timer together. Then reload and test with the same curl command.

Verify

The slow endpoint returns its status in the new window, the error log shows no new timed out lines, and the timing from curl matches your expectations. Track response time as well as status with an अपटाइम मॉनिटर and the वेबसाइट स्पीड टेस्ट, so a gradual slowdown shows up before it becomes a 504.

अगले कदम

• Read fix 504 Gateway Timeout.
• Compare with CDN vs origin 502 diagnosis.
• सीखें nginx 502/504 timeout tuning.
• Diagnose slowness with website slow diagnosis.

सामान्य प्रश्न

Is a 504 always the server's fault?

It is a server-side or network-side problem between proxies and the origin, not the visitor's. The cause could be a slow app, an overloaded database, or a timeout setting that is too short.

Why do I get a 504 after exactly 60 seconds?

A 60-second default is shared by several products, including nginx, Apache and AWS load balancers. Check each layer's setting to find which one fired.

What is the difference between 502 and 504?

A 502 means the upstream returned an invalid response or the connection failed. A 504 means it did not respond in time.

Should I just set every timeout to a huge number?

No. Long timeouts tie up workers and connections and hide slow code. Increase only where needed, and move long jobs to background processing.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.