Código de estado 499: qué significa client closed request en nginx

Qué significa el código de estado 499

499 Client Closed Request es específico de nginx y nunca se ha definido en ningún RFC. Los códigos por encima de 99 y por debajo de 600 están reservados en general para las líneas de estado HTTP, pero el 499 es una convención propia de nginx, que se registra cuando nginx detecta que la conexión del cliente se cayó mientras todavía esperaba la respuesta de la aplicación upstream, o mientras todavía estaba enviando el cuerpo de la respuesta de vuelta al cliente. La forma más habitual en el mundo real es un upstream lento combinado con un cliente, una pestaña de navegador, o un balanceador de carga cuyo propio tiempo de espera es más corto de lo que iba a tardar el servidor, así que el cliente cuelga primero.

Cómo aparece en los registros

Nunca verás el 499 como un código de estado devuelto a ningún cliente, navegador, curl, u otro, porque por definición el cliente ya se ha ido para cuando nginx se lo habría enviado. Solo existe en el propio registro de acceso de nginx:

10.0.0.12 - - [19/Sep/2026:14:02:11 +0000] "GET /api/report HTTP/1.1" 499 0 "-" "python-requests/2.31"

El tamaño de respuesta de 0 bytes y el momento en que ocurre en relación con el tiempo de respuesta conocido de tu upstream son los dos detalles más útiles: un 499 que aterriza de forma constante justo alrededor del tiempo de espera de tu upstream, sin nada enviado de vuelta, apunta directamente a "el backend era demasiado lento y algo se rindió de esperar".

Qué causa un 499

• Una aplicación upstream lenta. El backend tarda más en responder de lo que algún cliente o intermediario está dispuesto a esperar, ya sea una consulta a base de datos lenta, una llamada a una API externa, o un cálculo genuinamente pesado.
• Un tiempo de espera del lado del cliente más corto de lo que necesita el servidor. Una pestaña de navegador cerrada, una app móvil que se rinde ante una conexión inestable, o el propio tiempo de espera de una librería de cliente HTTP disparándose antes de que llegue la respuesta.
• Un balanceador de carga o un proxy upstream que agota su tiempo de espera antes. Si algo se sitúa entre el usuario final real y nginx, su propio tiempo de espera puede disparar una desconexión que nginx registra como 499, aunque el usuario final real nunca haya cancelado nada explícitamente.
• Un usuario que navega a otra página o recarga. Alguien que abandona una página que carga lentamente, o que pulsa recargar con impaciencia, cierra la conexión en curso antes de que nginx haya terminado.
• Valores de tiempo de espera inconsistentes en toda la cadena. Un cliente, un CDN, un balanceador de carga, y el propio nginx pueden tener cada uno un tiempo de espera distinto, y el que sea más corto determina cuándo ocurre la desconexión, sea cual sea la configuración de los demás.

Por qué nunca aparece en un navegador

El 499 no es una respuesta, es una nota que nginx se hace a sí mismo sobre una respuesta que nunca llegó a terminar de enviar. Un usuario cuya pestaña produjo un 499 en tus registros no ve absolutamente nada: ninguna página de error, ningún código de estado, solo una página que dejó de cargar o un indicador de carga que nunca se resolvió, porque no hubo ninguna respuesta que el navegador pudiera renderizar. Esto es exactamente por lo que fiarse de los errores reportados por usuarios se pierde todos estos casos por completo; el único sitio donde un 499 es visible es en el propio registro de acceso del servidor.

Cómo corregir y reducir los 499

No hay un único ajuste que elimine los 499, ya que la causa subyacente es una carrera entre el cliente rindiéndose y el servidor terminando, y la solución depende de qué lado de esa carrera está realmente roto. Empieza por establecer si el upstream es constantemente lento para la ruta afectada, o si las desconexiones se concentran en torno a un cliente, una red, o un intermediario concretos, ya que cada uno apunta a soluciones distintas.

1. Investiga primero el tiempo de respuesta del upstream, ya que un backend lento es la causa subyacente más habitual. Mira cuánto tardaron realmente en el upstream las peticiones afectadas, no solo que nginx registrara un 499.
2. Alinea los valores de tiempo de espera en toda la cadena, de forma deliberada, en lugar de dejar el valor por defecto de cada capa tal cual: el cliente, el CDN, el balanceador de carga, y los propios proxy_read_timeout y proxy_connect_timeout de nginx deberían fijarse con una idea clara de cuál está pensado para dispararse primero.
3. Plantéate proxy_ignore_client_abort si dejar que el upstream termine su trabajo incluso después de que el cliente se desconecte importa para tu aplicación, por ejemplo para completar una escritura que no debería quedarse a medias:

   proxy_ignore_client_abort on;

   Esto no evita la entrada de registro 499 para la desconexión original; cambia si nginx mantiene la petición al upstream en marcha de todos modos.
4. Acelera el propio trabajo del upstream donde la causa raíz sea genuinamente un endpoint lento, ya que ningún ajuste de tiempo de espera arregla por sí solo un backend que tarda demasiado; perfila las consultas o llamadas lentas concretas detrás de la ruta afectada.
5. Trata una tasa creciente de 499 como una señal real, no como ruido de registro a filtrar, ya que normalmente significa que tu aplicación se ha vuelto más lenta o que tu configuración de tiempos de espera está desajustada en algún punto de la cadena.

Cómo evitar que se convierta en una caída

Como el 499 nunca llega al cliente como un error visible, es fácil que un endpoint genuinamente lento pase desapercibido hasta que alguien lea los registros de acceso, incluso mientras usuarios reales abandonan peticiones en silencio. Una comprobación HTTP programada mide el tiempo de respuesta real contra el endpoint directamente y alerta cuando se degrada, detectando la ralentización que está produciendo los 499 antes de que crezca hasta convertirse en peticiones que fallan directamente. La monitorización desde varias ubicaciones también ayuda a separar un backend genuinamente lento de un tiempo de espera que solo se dispara para clientes de una ruta de red concreta.

Errores relacionados

Consulta 504 Gateway Timeout para el equivalente estándar y visible para el cliente cuando es el propio nginx el que se rinde de esperar al upstream en lugar de rendirse primero el cliente, la guía de la familia 4xx para la familia estándar de errores de cliente, y 429 Too Many Requests para un tipo de rechazo distinto ligado a la tasa y no al tiempo.

Preguntas frecuentes

¿Es el 499 un código de estado HTTP real?

No. Es una convención de registro propia de nginx para un cliente que se desconectó antes de que terminara la respuesta, y nunca se envía por la red a ningún cliente ya que el cliente ya se ha ido para cuando se enviaría.

¿Por qué mi herramienta de monitorización nunca ve un 499?

Una comprobación de monitorización es en sí misma un cliente, y si es ella la que se rinde ante una respuesta lenta, va a reportar su propio error de tiempo de espera, no un 499, ya que nunca llega a recibir una respuesta HTTP de la que leer un código de estado. El 499 solo aparece en la propia entrada del registro de acceso del servidor para esa petición.

¿Significa un 499 que mi servidor se cayó?

No. Significa específicamente que el servidor todavía estaba trabajando, o a punto de empezar a trabajar, cuando el cliente se desconectó. Una caída normalmente produciría en su lugar un 502 o un 500, una vez que algo llegara a responder.

¿Puedo detener el procesamiento del upstream cuando un cliente se desconecta?

Por defecto, nginx generalmente deja de esperar al upstream en cuanto el cliente se ha ido, pero el comportamiento exacto depende de tus ajustes de proxy; proxy_ignore_client_abort on le dice a nginx que deje continuar la petición al upstream en lugar de abandonarla.

¿Cuál es la solución más habitual para los 499 frecuentes?

Alinear los valores de tiempo de espera entre el cliente, cualquier proxy o balanceador de carga intermedio, y el propio nginx, combinado con abordar lo que sea que esté haciendo lento al upstream en primer lugar. Ninguna de las dos por sí sola suele resolver un patrón persistente.