The short version
- 01Confirm that the response is HTTP 504 and capture the failure time.
- 02Check the service's status before repeating a failed page view.
- 03Inspect the resulting record before retrying a timed-out write.
- 04Separate upstream connection time from response-processing time in the logs.
- 05Fix the network or slow operation before adjusting a justified finite timeout.
- 06Verify the same public request completes within the intended time budget.
Raw message
504 Gateway Timeout
Likely causes
- The gateway cannot connect to the upstream before its deadline.
- The upstream accepts the connection but does not respond within the allowed wait.
- A network rule prevents the expected return traffic.
- A response stalls before all expected data arrives.
The gateway's upstream wait expired
504 means a gateway did not receive a timely upstream response needed to complete the request. It does not specify a universal timeout duration. The relevant deadline belongs to the component that generated the response.
408 concerns receiving the incoming request; 504 concerns waiting upstream. Our first comparison is whether the failure happens before an upstream connection is established or after the backend begins work. Those paths call for different evidence.
If a page or operation times out
Check the site's status notice and record the action and approximate wait. If a simple page view keeps failing, report the URL, time and any error identifier. Browser cache deletion does not make a stalled server operation finish.
A timed-out write may still need its outcome checked. Look for the saved record or confirmation before submitting again, and use the service's supported recovery flow when uncertain.
If the same site works through another permitted connection but fails through a custom proxy, report that comparison to the proxy administrator. Keep organization-required networking in place.
If you control the gateway and application
AWS distinguishes a target connection timeout from a connected target that exceeds the idle timeout. Its other examples include blocked return traffic and a response whose declared Content-Length exceeds the bytes sent. Read the gateway's specific reason and timing.
For NGINX, proxy_read_timeout measures the gap between successive upstream reads, not the total duration of a response. Raising it is not a general cure for a slow operation, and another intermediary can still have an earlier deadline.
Our recommended sequence is to trace connection establishment, backend processing and response transfer separately. Locate the slow dependency or blocked path, repair it, and measure the original request again. Change a finite timeout only when the operation's expected duration justifies it.
For long-running work under your control, consider a documented job-and-status workflow instead of keeping a browser request open indefinitely. Verify completion and the user-visible result through the public route.
Sources and review notes
Checked on . Based on MDN, AWS, NGINX and HTTP retry semantics. Timing comparisons and the job-workflow suggestion are editorial guidance; timeout behavior varies by serving layer.