Erro 400 Bad Request: o que é e como resolver

O que é o erro 400 Bad Request?

400 Bad Request é um código de status HTTP que significa que o servidor recebeu a sua requisição, mas não vai processá-la porque algo na própria requisição parece errado. O padrão HTTP (RFC 9110, seção 15.5.1) o define como o servidor não conseguir ou não querer processar uma requisição "devido a algo percebido como um erro do cliente", como sintaxe malformada, enquadramento de mensagem inválido ou roteamento de requisição enganoso.

Diferente de um erro 500, que significa que o servidor quebrou, um 400 aponta o dedo para a requisição: a URL, os cabeçalhos, os cookies ou os dados que o seu navegador ou app enviou. Normalmente o site está funcionando bem para todo mundo.

Isso é uma boa notícia para os visitantes, porque a correção geralmente está do seu lado e leva um minuto: um link digitado errado ou um cookie corrompido estão por trás da maioria dos erros 400.

Como um erro 400 aparece

A mensagem depende do software do servidor, e o texto extra costuma ser a melhor pista da causa:

O que causa o erro 400 Bad Request?

• Uma URL malformada. Um sinal % perdido, um espaço, um caractere que deveria ter sido codificado, ou um link cortado ou colado duas vezes.

• Cookies corrompidos ou grandes demais. Sites que gravam muitos cookies (login, testes A/B, analytics) podem fazer o cabeçalho Cookie passar do limite do servidor. Um cookie danificado durante uma atualização também pode ser rejeitado.

• Cabeçalhos de requisição grandes demais. Além dos cookies, tokens de autenticação longos ou cabeçalhos adicionados por extensões e proxies vão se somando.

• Dados inválidos enviados a uma API. Campos obrigatórios faltando, JSON malformado ou o cabeçalho Content-Type errado.

• HTTP enviado a uma porta HTTPS. Comum atrás de balanceadores de carga e proxies reversos.

• Um arquivo grande demais. Muitos servidores respondem 413 Content Too Large, mas alguns apps e frameworks retornam 400 no lugar.

Correção 1: confira a URL

Olhe com atenção a barra de endereço. Problemas para observar:

• Um % que não é seguido por dois caracteres hexadecimais (%20 está certo, %2 ou %zz não).

• Espaços, { }, |, \ ou outros caracteres incomuns, principalmente em links copiados de e-mails, PDFs ou apps de mensagem.

• Um link colado duas vezes (https://example.com/https://example.com/...) ou cortado no meio.

• Uma URL muito longa, cheia de parâmetros de rastreamento. Apague tudo a partir do ? e tente de novo.

Se você chegou por um link de outro site, vá para a página inicial do site e navegue até a página a partir dali.

Correção 2: limpe os cookies só desse site

Isso resolve a maioria dos erros 400 em sites que você já usou antes, principalmente mensagens que falam de cookies ou cabeçalhos "too large" (grandes demais) ou "too long" (longos demais). Você não precisa apagar os cookies de todos os sites, só os deste:

• Chrome / Edge: clique no ícone à esquerda da barra de endereço → Cookies e dados do site (ou Configurações do site) → exclua os dados do site e recarregue.

• Firefox: clique no cadeado → Limpar cookies e dados de sites…

• Safari (Mac): Safari → Ajustes → Privacidade → Gerenciar Dados de Sites… → procure o site → Remover.

• iPhone: Ajustes → Apps → Safari → Avançado → Dados de Sites → deslize o site para a esquerda para apagar.

Correção 3: teste uma janela anônima e depois limpe o cache

Abra a página em uma janela anônima/privativa (Ctrl + Shift + N no Chrome e no Edge, Ctrl + Shift + P no Firefox, Cmd + Shift + N no Safari). Janelas anônimas começam sem cookies e sem extensões, então, se a página funcionar ali, a Correção 2 ou a Correção 4 vai resolver de vez.

Se a janela anônima também falhar, limpe o cache do navegador (Ctrl + Shift + Delete → Imagens e arquivos armazenados em cache) e, como último passo, limpe o cache DNS. O DNS raramente é a causa de um 400, mas, depois que um site muda de servidor, um endereço desatualizado pode levar você a um servidor que rejeita a sua requisição.

Correção 4: desative as extensões e confira o tamanho dos arquivos

Extensões que modificam requisições, como ferramentas de privacidade, editores de cabeçalho, buscadores de cupons e alguns bloqueadores de anúncios, podem adicionar ou alterar cabeçalhos de um jeito que o servidor rejeita. Desative todas, recarregue e depois reative uma de cada vez para achar a culpada.

Se o erro aparece ao enviar um arquivo, tente um arquivo menor. Comprima as imagens ou divida arquivos grandes. Isso mostra se o servidor está rejeitando o tamanho, mesmo que ele informe o problema como 400 em vez de 413.

Para donos de sites: como encontrar a causa dos erros 400

Se os usuários relatam erros 400 no seu site, comece pela mensagem exata que eles veem e pelos logs do servidor. O nginx e o Apache registram o motivo no nível info, então aumente temporariamente o nível do log de erros se não encontrar nada, e o log de acesso mostra quais URLs retornam 400. O Verificador de Cabeçalhos HTTP do DNS Robot mostra o código de status, o software do servidor e cada cabeçalho Set-Cookie que uma página envia, o que ajuda a identificar cookies que não param de crescer.

# Quais requisições recebem 400? (formato de log combined do nginx)
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Os motivos que o nginx registrou (precisa de error_log ... info;)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

"Request Header Or Cookie Too Large"

O nginx lê os cabeçalhos da requisição em buffers definidos por large_client_header_buffers, por padrão 4 buffers de 8 KB. Uma única linha de cabeçalho, normalmente o cabeçalho Cookie, que não cabe em um buffer dispara este 400. O limite equivalente no Apache é o LimitRequestFieldSize, de 8.190 bytes por padrão.

A correção certa é enviar menos: remova os cookies de que você não precisa mais, mantenha os cookies de sessão pequenos e restrinja os cookies aos caminhos e subdomínios que os usam. Se você realmente precisa de cabeçalhos maiores, por exemplo para tokens grandes de login único (SSO), aumente o limite:

# nginx (bloco http ou server)
large_client_header_buffers 4 16k;

# Equivalente no Apache (httpd.conf / vhost)
# LimitRequestFieldSize 16380

"The plain HTTP request was sent to HTTPS port"

O nginx retorna este 400 quando algo envia HTTP simples para uma porta em que ele espera TLS, normalmente a 443. As causas típicas são um balanceador de carga ou proxy encaminhando tráfego http:// para a porta 443, um link com http://example.com:443 ou uma configuração antiga ssl on; que faz uma porta esperar TLS quando não deveria.

Garanta que cada linha listen corresponda ao que chega nela: listen 443 ssl; para HTTPS e listen 80; para HTTP simples, com um redirecionamento da 80 para a 443. Confirme também que o proxy na frente fala HTTPS com a 443 (ou HTTP com a 80).

Erros 400 em APIs

As APIs usam o 400 para requisições que não passam na validação. Se você está chamando uma API, leia o corpo da resposta, porque a maioria das APIs explica qual campo está errado. Depois, confira se você está enviando um JSON válido, o cabeçalho Content-Type: application/json correto e todos os parâmetros obrigatórios.

Se você está construindo uma API, retorne um corpo que diga qual é o problema (por exemplo, {"error": "email is required"}) e considere usar 422 Unprocessable Content para requisições bem formadas mas semanticamente inválidas, deixando o 400 para requisições que nem podem ser interpretadas.

400 vs. 401, 403, 404, 413, 429 e 431

Os nossos guias dos erros vizinhos: 403 Forbidden, 401 Unauthorized e 429 Too Many Requests. Para redirecionamentos que entram em loop em vez de falhar, veja ERR_TOO_MANY_REDIRECTS, e o Verificador de Redirecionamento mostra cada salto.