Error reference HTTP status

How to fix 408 Request Timeout

A 408 Request Timeout means the server closed the connection because your client did not deliver a complete request within the server's patience window. It is a client-to-server transmission problem — slow links, stalled uploads, or idle pooled connections — not a sign the site is down. 408s are explicitly safe to retry, and most disappear with connection tuning.

Try clean residential routes All error codes

408 Request Timeout

What 408 Request Timeout means

HTTP 408 is the server saying: a connection was opened to me, but the complete request never arrived in time. Every web server enforces an idle timeout between accepting a TCP connection and receiving the full request line, headers, and body. If your client connects and then stalls — slow network, a large body trickling in, or a connection opened and never used — the server responds 408 and closes the connection.

Do not confuse 408 with its neighbors. A 504 means a server that accepted your request timed out waiting on another server behind it. A client-side timeout (curl error 28, requests.exceptions.Timeout) means your client gave up, not the server. 408 is specifically the server timing out on you while you were still sending.

One quirk worth knowing: clients that hold keep-alive connections open sometimes receive a 408 on an idle connection the server is reaping. Those are harmless — well-behaved clients retry on a fresh connection automatically. Persistent 408s on active requests are the ones worth debugging.

408 Request Timeout

How to fix a 408 error, step by step

Since a 408 means the request was never processed, retrying is safe — start there, then remove the source of the slowness.

Retry on a fresh connection. 408 is defined as retryable, and a large share of 408s are one-off stalls or idle-connection reaping. Add automatic retries with backoff before anything else.
Disable or shorten connection reuse. A pooled keep-alive connection that sat idle past the server's timeout will fail its next request. Configure your HTTP client to discard idle connections sooner than the server does.
Check your upload path for large bodies. A multi-megabyte POST over a slow or lossy link can exceed the server's timers. Compress payloads, split uploads, or raise your sending throughput.
Measure raw latency to the host with curl -w timing output. High connect or start-transfer times point to a slow network path — routing, congestion, or a distant server.
Test with and without the proxy. If direct requests succeed and proxied ones hit 408, the added round trips along the proxy path are pushing you over the server's window — see the next section.
Rule out packet loss and MTU issues. Fragmented handshakes and retransmissions can stall a request long enough to trip server timers; mtr or ping with large payloads will surface loss.
Lower per-connection concurrency. Saturating one connection with multiplexed or pipelined requests can starve an individual request's bytes past the deadline.
If it is your own server, review its timeout configuration (e.g. nginx client_header_timeout and client_body_timeout) before assuming clients are misbehaving.

408 Request Timeout

How proxy routing affects 408s

Every proxy hop adds distance: your request travels to the proxy, then out through an exit IP, then to the target. With residential proxies specifically, exit connections ride on real consumer links whose speed varies — a slow exit can stretch the time it takes your request to fully arrive, and a server with tight timers answers 408.

The fix is rarely to remove the proxy — it is choosing exits deliberately. Rotate away from slow peers, target a country close to the destination server so the final leg is short, and use dedicated-bandwidth products for latency-sensitive work. On ProxyOmega you control all three from the username string, with no code changes required.

Rotate off a slow exit

With rotating residential ports, a stalled request is often just an unlucky exit. Budget Unlimited (/plan-unlimited/) rotates each port on an interval, and a new -session-<id> value gives you a fresh exit immediately — build retries that change the session ID so the retry does not reuse the same slow path.

Buy bandwidth where it matters

If your workload uploads large bodies or calls latency-sensitive APIs, dedicated speed beats pool luck. Premium Unlimited (/plan-premium/) provides dedicated 200 Mbps to 1 Gbps residential lines, and Static ISP (/plan-isp/) gives you one fast, stable US ISP IP for workloads that need a consistent, low-variance path.

Shorten the final leg

Latency compounds per hop. If the target server is in Germany, exiting through a German residential IP keeps the proxy-to-target leg short. ProxyOmega supports country targeting across 200+ countries directly on the username (-country-de), so matching exit geography to server geography is a one-token change — see /locations/ for coverage.

408 Request Timeout

Retry-safe proxied requests in Python

This configuration treats 408 as retryable, rotates the sticky session on each retry so a slow exit is not reused, and sets explicit connect and read timeouts so your client fails fast instead of stalling.

import uuid
import requests

def fetch(url, attempts=4):
    last = None
    for _ in range(attempts):
        session_id = uuid.uuid4().hex[:8]        # new exit on every attempt
        user = f"USERNAME-country-us-session-{session_id}"
        proxy = f"http://{user}:[email protected]:10000"
        try:
            r = requests.get(url,
                             proxies={"http": proxy, "https": proxy},
                             timeout=(10, 60))   # connect, read
            if r.status_code != 408:
                return r
            last = r
        except requests.exceptions.Timeout:
            continue
    return last

print(fetch("https://example.com/").status_code)

FAQ

Frequently asked questions

Is a 408 my client's fault or the server's?

Usually the transmission path between them. The server enforces the timer, but it fires because the complete request did not arrive fast enough — slow links, stalled uploads, idle pooled connections, or a long proxy path. If direct requests work and proxied ones fail, the added path latency is the variable to fix first.

Is it safe to retry a request that returned 408?

Yes. A 408 means the server never processed the request, so retrying cannot double-execute anything — it is one of the few statuses that is safe to retry even for POST. Retry on a fresh connection with modest backoff, and through a rotating proxy, change the session ID so the retry gets a different exit.

What's the difference between 408 and a curl timeout (error 28)?

Direction. curl error 28 means your client gave up waiting under --max-time or --connect-timeout. HTTP 408 means the server gave up waiting for your client to finish sending. They can share a root cause — a slow path — but 408 arrives as a real HTTP response, while error 28 means no usable response arrived at all.

Can rotating proxies cause 408 errors?

Rotation itself does not — each request still travels one path end to end. What can contribute is landing on a slow residential exit for that particular request. The practical answer is retry-with-rotation: a fresh session ID routes the retry through a different exit, and dedicated-speed plans remove the variability for latency-sensitive workloads.

Stop losing requests to slow paths Start routing today.

Rotating residential, dedicated 200 Mbps to 1 Gbps lines, and static ISP IPs — pick the speed profile your workload needs.

Get started