HTTP 408 Request Timeout: Causes and Fixes for Slow Clients

A 408 means the server waited for the client to finish sending its request and gave up. The key point: the delay was on the sending side, not in the server's processing. If the server took too long to respond to a complete request, you want a 504 Gateway Timeout or a timeout in your app instead. The HTTP 408 reference has the definition.

Servers send 408 with a Connection: close header and then drop the connection. Browsers often retry silently, which is why many people only see it in server logs or after a slow upload.

If you are a visitor

1. Reload the page. A single dropped packet or a phone changing towers can leave the request incomplete.
2. Check your connection, then try another network or turn off Wi-Fi to use mobile data.
3. Turn off a VPN or proxy, which can add latency or stall uploads.
4. Retry the upload with a smaller file or compress it first. Large form posts over weak links are the most common trigger.
5. Pause heavy downloads on the same connection while you submit.
6. Try later. If the site is under strain, its limits may be tighter than normal.

If you own the site

1. Slow or stalled clients and short server timeouts

nginx closes the connection and returns 408 when the client does not send the header or body in time. The directives and defaults are documented by nginx:

client_header_timeout 60s;   # waiting for the request header
client_body_timeout   60s;   # time between successive reads of the body
send_timeout          60s;   # sending the response to the client

Raising client_body_timeout for upload endpoints is reasonable, but do it per location. Very long values make you easier to exhaust with slow connections (slowloris-style behavior).

location /upload {
    client_body_timeout 120s;
    client_max_body_size 64m;
}

Apache uses mod_reqtimeout (enabled by default in many builds) to enforce a minimum data rate:

RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

Adjust the values only after you know which phase fails. Check the module is loaded with apachectl -M | grep reqtimeout.

2. Load balancer or proxy idle timeouts

Cloud load balancers close idle connections after a set time. If a keep-alive connection sits idle and the next request arrives just as the balancer or server closes it, the client may see a 408 or reset. Keep the backend keep-alive timeout longer than the balancer's idle timeout. Check your provider's current documentation for the default, since it changes by product. For deeper tuning see nginx 502/504 timeout tuning and load balancer health checks.

3. Pre-connections and browser speculation

Browsers open extra "preconnect" sockets and never use them. Servers that log 408 for these idle sockets produce noise rather than outages. If the 408s in the log have no request line and come from real browsers, it is usually harmless. Look at the pattern: the access log shows "-" 408 with zero bytes sent, as opposed to POST requests failing.

4. Network and MTU problems on the path

Large POSTs that stall at the same size every time, while small requests succeed, point to path MTU or packet-loss trouble between the client and server (often VPNs, tunnels or firewalls). Test from several locations with a request that has a big body, and check that required ports are reachable with the Port Checker. Packet captures on the server help confirm where data stops arriving.

5. A server so overloaded it cannot read requests

When worker threads are all busy, new connections wait in the accept queue and the client's body arrives late. Check CPU, memory and worker limits (worker_connections in nginx, MaxRequestWorkers in Apache). Measure response behavior with the Website Speed Test and review why your site is down.

Find where the time is lost

curl -v --max-time 30 -X POST --data-binary @bigfile.bin https://example.com/upload \
  -w "\nconnect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n"

If the upload itself exceeds your timeout, the cure is chunked or direct-to-storage uploads, not a timeout of several minutes. Confirm the resulting status with the HTTP Status Checker and inspect headers using the HTTP Header Checker. Put the form page under an Uptime Monitor to catch regressions.

Next steps

• Read the HTTP 408 reference.
• Learn about connection failures in connection refused, timed out, reset.
• Compare with 504 Gateway Timeout.
• Check your server with the Website Health Check.

FAQ

Is 408 the same as 504?

No. 408 means the client was too slow sending its request. 504 means a gateway waited too long for an upstream server to reply.

Why do I see 408 in my logs but users report no problem?

Browsers open spare connections that sit idle and are closed by the server. Those 408s are normally harmless.

Should I increase every timeout?

No. Increase only the one that fails, for only the endpoint that needs it. Generous global timeouts help slow-connection attacks.

Does 408 affect SEO?

Only if crawlers hit it repeatedly. Occasional 408s from idle sockets do not matter.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.