Status 499: o que o nginx quer dizer com client closed request

O que significa o código de status 499

499 Client Closed Request é específico do nginx e nunca foi definido em nenhuma RFC. Códigos acima de 99 e abaixo de 600 são reservados para linhas de status HTTP em geral, mas o 499 é uma convenção própria do nginx, registrada quando o nginx detecta que a conexão do cliente caiu enquanto ele ainda esperava a aplicação de origem responder, ou enquanto ainda estava enviando o corpo da resposta de volta ao cliente. O formato mais comum no mundo real é uma origem lenta combinada com um cliente, aba de navegador, ou balanceador de carga cujo próprio timeout é menor do que o tempo que o servidor levaria, então o cliente desliga primeiro.

Como aparece nos logs

Você nunca vai ver o 499 como um código de status devolvido para nenhum cliente, navegador, curl ou qualquer outro, porque por definição o cliente já foi embora no momento em que o nginx enviaria isso. Ele existe só no próprio log de acesso do nginx:

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

O tamanho de resposta de 0 bytes e o tempo em relação ao tempo de resposta conhecido da sua origem são os dois detalhes mais úteis: um 499 que cai consistentemente perto do timeout da sua origem, sem nada devolvido, aponta claramente para "a origem estava lenta demais e alguma coisa desistiu de esperar".

O que causa um 499

• Uma aplicação de origem lenta. O backend está levando mais tempo para responder do que algum cliente ou intermediário está disposto a esperar, seja uma consulta lenta ao banco de dados, uma chamada a uma API externa, ou um processamento genuinamente pesado.
• Um timeout do lado do cliente menor do que o servidor precisa. Uma aba de navegador fechada, um aplicativo móvel desistindo de uma conexão instável, ou o próprio timeout de uma biblioteca de cliente HTTP disparando antes de a resposta chegar.
• Um balanceador de carga ou proxy intermediário atingindo o timeout primeiro. Se algo fica entre o usuário final real e o nginx, o próprio timeout dele pode disparar uma desconexão que o nginx registra como 499, mesmo que o usuário final real nunca tenha cancelado nada explicitamente.
• Um usuário navegando para outra página ou atualizando. Alguém clicando para sair de uma página lenta carregando, ou atualizando por impaciência, fecha a conexão em andamento antes de o nginx terminar.
• Valores de timeout inconsistentes ao longo da cadeia. Um cliente, uma CDN, um balanceador de carga e o próprio nginx podem ter cada um um timeout diferente, e qualquer que seja o mais curto determina quando a desconexão acontece, independentemente de como os outros estão configurados.

Por que ele nunca aparece em um navegador

O 499 não é uma resposta, é uma anotação que o nginx faz para si mesmo sobre uma resposta que nunca terminou de enviar. Um usuário cuja aba produziu um 499 nos seus logs não vê nada: nenhuma página de erro, nenhum código de status, só uma página que parou de carregar ou um indicador que nunca se resolveu, porque não havia resposta nenhuma para o navegador renderizar. É exatamente por isso que confiar em erros relatados por usuários deixa passar isso completamente; o único lugar onde um 499 é visível é o próprio log de acesso do servidor.

Como corrigir e reduzir 499

Não existe uma única configuração que elimine 499, já que a causa subjacente é uma corrida entre o cliente desistir e o servidor terminar, e a correção depende de qual lado dessa corrida está realmente quebrado. Comece estabelecendo se a origem está consistentemente lenta para a rota afetada, ou se as desconexões se concentram em um cliente, rede, ou intermediário específico, já que isso aponta para correções diferentes.

1. Investigue o tempo de resposta da origem primeiro, já que um backend lento é a causa subjacente mais comum. Olhe quanto tempo as requisições afetadas realmente levaram na origem, não só que o nginx registrou um 499.
2. Alinhe os valores de timeout ao longo de toda a cadeia, deliberadamente, em vez de deixar o padrão de cada camada como está: cliente, CDN, balanceador de carga, e o próprio proxy_read_timeout e proxy_connect_timeout do nginx deveriam ser definidos com um entendimento claro de qual deve disparar primeiro.
3. Considere o proxy_ignore_client_abort se deixar a origem terminar o trabalho dela mesmo depois de o cliente desconectar importar para a sua aplicação, por exemplo para completar uma escrita que não deveria ficar pela metade:

   proxy_ignore_client_abort on;

   Isso não evita o registro de log do 499 para a desconexão original; muda se o nginx mantém a requisição na origem rodando de qualquer forma.
4. Acelere o trabalho real na origem onde a causa raiz é genuinamente um endpoint lento, já que nenhuma quantidade de ajuste de timeout corrige sozinha uma origem que demora demais; faça o profiling das consultas ou chamadas lentas específicas por trás da rota afetada.
5. Trate uma taxa crescente de 499 como um sinal real, não como ruído de log para filtrar, já que geralmente significa que a sua aplicação ficou mais lenta ou que a sua configuração de timeout está desalinhada em algum ponto da cadeia.

Como prevenir que isso vire uma queda

Como o 499 nunca chega ao cliente como um erro visível, é fácil um endpoint genuinamente lento passar despercebido até alguém ler os logs de acesso, mesmo enquanto usuários reais estão silenciosamente abandonando requisições. Uma verificação HTTP agendada mede o tempo de resposta real contra o endpoint diretamente e alerta quando ele degrada, pegando a lentidão que está produzindo os 499 antes que ela cresça a ponto de as requisições falharem totalmente. Monitoramento a partir de várias localidades também ajuda a separar uma origem genuinamente lenta de um timeout que só dispara para clientes em um caminho de rede específico.

Erros relacionados

Veja 504 Gateway Timeout para o equivalente padrão e visível ao cliente, quando o próprio nginx desiste de esperar a origem em vez de o cliente desistir primeiro, a visão geral dos 4xx para a família padrão de erros de cliente, e 429 Too Many Requests para um tipo diferente de rejeição ligada a taxa em vez de tempo.

Perguntas frequentes

O 499 é um código de status HTTP de verdade?

Não. É uma convenção de log própria do nginx para um cliente que se desconectou antes de a resposta terminar, e nunca é enviada pela rede para nenhum cliente, já que o cliente já foi embora no momento em que seria enviada.

Por que a minha ferramenta de monitoramento nunca vê um 499?

Uma verificação de monitoramento é ela mesma um cliente, e se for ela quem desiste de uma resposta lenta, vai relatar o próprio erro de timeout, não 499, já que nunca recebe uma resposta HTTP da qual ler um código de status. O 499 só aparece na própria entrada de log de acesso do servidor para aquela requisição.

Um 499 significa que o meu servidor caiu?

Não. Especificamente significa que o servidor ainda estava trabalhando, ou prestes a começar a trabalhar, quando o cliente se desconectou. Uma queda de verdade normalmente produziria um 502 ou 500, uma vez que algo de fato respondesse.

Posso parar o processamento na origem quando um cliente se desconecta?

Por padrão o nginx geralmente para de esperar pela origem assim que o cliente some, mas o comportamento exato depende das suas configurações de proxy; proxy_ignore_client_abort on diz ao nginx para deixar a requisição na origem continuar em vez de abandoná-la.

Qual é a correção mais comum para 499 frequentes?

Alinhar os valores de timeout entre o cliente, qualquer proxy ou balanceador de carga intermediário, e o próprio nginx, combinado com resolver o que está deixando a origem lenta em primeiro lugar. Nenhum dos dois sozinho costuma resolver um padrão persistente.