499 Client Closed Request
nginx logs 499 when the client disconnects before a response is sent. Esri uses the same number for a missing token.
Status
HTTP/1.1 499 Client Closed Request
Details
- Category: 4xx
- Status: Unofficial (nginx (also Esri: Token Required)). Not registered with IANA. A server, framework, or CDN convention.
- Specification: none, not defined by any RFC
- Cacheable: Not cacheable
- Response body: Must not be sent
- Retry: Safe to retry
In nginx, 499 is a log-only code: the client closed the connection while nginx was still waiting on the upstream, so no response was ever sent. A rise in 499s almost always means backend latency has crossed the client's timeout, and it is a leading indicator of a slow dependency.
Esri's ArcGIS uses 499 to mean a token was required and not supplied, which is unrelated. Identify the server before interpreting the number.
Common causes
- A client or upstream proxy timed out and closed the connection while the backend was still working.
- A user cancelled a request or navigated away.
- A load balancer idle timeout shorter than backend processing time.
- On ArcGIS, a request made with no token.
How to fix it
As the client
- Raise read timeouts to exceed realistic backend latency, and retry idempotent requests.
- Track backend p95 latency and set timeouts above it rather than at an arbitrary round number.
As the server
- Chase backend latency. 499s are a symptom of slow upstreams, not a client defect.
- Align proxy, load balancer, and application timeouts so one of them is clearly authoritative.
Examples
(nginx access log) 203.0.113.5 - - "GET /api/report HTTP/1.1" 499 0 "-" "python-requests/2.32"
Notes for proxy users
When scraping through a proxy, a 499 in the target's logs and a timeout in your client are the same event seen from two sides. If it happens consistently on slow endpoints, raise the client timeout before assuming the proxy is at fault.