HTTP 408 Request Timeout: qué significa y cómo solucionarlo

Qué significa este error y cómo reconocerlo

• Un navegador, cliente de API, herramienta de carga, monitor sintético o comprobador de estado recibe 408 Request Timeout.
• El error puede producirse solo para una URL, método HTTP, cliente, carga o ruta de red, en lugar de afectar a todo el sitio.
• Una solicitud que envía un cuerpo, como una carga de archivo o el envío de un formulario, puede fallar después de que la conexión permanezca abierta sin completarse.
• Las cabeceras de respuesta pueden revelar si la respuesta fue generada por un proxy, CDN, balanceador de carga, WAF o servidor de origen.
• La resolución DNS y la negociación TLS pueden completarse correctamente aunque la solicitud HTTP posterior reciba un 408.
• Los registros pueden mostrar una solicitud incompleta, una conexión inactiva, un timeout de lectura de la solicitud o un timeout generado antes de que la solicitud llegara a la aplicación.

Causas principales, ordenadas por probabilidad

1. El cliente no terminó de enviar la solicitud. Una carga lenta, una conexión bloqueada, una solicitud del navegador interrumpida o un cuerpo de solicitud incompleto pueden superar el tiempo de espera del servidor.
2. Una conexión persistente inactiva expiró. Un servidor o intermediario puede cerrar una conexión keep-alive cuando la siguiente solicitud no llega o no se completa dentro del periodo de inactividad configurado.
3. Un proxy, CDN, balanceador de carga o WAF agotó el tiempo de espera primero. Las distintas capas pueden aplicar límites diferentes para las cabeceras de solicitud, el cuerpo de la solicitud, la inactividad de la conexión o la duración total.
4. La inestabilidad de la red retrasó la entrega de la solicitud. La pérdida de paquetes, una conexión interrumpida o una ruta problemática pueden impedir que el endpoint reciba la solicitud completa.
5. Los detalles de la solicitud activan una regla específica de una capa. Un cuerpo grande, cabeceras inusuales, un patrón de transferencia no compatible o una política específica del método pueden hacer que un intermediario deje de esperar o rechace la ruta de la solicitud.
6. La respuesta se clasificó incorrectamente o fue generada por una infraestructura personalizada. Algunos sistemas usan 408 para una condición de timeout que no corresponde al escenario estándar de solicitud del cliente, por lo que es necesario comprobar el componente que la generó y sus registros.

Cómo solucionarlo

Si estás visitando el sitio

1. Vuelve a intentar la URL exacta una vez después de confirmar que la dirección es correcta.
2. Si estabas cargando un archivo o enviando un formulario, comprueba si la conexión se mantuvo estable y si la operación puede reanudarse de forma segura.
3. Si la solicitud requiere una cuenta, inicia sesión mediante el flujo normal del sitio e inténtalo de nuevo; no vuelvas a enviar repetidamente un formulario o una solicitud de pago sin confirmar si la primera solicitud se completó.
4. Si el error persiste, anota la URL, el método HTTP si lo conoces, la hora aproximada, el tipo de red y la respuesta 408 visible. Envía esos datos al propietario del sitio sin compartir contraseñas, cookies, datos de pago ni claves de API.

Si desarrollas u operas el servicio

1. Captura la solicitud exacta. Registra el método, la ruta de la URL, las características del tamaño de la solicitud, las cabeceras relevantes, si se envió un cuerpo, el estado de respuesta, las cabeceras de respuesta y una marca de tiempo. Redacta las credenciales, cookies, valores de autorización y datos personales.
2. Reproduce las mismas condiciones. Compara una solicitud normal con el método, cliente, tamaño de carga, tipo de conexión y comportamiento del cuerpo de la solicitud que provocan el fallo. Que un GET sencillo funcione no descarta un timeout en un POST, una carga, una solicitud de streaming u otro método.
3. Localiza la capa que generó la respuesta. Comprueba las cabeceras de respuesta y los identificadores de solicitud o de trazado; después, correlaciona la marca de tiempo en los registros de la CDN, el WAF, el balanceador de carga, el reverse proxy, el servidor web y la aplicación. La primera capa que registra el timeout suele ser el mejor punto de partida.
4. Inspecciona la configuración de lectura de solicitudes y de timeout por inactividad. Revisa la configuración relevante del servidor y de los intermediarios para cabeceras incompletas, cuerpos de solicitud lentos, conexiones keep-alive y duración total de la solicitud. Compárala con el comportamiento esperado de las cargas y los clientes de la aplicación.
5. Comprueba la ruta de red y el comportamiento del cliente. Busca reinicios de conexión, pérdida de paquetes, cargas bloqueadas, cambios de proxy o un cliente que abre una conexión pero no termina de enviar la solicitud.
6. Compara los cambios recientes. Revisa los despliegues y cambios en el enrutamiento, la configuración del proxy/CDN, las reglas del WAF, los límites de tamaño de solicitud, el middleware de autenticación y la gestión de conexiones. Trata la autenticación o autorización como una investigación secundaria, salvo que los registros indiquen que la solicitud llegó a esa lógica.
7. Aplica la corrección autorizada más específica. Ajusta únicamente el timeout o la regla de gestión de solicitudes responsable, o corrige el comportamiento del cliente. No desactives ampliamente los controles de seguridad ni aumentes todos los timeouts sin comprender las implicaciones de capacidad y abuso.
8. Vuelve a probar y supervisa. Repite la solicitud original de forma segura, verifica que se devuelve el estado esperado y comprueba las rutas y métodos relacionados. Para solicitudes no idempotentes, utiliza un caso de prueba aprobado o confirma el resultado de la operación antes de reintentar.

Prevención y cómo verificar la solución

• Supervisa las tasas de estados HTTP por ruta, método, tipo de cliente y despliegue para que un timeout específico de una solicitud no quede oculto en una métrica agregada.
• Mantén documentada y bajo control de versiones, cuando sea compatible, la configuración de timeouts de la CDN, el WAF, el balanceador de carga, el reverse proxy, el servidor web y la aplicación.
• Prueba las cargas lentas, las solicitudes incompletas, el comportamiento keep-alive y los métodos de API importantes en un entorno controlado.
• Configura de forma deliberada los timeouts de solicitud y conexión, equilibrando el comportamiento legítimo del cliente con el consumo de recursos y el riesgo de abuso.
• Conserva marcas de tiempo sincronizadas e identificadores de solicitud o de trazado en las distintas capas de red.
• Haz explícito el comportamiento de reintento de los clientes, especialmente para solicitudes no idempotentes como envíos de formularios, pedidos o pagos.
• Conserva suficientes registros y métricas saneados para correlacionar un 408 con el componente que lo emitió.

Preguntas frecuentes