---
title: "Erro 400 Bad Request: o que significa e como resolver"
description: "400 bad request significa que o servidor recebeu uma requisição que não aceita: link quebrado, cookies grandes demais ou dados inválidos. Veja como resolver."
url: https://proxynet.io/pt-br/blog/400-bad-request-error
date: 2026-11-12
author: "Acar Diveroli"
category: "Tutoriais, Web scraping"
lang: pt-BR
---

# 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.

> **Nota: Resposta rápida**
>
> Um erro 400 Bad Request significa que o servidor do site recebeu a sua requisição, mas não a processou, porque havia algo errado na própria requisição: um endereço digitado errado ou quebrado, cookies demais ou grandes demais para aquele site, um cookie corrompido, uma extensão que alterou a requisição ou, no código, dados inválidos. Recarregar envia a mesma requisição e recebe a mesma resposta. Confira o endereço, apague só os cookies daquele site e teste uma janela anônima; se o erro continuar, entre em contato com o site. Desenvolvedores devem ler o corpo da resposta, que geralmente aponta o problema.

## 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](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.1), 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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/400), 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ê.

| O que você vê | Quem envia | Causa comum |
|---|---|---|
| “400 Bad Request”, “Request Header Or Cookie Too Large”, “nginx” | nginx | Cookies demais ou grandes demais para o site |
| “400 Bad Request”, “The plain HTTP request was sent to HTTPS port” | nginx | Uma requisição `http://` em uma porta que espera HTTPS |
| “Bad Request”, “Your browser sent a request that this server could not understand.” | Apache | Um endereço ou cabeçalho malformado |
| “HTTP 400 - Bad Request (Request header too long)” | IIS, o servidor web da Microsoft | Um cabeçalho acima do limite, muitas vezes um token de login |
| “Esta página não está funcionando”, “Se o problema continuar, entre em contato com o proprietário do site.”, “HTTP ERROR 400” | Chrome | O site enviou um 400 sem página própria |
| Uma mensagem JSON curta, como `{"error":"invalid JSON"}` | Uma API | Dados inválidos ou um parâmetro ausente |

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?

| Código | Nome | O que significa | O que ajuda |
|---|---|---|---|
| `400` | Bad Request | A requisição está com defeito | Corrigir o endereço, os cookies ou os dados |
| `401` | Unauthorized | Faltam credenciais válidas | Fazer login ou enviar um token válido |
| `403` | Forbidden | Entendida, mas recusada | Outra conta ou outra permissão |
| `404` | Not Found | Não há nada neste endereço | Conferir o endereço |
| `413` | Content Too Large | O envio é grande demais | Enviar um arquivo menor |
| `431` | Request Header Fields Too Large | Os cabeçalhos são grandes demais | Apagar os cookies do site |

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](/pt-br/blog/401-unauthorized-error). 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`](https://nginx.org/en/docs/http/ngx_http_core_module.html#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](https://support.google.com/chrome/answer/95647?hl=pt-BR)).
   - 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:

```bash
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):

```text
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](https://proxynet.io/pt-br/https-proxy), 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](https://proxynet.io/pt-br/residential-proxy) 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](/pt-br/blog/http-status-codes-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

| A sua situação | O que fazer |
|---|---|
| “Request Header Or Cookie Too Large” em um site | Apague os cookies daquele site |
| Um link de e-mail dá 400 | Digite-o de novo ou comece pela página inicial |
| A página abre em uma janela anônima | Remova o cookie ou a extensão responsável |
| O erro aparece quando você envia um arquivo | Envie um arquivo menor |
| Só em uma rede, ou só com a VPN ligada | Confira a VPN, o proxy ou o software de segurança |
| A sua chamada de API retorna 400 | Leia o corpo e corrija o JSON, o cabeçalho ou o parâmetro |

## 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](/pt-br/proxy).