HTTP 499 Client Closed Request: Las 3 Causas Más Comunes Y Cómo Solucionarlo

Te ayudamos a entender el error HTTP 499 Client Closed Request: cuáles son las causas y cómo solucionarlo.

Tabla de contenidos

• ¿Qué es el error 499 Client Closed Request?
• Cómo corregir el error 499 Client Closed Request
  • Error 499 cuando la web está detrás de un proxy
    • La secuencia correcta para configurar los tiempos de espera
  • 499 cuando el servidor cerró la conexión
    • Cómo corregir el error 499 cuando muere tu aplicación
  • 499 cuando tu servidor está bajo un ataque DoS o DDoS
    • Cómo corregir el error 499 cuando sufrimos un ataque DoS/DDoS:
• Todos los Códigos de Estado HTTP

¿Qué es el error 499 Client Closed Request?

El 499 HTTP es un código de estado no estándar introducido por Nginx, y se produce cuando un cliente, por ejemplo un navegador, cierra la conexión mientras Nginx todavía está procesando la solicitud.

Cómo corregir el error 499 Client Closed Request

Hay varias razones por las que el cliente no procesa la petición o «request» y termina mostrándose el código de error 499. En los siguientes apartados te ayudaremos a identificar las diferentes causas y cómo solucionarlo en cada caso.

Error 499 cuando la web está detrás de un proxy

Puedes encontrar errores 499 cuando tienes un servicio de balanceo de carga «Load Balancer» entre tus usuarios y tu Nginx. Una situación similar ocurre cuando tu web servida con Nginx esta trabajando con un CDN o está detrás de un cortafuegos WAF (Web Application Firewall).

El error 499, en este caso, se da cuando el servidor frontal que atiende la solicitud del navegador es un servidor Nginx en modo de proxy inverso «reverse proxy» y envía la solicitud a tu web server, pero el proceso de la página es lento y se supera el tiempo de espera del servidor frontal.

Para corregir este error, puedes:

• Aumentar la capacidad de procesamiento de tu servidor. Al aumentar el «poder de procesamiento», reducirás el tiempo de espera de los proxies Nginx que están por delante de tu server.
• Si no puedes aumentar la potencia de tu servidor, aumenta los tiempos de espera «timeouts» de tus proxies (Load Balancer, CDN, Firewall, …).

En Wetopi puedes aumentar el tamaño de tu servidor con un solo clic.

★ Configuración cero: los archivos de configuración para todos los servicios del servidor se ajustan de forma transparente a la potencia.

La secuencia correcta para configurar los tiempos de espera

Si hay proxies en tu configuración, como un «Load Balancer», un Cortafuegos, un CDN, etc., debes configurar los tiempos de espera para que el «timeut» suceda primero en tu servidor y luego en los otros proxies por orden, según nos acercamos al usuario. De esta manera tendremos un mensaje claro del error que ocurre y en que capa de servicio ocurre.

Ejemplo:

Usuario → CDN → Nginx Load Balancer → Aplicación Nginx → Php_fpm

Se recomienda establecer los tiempos de espera de esta manera:

• n segundos para el tiempo de espera de Php_fpm.
  Configura el php.ini max_execution_time y
  el request_terminate_timeout en el archivo de configuración de php_fpm.

• n+1 segundos para el tiempo de espera de la aplicación Nginx.
  Configura fastcgi_read_timeout en la configuración de nginx.

• n+2 segundos para el tiempo de espera de Nginx Load Balancer
  En el location, donde estás haciendo el proxy_pass, establece los tiempos de espera de:
  proxy_connect_timeout
proxy_send_timeout
proxy_read_timeout
  
• n+3 segundos de tiempo de espera para tu CDN.
  NOTA: Si no puedes configurar los tiempos de espera de tu CDN, investiga cuál es su tiempo de espera y ajusta los demás tiempos de acuerdo con él.

Proporciona una cadena correcta de tiempos de espera.
El establecer una cadena incremental de tiempos de espera te permite encontrar el problema y en que capa de servicio ocurre.

499 cuando el servidor cerró la conexión

Este podría ser tu caso, si:

1. tu web o aplicación se está ejecutando en un servidor Nginx y,
2. la solicitud se pasa por un procesador de aplicaciones «CGI», por ejemplo, php_fpm, o
3. la solicitud se pasa a una API externa.

Este código de error 499 se produce cuando tu servidor es demasiado lento ejecutando código.

por ejemplo, el proceso de tu página de WordPress tarda demasiado o se congela

NOTA: Puedes identificar el caso si en la configuración de Nginx usas la directiva fastcgi_pass.

Para corregir este error, puedes:

• Aumentar la capacidad de procesamiento de tu servidor. Al aumentar el «poder de procesamiento», reducirás el tiempo de espera de tu Nginx.
• Si no puedes aumentar la potencia de tu servidor, aumenta el tiempos de espera de Nginx con la directiva: fastcgi_read_timeout.

★ En Wetopi, tienes configuración cero: los archivos de configuración para todos los servicios del servidor se ajustan de forma transparente a la potencia.

Cómo corregir el error 499 cuando muere tu aplicación

Si tu aplicación muere sin una respuesta, la solución podría estar en el código de tu API, CGI o gestor de contenidos.

NOTA: Este es el caso menos común. PHP y otros procesadores siempre retornan un mensaje notificando el problema. Si la aplicación arrojaba un error, Nginx le pasaría un código de error 5XX, no un 499.

Si tu aplicación se congela, tienes 2 opciones:

• Primero, configura tu Nginx para que espere más. Aumenta los tiempos de espera de tu Nginx modificando fastcgi_read_timeout.
• Si esperar más no resuelve el problema, aumenta la capacidad de procesamiento de tu servidor.
• Si el error 499 se produce en alguna página o petición en concreto, podría tratarse de un bloqueo o «code freeze» en tu aplicación o gestor de contenidos. Si usas WordPress, revisa la compatibilidad de los plugins. Si se realizan consultas a Base de Datos, revisa el buen estado de tablas e índices..

499 cuando tu servidor está bajo un ataque DoS o DDoS

Puede darse el caso en el que alguien ataque e intencionalmente consuma los recursos del servidor. Esto hace que el servidor no pueda procesar las solicitudes y no se sirvan las peticiones a tiempo.

Para verificar si este es su caso: mira en tu herramienta de análisis de «logs» y busca picos en el tráfico con solicitudes que den el código de estado 499:

Cómo corregir el error 499 cuando sufrimos un ataque DoS/DDoS:

En este caso, la mejor solución es una combinación de medidas de seguridad:

• Prevención: evita el tráfico no legítimo. Puedes filtrar el tráfico malicioso con una combinación de listas negras públicas y privadas.
• Agregar protección de infraestructura contra DOS (Denegación de servicio) y DDOS (Denegación de servicio Distribuida). Encuentra un proveedor de alojamiento con infraestructura lista para mitigar este tipo de ataques.
• Añadir una capa de protección, un proxy de seguridad, delante de tu servidor, o
• Contrata un servicio de seguridad externo. Uno muy conocido es Cloudflare. Cloudlare despliega una infraestructura distribuida frente a tu servidor para luchar contra los ataques DDOS.

Como especialistas en WordPress, sabemos lo importante que es disponer de fuertes medidas de seguridad.

Aplicamos tres técnicas para filtrar el tráfico:

Aprendizaje heurístico compartido,
Listas negras de fuentes externas y
Mitigación de ataques DDoS.

¿No tienes una cuenta en wetopi?

Incluye servidores desarrollo Gratis.
Sin tarjeta de crédito.

Todos los Códigos de Estado HTTP