The short version
- 01Confirm the response is HTTP 408 rather than a browser-only timeout message.
- 02Retry a failed page view once after the connection has recovered.
- 03Compare a small supported upload with the stalled transfer.
- 04Check the saved result before repeating a submission with an uncertain outcome.
- 05Inspect request-header and body-read timing at the server that returned 408.
- 06Retest the transfer after correcting the client or the relevant timeout setting.
Raw message
408 Request Timeout
Likely causes
- The request headers or body did not arrive within the server's waiting period.
- An upload stopped sending data long enough to hit a read timeout.
- A server closed an idle connection opened by the browser in advance.
- A client-to-server timeout is too short for the intended transfer conditions.
The server was still waiting for the request
408 concerns an incomplete incoming request. It is a different stage from 504, where a gateway is waiting for an upstream response. A browser message such as ERR_TIMED_OUT is not proof that an HTTP 408 response was received.
MDN also documents 408 responses on idle connections, including connections a browser opens ahead of navigation. An isolated entry in a server log therefore needs context: establish whether a visible page load or submission actually failed.
If a page or upload times out
Our first comparison is a normal page view versus the action that stalls. Retry the page once when the connection is usable. For an upload, keep the original and test a smaller supported file; note whether the transfer stops before the error appears.
If only one service fails repeatedly, report the action, time and any request identifier. A 408 alone does not prove a file-size limit: 413 covers oversized content. If the outcome of a submitted action is unclear, check the resulting record before submitting again.
If you control the client or web server
For NGINX, client_header_timeout limits receipt of the complete request header. client_body_timeout measures silence between successive body reads, not total upload duration. Check which phase expired before changing either setting.
Our diagnostic sequence is to match the access and error logs to the client transfer, then look for a stalled body producer or interrupted connection. Record when bytes stop arriving. Extending a timeout cannot make a client that stopped sending finish its request.
Use a finite timeout suited to the endpoint and test both a normal transfer and the previously failing one. Confirm that successful uploads reach the application and that abandoned transfers still release their connections.
Sources and review notes
Checked on . Based on HTTP semantics, MDN and NGINX documentation. Transfer comparisons and log-correlation steps are editorial diagnostics; timeout settings depend on the serving stack.