HTTP 408 Request Timeout: o que significa e como corrigir

O que este erro significa e como reconhecê-lo

• Um navegador, cliente de API, ferramenta de upload, monitor sintético ou verificador de integridade recebe 408 Request Timeout.
• O erro pode ocorrer apenas para uma URL, método HTTP, cliente, upload ou caminho de rede, e não em todo o site.
• Uma solicitação que envia um corpo, como um upload ou envio de formulário, pode falhar depois que a conexão permanece aberta sem ser concluída.
• Os cabeçalhos de resposta podem revelar se um proxy, CDN, balanceador de carga, WAF ou servidor de origem gerou a resposta.
• A resolução de DNS e a negociação de TLS podem ser concluídas mesmo quando a solicitação HTTP subsequente recebe um 408.
• Os logs podem mostrar uma solicitação incompleta, uma conexão ociosa, um timeout de leitura da solicitação ou um timeout gerado antes de a solicitação chegar à aplicação.

Causas principais, por probabilidade

1. O cliente não terminou de enviar a solicitação. Um upload lento, uma conexão travada, uma solicitação interrompida pelo navegador ou um corpo de solicitação incompleto podem exceder o período de espera do servidor.
2. Uma conexão persistente ociosa expirou. Um servidor ou intermediário pode fechar uma conexão keep-alive quando a próxima solicitação não chega ou não é concluída dentro do período de inatividade configurado.
3. Um proxy, CDN, balanceador de carga ou WAF atingiu o timeout primeiro. Camadas diferentes podem aplicar limites distintos para cabeçalhos da solicitação, corpo da solicitação, inatividade da conexão ou duração total.
4. A instabilidade da rede atrasou a entrega da solicitação. Perda de pacotes, uma conexão interrompida ou um caminho problemático podem impedir que o endpoint receba a solicitação completa.
5. Os detalhes da solicitação acionam uma regra específica da camada. Um corpo grande, cabeçalhos incomuns, um padrão de transferência não compatível ou uma política específica do método podem fazer um intermediário parar de esperar ou rejeitar o caminho da solicitação.
6. A resposta foi classificada incorretamente ou gerada por uma infraestrutura personalizada. Alguns sistemas usam 408 para uma condição de timeout que não corresponde ao cenário padrão de solicitação do cliente; por isso, é necessário verificar o componente que produziu a resposta e seus logs.

Como corrigir

Se você está visitando o site

1. Tente acessar a URL exata novamente uma vez, depois de confirmar que o endereço está correto.
2. Se você estava fazendo upload de um arquivo ou enviando um formulário, verifique se a conexão permaneceu estável e se a operação pode ser retomada com segurança.
3. Se a solicitação exigir uma conta, faça login pelo fluxo normal do site e tente novamente; não reenvie repetidamente um formulário ou uma solicitação de pagamento sem confirmar se a primeira solicitação foi concluída.
4. Se o erro persistir, registre a URL, o método HTTP, se conhecido, o horário aproximado, o tipo de rede e a resposta 408 visível. Envie esses detalhes ao responsável pelo site sem compartilhar senhas, cookies, dados de pagamento ou chaves de API.

Se você desenvolve ou opera o serviço

1. Capture a solicitação exata. Registre o método, o caminho da URL, as características do tamanho da solicitação, os cabeçalhos relevantes, se um corpo foi enviado, o status da resposta, os cabeçalhos da resposta e um registro de data e hora. Oculte credenciais, cookies, valores de autorização e dados pessoais.
2. Reproduza as mesmas condições. Compare uma solicitação normal com o método, cliente, tamanho do upload, tipo de conexão e comportamento do corpo da solicitação que falharam. Uma GET simples bem-sucedida não exclui um timeout em uma POST, em um upload, em uma solicitação de streaming ou em outro método.
3. Localize a camada que produziu a resposta. Verifique os cabeçalhos da resposta e os identificadores da solicitação ou do trace; depois, correlacione o horário nos logs da CDN, do WAF, do balanceador de carga, do proxy reverso, do servidor web e da aplicação. A primeira camada que registra o timeout geralmente é o melhor ponto de partida.
4. Inspecione as configurações de leitura da solicitação e de timeout de inatividade. Revise as configurações relevantes do servidor e dos intermediários para cabeçalhos incompletos, corpos de solicitação lentos, conexões keep-alive e duração total da solicitação. Compare-as com o comportamento esperado de upload e do cliente pela aplicação.
5. Verifique o caminho de rede e o comportamento do cliente. Procure resets de conexão, perda de pacotes, uploads travados, alterações de proxy ou um cliente que abre uma conexão, mas não termina de enviar a solicitação.
6. Compare alterações recentes. Revise deploys e alterações no roteamento, nas configurações de proxy/CDN, nas regras do WAF, nos limites de tamanho da solicitação, no middleware de autenticação e no tratamento de conexões. Considere autenticação ou autorização como uma investigação secundária, a menos que os logs mostrem que a solicitação chegou a essa lógica.
7. Aplique a correção autorizada mais específica. Ajuste apenas o timeout ou a regra de tratamento de solicitações responsável, ou corrija o comportamento do cliente. Não desative amplamente os controles de segurança nem aumente todos os timeouts sem entender as implicações de capacidade e abuso.
8. Teste novamente e monitore. Repita a solicitação original com segurança, verifique se o status esperado é retornado e confira rotas e métodos relacionados. Para solicitações não idempotentes, use um caso de teste aprovado ou confirme o resultado da operação antes de tentar novamente.

Prevenção e como verificar a correção

• Monitore as taxas de status HTTP por rota, método, tipo de cliente e deploy para que um timeout específico de uma solicitação não fique oculto em uma métrica agregada.
• Mantenha documentadas e, quando houver suporte, sob controle de versão as configurações de timeout da CDN, do WAF, do balanceador de carga, do proxy reverso, do servidor web e da aplicação.
• Teste uploads lentos, solicitações incompletas, comportamento de keep-alive e métodos de API importantes em um ambiente controlado.
• Defina deliberadamente os timeouts de solicitação e conexão, equilibrando o comportamento legítimo do cliente com o consumo de recursos e o risco de abuso.
• Preserve registros de data e hora sincronizados e identificadores de solicitação ou trace entre as camadas de rede.
• Torne explícito o comportamento de novas tentativas dos clientes, especialmente para solicitações não idempotentes, como envios de formulários, pedidos ou pagamentos.
• Mantenha logs e métricas sanitizados suficientes para correlacionar um 408 com o componente que o emitiu.

Perguntas frequentes