Erro 408 Request Timeout

A RFC 9110, seção 15.5.9, define o 408 como o servidor não receber a mensagem completa a tempo. Ela permite explicitamente que o cliente repita o pedido que estava a caminho, numa conexão nova se a atual não servir mais. Isso faz do 408 um dos poucos códigos 4xx em que repetir o mesmo pedido é o esperado.

Não confunda com aplicação lenta. Se o pedido chegou e o seu código demorou demais, isso é um 504 de um gateway ou um timeout do cliente, não um 408. O Node.js envia 408 sozinho quando um pedido passa do server.requestTimeout (300 segundos por padrão) ou os cabeçalhos passam do headersTimeout, e o nginx encerra pedidos com 408 quando o client_header_timeout ou o client_body_timeout vencem (60 segundos cada, por padrão).

Alguns 408 nos logs são inofensivos: navegadores abrem conexões extras com antecedência para acelerar a próxima navegação, e quando nenhum pedido chega, alguns servidores registram a conexão ociosa como 408.

Se você está visitando o site

• Conexão lenta, instável ou congestionada (dados móveis, Wi-Fi sobrecarregado) ao enviar um formulário ou arquivo.
• O computador entrou em suspensão ou a rede mudou no meio de um upload.

Se você administra o servidor

• Timeouts de corpo ou cabeçalho curtos demais para uploads grandes em conexões lentas.
• Um cliente que declara Content-Length maior que o corpo realmente enviado, e o servidor fica esperando bytes que nunca chegam.
• Conexões especulativas ou keep-alive que ficam abertas sem pedido e batem no timeout do servidor.

Se você está visitando o site

• Recarregue e envie de novo, de preferência numa conexão mais estável.
• Para arquivos grandes, tente pelo Wi-Fi ou comprima o arquivo antes.

Se você administra o servidor

• Aumente o client_body_timeout do nginx ou o requestTimeout do Node em endpoints de upload, ou envie os arquivos direto ao storage com URLs pré-assinadas.
• Faça os clientes repetirem pedidos idempotentes ao receber 408, numa conexão nova; muitas bibliotecas HTTP já fazem isso.
• Confira se o Content-Length enviado pelo cliente bate com o corpo, principalmente quando um proxy reescreve ou comprime o conteúdo.
• Ignore entradas 408 no log sem linha de pedido; são pré-conexões ociosas, não usuários com erro.

Quase ninguém escreve um 408 à mão: o servidor HTTP envia quando os timeouts de leitura vencem, então o que se configura são esses timeouts.

const server = app.listen(3000);
// Node answers 408 itself when these expire
server.headersTimeout = 10_000; // headers must arrive within 10 s
server.requestTimeout = 60_000; // whole request within 60 s

server {
  # nginx ends the request with 408 when these expire
  client_header_timeout 10s;
  client_body_timeout 60s;
}

408 vs 504

O 504 indica que um gateway esperou demais pelo servidor de trás; o 408 indica que o servidor esperou demais pelo cliente.

408 vs 499

O 499 é o nginx registrando que o cliente desistiu primeiro; o 408 é o servidor desistindo do cliente.

408 vs 524

O 524 é a Cloudflare esgotando o tempo esperando a resposta da origem, a direção oposta à do 408.

O erro 408 é causado pelo cliente ou pelo servidor?

O servidor informa que o cliente foi lento demais para enviar o pedido. A correção é uma conexão melhor, um conteúdo menor, ou timeouts maiores no servidor para uploads lentos legítimos.

Posso repetir o pedido depois de um 408?

Pode. A RFC 9110 permite que o cliente repita o pedido, numa conexão nova se a antiga foi fechada. Em pedidos não idempotentes, como pagamentos, garanta que o servidor ainda não processou, por exemplo com uma chave de idempotência.

Por que aparecem tantos 408 no meu log de acesso?

Muitas vezes vêm de conexões que o navegador abre com antecedência e nunca usa. Quando o servidor encerra uma conexão ociosa que não trouxe pedido, alguns servidores registram como 408. Isso não afeta os usuários.