Skip to content

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.

Note: 499 never reaches a client: nginx writes it to the log after the client has already gone. Esri's ArcGIS uses the same number for a missing token, so identify the server before interpreting it.

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

A client that hung up before the backend answered

Log

(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.

See also