400 Bad Request: o que significa e como corrigir

O que significa o erro 400 Bad Request

A RFC 9110 define o 400 como a forma do servidor dizer que não conseguiu entender a requisição por causa de sintaxe malformada. A palavra-chave é sintaxe: o servidor não está avaliando quem você é, o que você pode fazer, ou se o recurso existe. Ele está dizendo que a própria requisição, como bytes na conexão, não é interpretável como uma requisição HTTP válida. Isso pode ser na linha da requisição, nos cabeçalhos, ou no corpo, dependendo de onde o interpretador desistiu.

Como o erro aparece

Os navegadores exibem qualquer página de erro simples que o servidor devolva para um 400; não existe uma página própria do navegador como existe para uma falha de DNS ou de certificado, já que a conexão teve sucesso e uma resposta chegou a ser recebida. Uma variante comum vem escrita exatamente como "400 Bad Request - request header or cookie too large", que já nomeia a causa direto. Na linha de comando:

curl -I https://example.com/some/path
HTTP/1.1 400 Bad Request
Content-Type: text/html

Os logs do servidor são a evidência mais útil aqui, porque, ao contrário de uma falha de handshake TLS, a requisição chegou até a camada de aplicação e é registrada, muitas vezes com o cabeçalho ou a linha específica que falhou ao ser interpretada.

O que causa um erro 400 Bad Request

Para quem é visitante, na ordem em que você provavelmente vai encontrar cada uma:

• Cookies grandes demais ou corrompidos. Anos de cookies acumulados para um domínio, ou um cookie que ficou corrompido por uma extensão ou por um redirecionamento com defeito, produzem rotineiramente a mensagem exata "400 Bad Request - request header or cookie too large" assim que o tamanho total dos cabeçalhos passa do limite do servidor.
• Uma URL digitada errado ou mal codificada. Um caractere fora do lugar, um espaço não codificado, ou uma sequência de percent-encoding quebrada na barra de endereço ou num link colado podem não ser interpretáveis como sintaxe válida.
• Uma extensão do navegador modificando requisições. Bloqueadores de anúncio, ferramentas de privacidade e algumas extensões de VPN reescrevem cabeçalhos ou a linha da requisição, e um bug numa delas pode entregar ao servidor algo malformado.
• Um redirecionamento em cache apontando para uma URL quebrada. O navegador segue um redirecionamento antigo até uma URL que em si é inválida, e o 400 aparece no destino, não no link que você realmente clicou.
• Um upload de arquivo maior do que o servidor permite. Algumas configurações de servidor respondem a um upload grande demais com 400 em vez do código mais específico 413 Payload Too Large.

Para quem administra o site, mais ou menos na ordem que vale a pena checar primeiro:

• Limites de tamanho de cabeçalho ou cookie configurados baixos demais para o que a aplicação realmente envia, principalmente depois de adicionar cookies de rastreamento, JWTs em cabeçalhos, ou um mecanismo de sessão que cresce com o tempo.
• Um cabeçalho Host inválido ou ausente, que um proxy reverso mal configurado ou um cliente com defeito pode produzir, e que a maioria dos servidores exige para rotear a requisição.
• Um Content-Length que não bate com o corpo realmente enviado, o que um cliente quebrado ou um proxy com bug no meio do caminho pode causar.
• Regras de firewall de aplicação web ou do ModSecurity rejeitando uma requisição cuja sintaxe parece normal para um humano, mas que casa com um padrão que o WAF trata como malformado.
• Uma API rejeitando deliberadamente um JSON malformado com 400. Esse caso é comportamento correto, não um bug: um corpo de requisição que falha ao ser interpretado como JSON válido, ou que está faltando um campo obrigatório validado no nível de sintaxe, deve mesmo devolver 400 por design.

Como saber de quem é a culpa

Reproduza a mesma requisição a partir de um ambiente limpo: uma janela anônima sem extensões e sem cookies acumulados, ou uma chamada simples com curl para a mesma URL. Se a requisição limpa funciona, a causa era local, quase sempre cookies ou uma extensão. Se ela falha do mesmo jeito num cliente limpo e em outro lugar qualquer, os próprios limites ou regras do servidor estão rejeitando uma requisição formada legitimamente, e o jeito mais rápido de confirmar isso em escala é rodar uma verificação HTTP a partir de vários lugares ao mesmo tempo e comparar o código de status que cada um recebe de volta.

Como corrigir um erro 400 Bad Request

Se você é o visitante

1. Limpe os cookies do site primeiro, já que cookies grandes demais ou corrompidos são de longe a causa mais comum. A maioria dos navegadores deixa limpar os cookies de um site só, sem apagar o login de todos os outros.
2. Tente de novo numa janela anônima ou privada. Uma janela limpa não tem cookies acumulados e, dependendo do navegador, desativa a maioria das extensões por padrão, o que isola as duas causas mais comuns de uma vez.
3. Confira a URL em busca de erros de digitação ou caracteres fora do lugar, principalmente depois de colar um link de algum lugar que pode ter adicionado parâmetros de rastreamento ou quebrado a codificação.
4. Desative as extensões uma de cada vez se o erro persiste numa janela normal mas não na navegação anônima, para achar qual delas está reescrevendo a requisição.
5. Tente outro dispositivo ou outra rede para descartar um portal cativo ou um proxy local que não tem nada a ver com o site.

Se você administra o site

1. Aumente os limites de cabeçalho e de buffer se a aplicação realmente precisa deles maiores. No nginx:

   large_client_header_buffers 4 16k;

   No Apache:

   LimitRequestFieldSize 16384

   No IIS, confira tanto o maxRequestLength no web.config, para o corpo da requisição, quanto a configuração de registro MaxFieldLength do HTTP.sys, para campos de cabeçalho individuais.
2. Reduza o que você realmente está enviando em cookies e cabeçalhos, em vez de só subir o teto. Limpar cookies antigos, tirar tokens grandes dos cabeçalhos e definir tempos de vida de cookie mais curtos evita que o problema volte a acontecer conforme o uso cresce.
3. Confira o tratamento do cabeçalho Host no proxy reverso ou no load balancer, e confirme que ele está encaminhando um valor válido e esperado para a aplicação.
4. Leia os logs do WAF ou do ModSecurity em busca da regra específica que disparou, se houver algum na frente da aplicação; um falso positivo aí precisa de uma exceção pontual, não de desligar o conjunto de regras inteiro.
5. Confirme que um 400 da sua API é intencional antes de "corrigi-lo". Um corpo JSON malformado ou um campo que falha na validação no nível de sintaxe deve devolver 400; a correção nesse caso é mensagens de erro mais claras no lado do cliente, não mudar o código de status.

400 contra códigos parecidos

• 401 Unauthorized significa que a requisição foi entendida sem problema, mas faltam credenciais válidas ou elas foram recusadas.
• 403 Forbidden significa que a requisição foi entendida sem problema, mas o servidor se recusa a autorizá-la independentemente das credenciais.
• 404 Not Found significa que a requisição foi entendida sem problema e nenhum recurso correspondeu ao caminho.
• 413 Payload Too Large é o código específico para um corpo que excede um limite de tamanho, embora alguns servidores respondam com 400 na prática.
• 414 URI Too Long é o código específico para uma linha de requisição que excede um limite de comprimento.
• 422 Unprocessable Content significa que a sintaxe foi interpretada sem problema, mas a semântica não, por exemplo um JSON válido com um valor que falha numa validação de negócio, uma distinção mais fina do que a maioria das APIs se importa em fazer em vez de usar 400.

Como evitar que um erro 400 derrube uma página

Um 400 introduzido por um deploy que apertou os limites de cabeçalho, ou por uma atualização de regra de WAF que passa a casar com tráfego legítimo, não vai aparecer como uma queda ou um timeout, já que o servidor responde na hora e corretamente pelas próprias regras. Uma verificação HTTP programada com uma asserção no código de status esperado pega isso no momento em que começa a acontecer, em vez de esperar os chamados de suporte se acumularem. Combinada com o monitoramento a partir de vários lugares, ela também mostra se o 400 é geral ou ligado à configuração de borda de uma região específica.

Erros relacionados

A família mais ampla de códigos de erro de cliente e de servidor está coberta na visão geral dos códigos 4xx. Veja também 403 Forbidden, para requisições que o servidor entendeu e recusou, 404 Not Found, para requisições dirigidas a um recurso que não existe, e 429 Too Many Requests, para requisições recusadas por causa de taxa, não de sintaxe.

Perguntas frequentes

Por que limpar os cookies corrige um erro 400?

Porque os cookies viajam junto como cabeçalhos em toda requisição, e um servidor impõe um tamanho total máximo de cabeçalho. Anos de cookies acumulados, ou um único cookie corrompido, podem empurrar o total para além desse limite, e o servidor responde 400 antes mesmo de ler qualquer outra coisa da requisição.

O erro 400 é igual em todos os sites que eu visito?

O código e a causa geral, sintaxe malformada na requisição, são os mesmos em todo lugar, mas o limite exato que foi ultrapassado e o texto exato da página de erro são definidos pela configuração de servidor de cada site.

Minha API deveria devolver 400 para entrada inválida?

Sim, quando a entrada falha ao ser interpretada ou está faltando um campo que a API checa no nível de sintaxe. Isso é o 400 funcionando como deveria, não um bug a ser corrigido afrouxando a validação.

Um WAF pode causar um erro 400 numa requisição que parece totalmente normal?

Sim. Uma regra de WAF pode sinalizar um padrão numa URL, cabeçalho ou corpo que é tecnicamente HTTP válido mas casa com uma assinatura defensiva, e algumas configurações de WAF respondem com um 400 genérico em vez de uma página de bloqueio mais específica.

Qual é a diferença entre 400 e 413?

O 413 é o código específico para um corpo de requisição que excede um limite de tamanho configurado. Muitos servidores usam ele corretamente, mas alguns respondem 400 mesmo para essa mesma condição de corpo grande demais, então não presuma que o código sozinho conta a causa exata sem checar a documentação ou os logs do servidor.