What Is the 499 Status Code? (Client Closed Request)

Unlike a normal 4xx, a 499 is recorded after the client has already hung up, so it describes the client's behaviour, not the server's. Nginx introduced the code to distinguish "the caller disconnected" from real server errors. When a request takes longer than your HTTP library's timeout, the library aborts the socket; from the origin's side that looks like a client that closed the request mid-flight, and it logs 499. Cloudflare and other reverse proxies adopted the same convention. Because the response never reaches your code, your scraper typically surfaces this as a timeout/connection-aborted exception rather than a 499 — the 499 lives in the target's logs.

The most common cause is a read timeout set too low for the page you're fetching. Heavy, JavaScript-rendered, or anti-bot-challenged pages can take many seconds to respond; if your client times out at 5–10 seconds you abort early and generate 499s. Other triggers: a proxy that is slow or flaky and stalls the connection, a worker process that is killed (OOM, autoscaling, deploy) while requests are in flight, or cancelling requests in code (an aborted async task, a closed browser tab in a headless run). Overloading a slow origin with high concurrency makes each response slower, which makes your timeouts fire, which produces 499s in bulk.

Start by raising your client read/connect timeouts to comfortably exceed the target's worst-case response time, then retry timed-out requests with exponential backoff and jitter. Lower concurrency so the origin (and your proxy) can answer before your timeouts trip. Audit your proxies — swap out slow or unstable endpoints and prefer reliable residential proxies for protected sites. Make sure workers aren't being killed mid-request by memory limits or aggressive autoscaling. If the origin is genuinely slow because it's challenging you, the real fix is to stop fighting the challenge per-request and use a scraping API that handles the wait and the unblock for you.