HTTP 408 request timeout error

What 408 means

HTTP 408 Request Timeout is defined in RFC 9110 as the server deciding to shut down a connection because the client did not deliver a complete request in the time the server was prepared to wait. The precise detail to internalise is that this is about the client being slow to send, not the server being slow to respond. The request line, headers or body arrived too slowly or stopped arriving, so the server abandoned the connection. Because a server that sends 408 is giving up on that connection, it should include a Connection: close header, and browsers commonly treat 408 as safe to retry, since the request was never fully received and processed.

This is why the error log reading step matters: a purposeful 408 from a server you control is a different thing from the client-side timeout codes covered in the connection timed out and connection refused vs timed out articles.

Distinguish 408 from its neighbours

The 503 service unavailable and 504 gateway timeout articles cover the server-side variants. A 408 sits just before those: if the request never completes its trip, the timeout belongs at the request stage.

Find the slow layer

Work out which hop is timing out. Check the access and error logs for the exact line. Body and header timeout settings each have their own knob, and a proxy or load balancer ahead of the origin can time out first:

• Nginx reads the request line against client_header_timeout and the body against client_body_timeout; nginx may log the event and close the connection or return 408 depending on how it is configured.
• Apache's mod_reqtimeout sends an actual 408 response when a read stage is not completed in time.
• A front-end load balancer or proxy with its own read and connect timeouts can return a timeout before the origin even sees the whole request.

Confirm whether the timeout reproduces reliably or only on slow uplinks, and whether it is a single slow header (a large cookie or an auth token) or a large body. A client sending a very large multipart upload over a slow connection is the classic 408 trigger, because the bytes trickle in past the server's configured patience.

Fix and tune

If the client is a user with a slow connection, the honest fix treats the request as too big to reliably send in one shot, so review the 413 payload guidance on chunking or out-of-band uploads for multi-megabyte bodies. If the failure is an API client, check it is actually streaming the request body and is not stalled; many 408s on an API are a client bug (a body never sent) rather than a server limit. Only raise client_body_timeout and client_header_timeout and the equivalent proxy read timeouts after confirming a genuine slow client is being cut off too aggressively. Pair any server-side tightening with the uptime monitoring practice so silent request stalls surface before users do.