Erro 400 Bad Request: o que significa e como resolver

Você abre um link de um e-mail, ou um site que usa todo dia, e aparece uma tela branca com “400 Bad Request” em negrito. Às vezes uma segunda linha diz mais, como “Request Header Or Cookie Too Large”, com “nginx” no rodapé. O Chrome pode desenhar uma página cinza própria no lugar: “Esta página não está funcionando” e HTTP ERROR 400. Desenvolvedores recebem o mesmo número de uma API, geralmente com uma mensagem JSON curta.

Tudo isso significa que o servidor recebeu uma requisição que não quis aceitar. A seguir você vê o que o código significa, quem enviou a página, as causas e soluções para visitantes, como o 400 se diferencia do 401, 403, 404 e 413, e o que os desenvolvedores devem verificar, com um exemplo reproduzido.

O que significa 400 Bad Request?#

400 Bad Request significa que o servidor se recusa a processar uma requisição porque considera a própria requisição defeituosa. O padrão HTTP, RFC 9110, dá três exemplos: sintaxe de requisição malformada, enquadramento de mensagem inválido (informar errado onde a mensagem começa e termina) e roteamento enganoso da requisição. Em palavras simples, o endereço, os cabeçalhos ou os dados quebraram as regras com que o servidor trabalha.

Os códigos da faixa 400 descrevem problemas do lado da requisição, mas “erro do cliente” nem sempre quer dizer que você fez algo errado: um cookie que o próprio site definiu pode deixar as requisições do seu navegador grandes demais. Da definição sai uma regra. Como diz a referência do MDN, uma requisição repetida sem alterações falha com o mesmo erro, então recarregar não ajuda; mudar a requisição, sim.

Quem enviou a página 400 que você está vendo?#

A segunda linha da página e o nome no rodapé dizem qual programa recusou a requisição e, muitas vezes, por quê.

Conferimos a linha do Chrome com um pequeno servidor de teste no nosso próprio computador, que responde 400 com o corpo vazio, aberto no Chromium 145: com a interface em português aparecem exatamente essas linhas e um botão Recarregar. O Chrome escreve esse texto por conta própria, então ele não diz nada sobre a causa.

Como um 400 acontece, passo a passo?#

Uma requisição tem três partes, e o servidor as verifica em ordem:

1. A linha de requisição. O método e o endereço, como GET /search?q=shoes. Caracteres especiais viajam como um % seguido de dois dígitos hexadecimais (codificação percentual); um % sem esses dois dígitos não pode ser decodificado.
2. Os cabeçalhos. Linhas como Host e User-Agent, além de Cookie, que leva todos os cookies que o navegador guarda para aquele site. Os servidores limitam cada linha de cabeçalho: 8 KB por padrão no nginx, 8.190 bytes no Apache.
3. O corpo. Dados de formulário ou de API, muitas vezes JSON, cujo formato e campos obrigatórios a aplicação verifica.
4. O veredito. A primeira verificação que falha encerra a requisição com 400, geralmente com um motivo curto.
5. A repetição. Nada mudou, então a próxima tentativa envia o mesmo endereço, os mesmos cookies e os mesmos dados, e recebe o mesmo 400.

Qual é a diferença entre 400, 401, 403, 404 e 413?#

O 400 é o código geral; os servidores enviam um mais específico quando ele se encaixa. Um 401 significa que o servidor leu a requisição, mas quer saber quem a enviou, que é o assunto de Erro 401 Unauthorized: o que significa e como resolver. Um envio grande demais normalmente recebe 413 (o nginx aceita 1 MB de corpo de requisição por padrão), embora algumas aplicações respondam 400.

Por que estou recebendo o erro 400 Bad Request?#

Do lado do visitante, as causas comuns são estas:

• Um endereço digitado errado ou quebrado. Links copiados de e-mails e apps de mensagens são cortados ou ganham caracteres a mais; um % sem dois dígitos hexadecimais depois dele, como em 50%off, não pode ser decodificado.
• Cookies demais ou grandes demais para aquele site, a causa por trás de “Request Header Or Cookie Too Large”.
• Um cookie corrompido ou desatualizado. Depois que um site muda o sistema de login, um cookie antigo pode trazer um valor que o código novo não consegue ler.
• Uma extensão que reescreve requisições, como uma que edita cabeçalhos ou cookies.
• Algo no meio do caminho, raramente: um software de segurança que inspeciona o tráfego web ou um proxy configurado com o esquema ou a porta errados.

O que significa “Request Header Or Cookie Too Large”?#

Significa que os cookies que o seu navegador guarda para aquele site, junto com os outros cabeçalhos, não cabem mais no limite de tamanho do servidor, então o nginx recusa a requisição com 400. O seu navegador envia todos os cookies de um site em um único cabeçalho Cookie a cada requisição, e o nginx recusa qualquer linha de cabeçalho maior que um buffer, 8 KB por padrão, como explica a documentação de large_client_header_buffers.

Os limites dos dois lados não batem. O padrão de cookies, RFC 6265, pede que os navegadores guardem pelo menos 4.096 bytes por cookie e pelo menos 50 cookies por domínio, muito mais que 8 KB somados. Um site com muitos cookies de análise e de sessão pode passar do limite depois de semanas de uso normal, e o erro então atinge só aquele site, porque só os cookies dele viajam com as requisições dele.

O IIS escreve “HTTP 400 - Bad Request (Request header too long)”, e alguns servidores enviam o código mais específico 431. A solução do seu lado é a mesma: apague os cookies daquele site.

Como resolver o erro 400 se você é visitante?#

Siga estes passos em ordem; os três primeiros levam um minuto.

1. Confira o endereço. Digite-o de novo, ou abra a página inicial do site e navegue a partir dela. Para um link longo de e-mail, teste sem a parte depois do ?.
2. Apague só os cookies daquele site. Isso desconecta você apenas daquele site e não mexe nos outros.
   • Chrome: Mais > Configurações > Privacidade e segurança > Cookies de terceiros > Ver todos os dados e as permissões do site, pesquise o site, selecione Excluir e confirme (os passos do Google).
   • Edge: Configurações e mais > Configurações > Privacidade, pesquisa e serviços > Cookies > Ver todos os cookies e dados do site, pesquise o site, abra a seta ao lado dele e selecione Excluir.
   • Firefox: no site, clique no ícone de escudo à esquerda da barra de endereço e escolha Limpar cookies e dados de sites do domínio…
   • Safari no Mac: Safari > Ajustes > Privacidade > Gerenciar Dados de Sites, selecione o site e clique em Remover.
3. Teste uma janela anônima. No Chrome, Mais > Nova janela anônima, ou Ctrl + Shift + N. Ela abre sem os cookies do site, e as extensões ficam desligadas, a não ser que você as tenha permitido ali. Se a página abrir, a causa era um cookie ou uma extensão.
4. Desligue as extensões uma a uma em Mais > Extensões > Gerenciar extensões no Chrome, começando pelas que bloqueiam conteúdo ou editam requisições.
5. Diminua o arquivo se o erro aparecer quando você envia um arquivo.
6. Teste sem a VPN ou o proxy, ou com dados móveis. Se a página carregar, algo na primeira rede está alterando as suas requisições.
7. Entre em contato com o site informando o endereço, o horário e onde você clicou. Se o erro voltar dias depois de apagar os cookies, o site define mais cookies do que o próprio servidor aceita.

Limpar o cache de DNS ou reiniciar o roteador raramente ajuda: quando um servidor responde 400, o seu computador já o encontrou.

O que os desenvolvedores devem verificar quando o código recebe um 400?#

No código, um 400 significa que o servidor recusou a requisição que o seu programa montou, e o corpo da resposta geralmente nomeia o campo ou a regra. Registre o corpo antes de mudar qualquer coisa. As causas comuns:

• JSON inválido: uma vírgula sobrando no fim, aspas simples, uma string montada à mão. Use o codificador da sua linguagem, como JSON.stringify ou json.dumps.
• Um Content-Type que não corresponde ao corpo, como JSON enviado com um tipo de formulário.
• Parâmetros ausentes ou errados: um campo obrigatório deixado de fora, um número enviado como texto, uma data no formato errado.
• Query strings montadas à mão. Espaços, & e % dentro dos valores precisam ser codificados; URLSearchParams ou urllib.parse.urlencode fazem isso por você.
• Cabeçalhos que o servidor não aceita. Um cookie grande ou um token longo pode passar do limite por cabeçalho: 8 KB no nginx, LimitRequestFieldSize no Apache, MaxFieldLength no IIS. O HTTP/1.1 também exige um 400 quando o cabeçalho Host falta ou vem duplicado.
• Hábitos do HTTP/1.1 no HTTP/2. O HTTP/2 exige nomes de cabeçalho em minúsculas e proíbe cabeçalhos de conexão como Connection e Keep-Alive; o servidor reinicia essa requisição ou responde 400. Isso acontece quando o código ou um proxy copia cabeçalhos do HTTP/1.1 para o HTTP/2.

Um 400 por JSON malformado, reproduzido#

Rodamos no nosso próprio computador um pequeno servidor Node.js que responde 400 quando o corpo de um pedido não é JSON válido e enviamos uma requisição com curl -i (-i mostra a linha de status e os cabeçalhos) e uma vírgula sobrando no fim do corpo:

curl -i http://127.0.0.1:18400/api/orders -H "Content-Type: application/json" -d '{"product": "sku-123", "qty": 2,}'

A saída (curl 8.22 no Windows 11, Node.js 24):

HTTP/1.1 400 Bad Request
Content-Type: application/json
Date: Thu, 12 Nov 2026 01:21:06 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

{"error":"invalid JSON","detail":"Expected double-quoted property name in JSON at position 32 (line 1 column 33)"}

position 32 na mensagem é o } logo depois da vírgula: o JSON não permite vírgula antes de uma chave de fechamento. Remova a vírgula e o corpo fica válido. Uma API real escreve a mensagem de outro jeito, mas o padrão se mantém: a linha de status diz que a requisição está errada, e o corpo diz onde.

O que muda atrás de um proxy?#

Nada na requisição, se o proxy estiver bem configurado. Para um endereço https://, o cliente pede ao proxy que abra um túnel com uma requisição CONNECT, e o proxy repassa os bytes nos dois sentidos sem lê-los, então um 400 que volta é o veredito do site. Um erro de configuração típico é um esquema que não combina com a porta: uma requisição http:// simples em uma porta que espera HTTPS recebe do nginx “The plain HTTP request was sent to HTTPS port”. Com os Proxies HTTPS, copie o host, a porta e o esquema exatamente como o Gerador de endpoints mostra.

Como um scraper deve tratar um 400?#

Como um bug na própria requisição, não como um bloqueio. Repetir sem mudanças devolve o mesmo 400, e os Proxies residenciais mudam o endereço que o site vê, não a requisição que o seu código envia. Pare, registre a requisição e o corpo, e corrija o que ele apontar.

Outros códigos merecem nova tentativa, como um 503 depois de uma pausa; Códigos de status HTTP no web scraping separa esses dos que significam parar.

Onde você pode encontrar um 400#

• Um site que você usa todo dia e que de repente mostra “Request Header Or Cookie Too Large”.
• Links longos de e-mails, apps de mensagens e newsletters que se cortam no caminho.
• Formulários de envio com um limite de tamanho que a página não menciona.
• Botões de login com a Conta do Google em apps mal configurados, com um código “Error 400”.
• Chamadas de API feitas por scripts, pelo Postman e por ferramentas no-code depois que o nome ou o tipo de um campo mudou.

Erros comuns#

• Limpar todos os dados de navegação. Isso desconecta você de todos os sites; só os cookies do site com erro importam.
• Recarregar várias vezes. A requisição não muda, então a resposta também não.
• Culpar a conexão. Um 400 significa que a requisição chegou.
• Desenvolvedores: repetir um 400 em loop ou trocar de endereço IP por causa dele, e registrar o código de status sem o corpo.
• Donos de sites: aumentar os limites de cabeçalho em vez de enxugar os cookies. O próprio padrão de cookies recomenda que os servidores mantenham os cookies poucos e pequenos.

Guia de decisão#

Perguntas frequentes#

O erro 400 é culpa minha ou do site?#

Pode ser de qualquer um dos dois; o código só diz que a requisição estava com defeito. Um erro de digitação ou uma extensão está do seu lado, um cookie grande demais foi definido pelo próprio site, e um 400 vindo de uma API é um bug no código que a chama.

Por que recebo 400 Bad Request em apenas um site?#

Porque a causa geralmente está nos cookies ou nos limites daquele site: cada site recebe só os próprios cookies e define os próprios limites de tamanho. Apague os cookies daquele site; se uma janela anônima mostrar o mesmo erro, o site precisa corrigir.

Uma VPN ou um proxy pode causar o erro 400?#

Raramente. Uma VPN, e um proxy que tunela HTTPS, repassam a sua requisição sem alterações, então o 400 vem do site. Se o erro só aparece com o proxy ligado, confira o esquema e a porta dele; um software de segurança que inspeciona o tráfego também pode alterar cabeçalhos.

Como resolver o 400 Bad Request no iPhone ou no Android?#

No Android, abra o site no Chrome, toque em Informações da página no canto esquerdo da barra de endereço, depois em Cookies e dados de sites, e toque em Excluir ao lado dos dados armazenados. No iPhone, teste primeiro uma aba privada; se funcionar, Ajustes > Apps > Safari > Avançado > Dados do Site > Remover Todos os Dados resolve, mas desconecta você de todos os sites.

Por que recebo 400 Bad Request no Postman?#

Geralmente por causa do corpo ou do tipo dele. Com o corpo em raw e o tipo JSON, o Postman adiciona o cabeçalho Content-Type correspondente, mas um que você tenha digitado manualmente prevalece. Confira o JSON e os parâmetros obrigatórios e depois leia o corpo da resposta.

O que significa “Error 400: redirect_uri_mismatch”?#

Aparece quando um app manda você fazer login com o Google: o endereço de retorno (redirect URI) que o app informou ao Google não corresponde a nenhum endereço registrado para aquele app. Só o desenvolvedor do app pode corrigir isso, nas configurações do Google Cloud do app.

Em resumo#

Um 400 Bad Request significa que o servidor recebeu a sua requisição e não a aceitou do jeito que ela veio. Visitantes conferem o endereço, apagam os cookies daquele site, testam uma janela anônima e desligam as extensões. Desenvolvedores leem o corpo da resposta, corrigem o JSON, os cabeçalhos ou os parâmetros e nunca repetem um 400 sem mudanças. Quando você precisar de proxies para monitoramento ou coleta de dados, compare os tipos na nossa página de proxies.