HTTP 408 Request Timeout: Causes, Examples, and Fixes

An HTTP 408 Request Timeout response indicates that the server did not receive a complete request message within the time that it was prepared to wait.

HTTP 408 at a glance

Status: 408
Phrase: Request Timeout
Class: 4xx Client Error
Specification: RFC 9110 Section 15.5.9
Hop context: Client to receiving web server / reverse proxy
Connection policy: Typically accompanied by Connection: close
Client retry: Safe to repeat without modifications at any later time

What a 408 response tells you

When a client receives an HTTP 408 status code, specific protocol facts are established:

The timeout occurred on the client-to-server hop: The receiving server was actively waiting for the client to finish sending its request headers or payload body, but the configured waiting duration expired.
The server did not execute the request: Because the request message was incomplete, application controllers never began processing the payload.
The request is safe to repeat: According to RFC 9110 Section 15.5.9, the client MAY repeat the request without modifications at any later time.

The crucial distinction: 408 vs 504

One of the most common points of confusion in HTTP debugging is distinguishing between status 408 and status 504:

[Client] ------ 408 Request Timeout ------> [Web Server / Edge]
                                                    |
[Client] <----- 504 Gateway Timeout ------- [Reverse Proxy] ------ (Upstream Server)

HTTP 408 (4xx Client Error): The receiving server gives up waiting for the client to send its request data. The hop is Client -> Server.
HTTP 504 (5xx Server Error): An intermediary gateway or reverse proxy gives up waiting for an upstream backend server to send its response. The hop is Proxy -> Upstream.

For a full comparative breakdown, see our dedicated guide on HTTP 408 vs 504.

What a 408 does not tell you

While an HTTP 408 confirms that the connection timed out before receiving the full request, it does not mean:

The backend database or microservice failed or hung (that would produce a 504 or 500).
The requested URL is invalid or blocked (404 or 403).
The payload format was rejected (400, 413, or 415).

Similar status codes

504 Gateway Timeout

An intermediary server (gateway or reverse proxy) did not receive a timely response from an upstream server needed to complete the request.

502 Bad Gateway

An intermediary server received an invalid or unparseable response from an upstream server.

429 Too Many Requests

The user has sent too many requests in a given amount of time (rate limiting).

For further reference, consult our documentation on HTTP 504 Gateway Timeout and HTTP 502 Bad Gateway.

Diagnostic scenarios

Two common scenarios demonstrate how HTTP 408 errors occur in production:

Scenario 1: Mobile client network stall during large upload

A mobile application attempts to upload a high-resolution photo or video over an unstable cellular network. The client transmits the request headers and initial 50 KB of binary data, but experiences a packet loss burst or cellular tower handoff. The receiving web server waits for the next TCP packet until its client_body_timeout (e.g., 30 seconds) expires, terminates the socket, and returns HTTP 408.

Scenario 2: Truncated HTTP request over persistent keep-alive connection

A custom script or client library opens a raw TCP socket, sends the request line and initial headers, but stalls before sending the terminating double CRLF sequence (\r\n\r\n). The web server’s header buffer timeout triggers, closing the idle socket with status 408.

Common causes of HTTP 408

Slow client upload or stalled payload transmission

The client opened a TCP connection and initiated a request but transmitted headers or body chunks too slowly, exceeding the server body read deadline.

Network latency or dropped packets on client link

High packet loss, mobile network handoffs, or severe bandwidth constraints caused transmission pauses exceeding the web server timeout threshold.

Aggressive server idle or keep-alive timeout configuration

The web server or reverse proxy was configured with an unusually short client body timeout or keep-alive timeout (e.g., 5 seconds) that legitimate slow clients exceed.

Premature socket close or uncompleted chunked transfer

The client halted transmission mid-stream without properly sending the final zero-length chunk terminating a chunked transfer encoding stream.

Headers you may encounter

Connection: close: Servers almost always append this header to indicate that the underlying TCP connection will be terminated immediately.
Content-Type: Typically application/problem+json (RFC 7807) or text/html.
Date: Timestamp when the timeout occurred.

Troubleshooting flow

When troubleshooting an HTTP 408 error, follow this structured diagnostic path:

HTTP 408 Request Timeout
  |
  +-- Is the issue occurring on large file uploads?
        |
        +-- Yes: Check client bandwidth and server client_body_timeout.
        |
        +-- No: Inspect client network stability or persistent socket handling.
              |
              +-- Are mobile users predominantly affected?
                    |
                    +-- Yes: Implement upload chunking and automatic retries.
                    +-- No: Inspect web server keep-alive and header timeouts.

What to check before changing backend code

Before modifying backend application services, inspect the network transport layer:

Measure client uplink bandwidth and check for packet loss between client and edge.
Review web server timeout directives (e.g., NGINX client_body_timeout, client_header_timeout, send_timeout).
Verify if clients use chunked transfer encoding and send data in steady intervals.
Check whether an edge CDN or firewall drops idle TCP sockets prematurely.
Implement client-side retry mechanisms with exponential backoff for idempotent requests.

How to verify the fix

Simulate a slow client upload using curl with rate-limiting (--limit-rate) to verify server timeout thresholds:

curl -i -X POST https://api.example.test/v1/uploads \
  -H "Content-Type: application/octet-stream" \
  --limit-rate 50k \
  --data-binary "@testfile.bin"

Observe whether the server permits slow connections or gracefully returns 408 when limits are exceeded.

Remediation paths to evaluate

If clients operate on poor mobile connections

Implement resumable, chunked upload protocols (such as tus.io or S3 multipart uploads) rather than single monolithic HTTP requests.

If server timeout limits are overly restrictive

Increase client_body_timeout and client_header_timeout in NGINX or Apache configurations to accommodate expected payload transfer times.

If client network sockets stall intermittently

Configure client HTTP clients with connection timeouts, socket timeouts, and automatic retry policies.

FAQ

Can a client retry an HTTP 408 request?

Yes. RFC 9110 Section 15.5.9 states that the client may repeat the request without modifications at any later time. Because the server never received the complete request, no server-side state was changed.

Is HTTP 408 generated by the backend or the web server?

HTTP 408 is typically generated by the first receiving HTTP server (e.g., NGINX, Apache, Envoy, or an edge reverse proxy) that manages the client TCP socket, before the request reaches backend application controllers.

What is the difference between 408 and 504?

HTTP 408 occurs when the server times out waiting for the client to send data. HTTP 504 occurs when an intermediary proxy times out waiting for an upstream backend service to respond.

Key takeaway

HTTP 408 Request Timeout occurs on the client-to-server connection when the receiving server gives up waiting for the client to complete sending its request headers or payload. Verify client upload stability, review server socket timeout settings, and implement chunked or resumable uploads for large payloads.