O Que É um Erro 400 Bad Request e Como Você o Corrige?

Um 400 Bad Request é um código de status HTTP/1.1 de erro do cliente definido no RFC 9110 que sinaliza que o servidor recebeu uma solicitação que não pode ou não irá processar porque a própria solicitação está malformada. Ao contrário dos erros 5xx, que se originam no lado do servidor, um erro 400 coloca a culpa diretamente no cliente — o que significa que o problema está na solicitação enviada, não na capacidade do servidor de responder.

Em termos práticos, um erro 400 ocorre antes mesmo de o servidor tentar atender à solicitação. O servidor analisa a mensagem HTTP recebida, deteta algo estrutural ou semanticamente inválido — um cabeçalho corrompido, um URI malformado, um payload excessivamente grande, um cookie inválido — e imediatamente retorna 400 Bad Request em vez de prosseguir. Conhecer esta distinção é o caminho mais rápido para um diagnóstico correto.

O Que o Código de Status 400 Realmente Significa ao Nível do Protocolo

O HTTP opera com base num contrato estrito de solicitação-resposta. Cada solicitação deve estar em conformidade com a gramática definida na especificação HTTP. Quando um cliente envia uma mensagem que viola esta gramática, o servidor tem permissão e é esperado que a rejeite com uma resposta 400.

O servidor não regista um 400 como sua própria falha. Regista-o como uma solicitação de cliente rejeitada. É por isso que reiniciar cegamente um servidor ou limpar uma cache CDN raramente resolve um 400 genuíno — a causa raiz está quase sempre na construção da solicitação.

As variantes comuns deste erro renderizadas pelo navegador incluem:

• 400 Bad Request
• HTTP Error 400
• Bad Request — Invalid URL
• 400. That's an error. Your client has issued a malformed or illegal request.
• 400 Bad Request. The server cannot or will not process the request due to something that is perceived to be a client error.

Todos estes mapeiam para o mesmo código de status HTTP subjacente. A formulação difere consoante o software do servidor (Apache, Nginx, IIS, Cloudflare) e o framework da aplicação.

Causas Raiz de um Erro 400 Bad Request

Compreender o gatilho preciso é essencial antes de tentar qualquer correção. As causas dividem-se em duas categorias: do lado do cliente e má configuração do lado do servidor.

Causas do Lado do Cliente

URL malformado ou incorretamente codificado

Um URL contendo espaços não codificados, caracteres ilegais ou sequências de codificação percentual quebradas será rejeitado imediatamente. A especificação HTTP exige que todos os caracteres fora do conjunto não reservado (A–Z, a–z, 0–9, -, _, ., ~) sejam codificados percentualmente antes da transmissão.

Cookies corrompidos ou excessivamente grandes

Os cookies são transmitidos no cabeçalho de solicitação Cookie. Se um valor de cookie estiver malformado, exceder o limite de tamanho por cookie do navegador (tipicamente 4096 bytes), ou contiver caracteres que violem o RFC 6265, o servidor pode rejeitar toda a solicitação. Esta é uma das causas mais frequentemente ignoradas de erros 400 intermitentes em sites que o utilizador visitou anteriormente sem problemas.

Cabeçalhos de solicitação inválidos ou em falta obrigatórios

Algumas APIs e aplicações web impõem validação estrita de cabeçalhos. Um Content-Type em falta numa solicitação POST, um cabeçalho Authorization malformado, ou um cabeçalho Accept com um tipo de media não suportado podem todos desencadear um 400.

Payload de solicitação excessivamente grande

Os servidores web e proxies reversos impõem limites máximos de tamanho do corpo. O Nginx usa client_max_body_size (padrão: 1 MB); o Apache usa LimitRequestBody. Exceder estes limites produz uma resposta 400 ou 413 dependendo da configuração.

Cache DNS desatualizada ou incorreta

Embora as falhas de resolução DNS tipicamente produzam erros de conexão em vez de HTTP 400s, uma cache DNS envenenada ou desatualizada que encaminha uma solicitação para o servidor errado — que não reconhece o cabeçalho Host — pode resultar num 400 sendo retornado pela origem errada.

Extensões do navegador a interferir com cabeçalhos de solicitação

Certos bloqueadores de anúncios, ferramentas de privacidade e extensões de desenvolvimento modificam os cabeçalhos HTTP de saída. Se uma extensão injetar um cabeçalho malformado ou duplicado, o servidor pode rejeitar a solicitação.

Causas do Lado do Servidor

Regras .htaccess mal configuradas (Apache)

Regras de reescrita, diretivas de redirecionamento ou entradas de controlo de acesso com erros de sintaxe podem fazer com que o Apache gere um 400 antes de a solicitação chegar à camada da aplicação.

Erros de configuração do Nginx

Diretivas server_name inválidas, blocos location quebrados, ou configurações proxy_pass incorretas podem fazer com que o Nginx retorne um 400 para solicitações que não consegue encaminhar.

Bloqueio excessivo por WAF ou plugin de segurança

As Firewalls de Aplicações Web — seja ao nível do servidor (ModSecurity), ao nível do CDN (Cloudflare WAF), ou ao nível da aplicação (plugins de segurança WordPress) — podem sinalizar solicitações legítimas como maliciosas e retornar um 400 ou 403. Isto é comum quando os parâmetros da solicitação contêm strings que correspondem a assinaturas de injeção SQL ou XSS.

Falhas de validação ao nível da aplicação

Frameworks como Laravel, Django ou Express.js retornam 400 quando a validação de entrada falha — por exemplo, um campo JSON obrigatório está ausente, um campo de data está no formato errado, ou um parâmetro numérico recebe um valor de string.

Como Corrigir um Erro 400 Bad Request: Passos do Lado do Cliente

1. Validar e Corrigir o URL

Inspecione o URL caractere por caractere. Preste especial atenção a:

• Espaços não codificados: Um espaço deve ser %20, não um espaço literal ou + (fora de dados de formulário).
• Barras duplas ou barras em falta: https://example.com//path ou https://example.com/path? com um ponto de interrogação pendente.
• Codificação percentual quebrada: Um % não seguido de exatamente dois dígitos hexadecimais é ilegal.
• Caracteres não-ASCII: Nomes de domínio com caracteres Unicode devem usar Punycode; segmentos de caminho com Unicode devem ser codificados percentualmente em UTF-8.

Um URL corretamente codificado tem este aspeto:

https://example.com/search?q=hello%20world&lang=en

Não assim:

https://example.com/search?q=hello world&lang=en

2. Limpar Cookies e Cache do Navegador

Isto resolve a maioria dos erros 400 encontrados em sites que o utilizador visitou anteriormente.

Google Chrome:

1. Abra chrome://settings/clearBrowserData
2. Defina o intervalo de tempo para Todo o período
3. Marque Cookies e outros dados do site e Imagens e ficheiros em cache
4. Clique em Limpar dados

Mozilla Firefox:

1. Abra about:preferences#privacy
2. Em Cookies e Dados do Site, clique em Limpar Dados
3. Selecione ambas as opções e confirme

Safari (macOS):

1. Vá a Safari > Definições > Privacidade
2. Clique em Gerir Dados do Site, depois em Remover Tudo

Para uma abordagem mais direcionada — especialmente útil quando não quer perder todos os dados de sessão — use as ferramentas de desenvolvimento do navegador para eliminar apenas os cookies do domínio específico:

1. Abra as DevTools (F12 ou Cmd+Option+I)
2. Navegue até Aplicação > Armazenamento > Cookies
3. Selecione o domínio e elimine cookies individuais

3. Limpar a Cache DNS

Windows:

ipconfig /flushdns

macOS (Ventura, Sonoma, Sequoia):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Linux (nscd):

sudo service nscd restart

Após limpar, verifique se a resolução está correta antes de tentar novamente:

nslookup example.com

4. Desativar Extensões do Navegador

As extensões que modificam cabeçalhos HTTP são as mais prováveis culpadas. Em vez de desativar todas as extensões simultaneamente, use primeiro o modo de navegação anónima ou privada do navegador — a maioria das extensões está desativada por padrão nas janelas privadas. Se a página carregar corretamente em modo anónimo, uma extensão é a responsável.

Para isolar a extensão específica no Chrome:

1. Navegue até chrome://extensions/
2. Desative todas as extensões
3. Reative-as uma de cada vez, recarregando a página após cada uma

5. Testar noutro Navegador, Dispositivo ou Rede

Este passo determina rapidamente se o problema é específico do ambiente. Se a página carregar num dispositivo móvel usando dados móveis mas falhar no seu computador, o problema é provavelmente local — seja a configuração do navegador, um proxy ao nível da rede, ou uma firewall corporativa a modificar os cabeçalhos da solicitação.

Como Corrigir um Erro 400 Bad Request: Passos do Lado do Servidor

Estes passos aplicam-se a proprietários de sites, programadores e administradores de sistemas com acesso ao servidor ou painel de controlo de alojamento.

6. Analisar os Registos de Acesso e Erros do Servidor

Os registos do servidor são a ferramenta de diagnóstico definitiva. Uma entrada 400 no registo de acesso mostrará a linha de solicitação bruta que foi rejeitada.

Registo de erros do Nginx (caminho padrão):

tail -n 100 /var/log/nginx/error.log | grep " 400 "

Registo de erros do Apache:

tail -n 100 /var/log/apache2/error.log

Registo de acesso do Nginx — filtrar respostas 400:

awk '$9 == 400' /var/log/nginx/access.log | tail -20

Procure padrões: os erros 400 estão a vir de um endpoint específico, de um agente de utilizador específico, ou de um parâmetro específico? Isto reduz drasticamente a causa raiz.

Se estiver a executar um ambiente de Alojamento VPS, tem acesso SSH direto a estes registos. No Alojamento Web Partilhado gerido, os registos de acesso estão tipicamente disponíveis através da secção Erros do cPanel ou através do download do registo de Acesso Bruto.

7. Auditar o Ficheiro .htaccess (Apache)

Um único erro de sintaxe no .htaccess pode fazer com que o Apache retorne erros 400 ou 500 para cada solicitação. Valide a sintaxe do ficheiro sem reiniciar o Apache:

apachectl -t

Problemas comuns do .htaccess que produzem erros 400:

• Padrões RewriteRule com caracteres especiais não escapados

LimitRequestBody definido com um valor inesperadamente baixo
Diretivas Header malformadas

Exemplo de uma diretiva problemática:
# This will cause a 400 if the header value is malformed
RequestHeader set X-Custom-Header "value with "quotes""
Versão corrigida:
RequestHeader set X-Custom-Header "value with escaped quotes"
8. Verificar a Configuração do Nginx
Valide toda a configuração do Nginx antes de aplicar alterações:
nginx -t
Preste atenção ao client_max_body_size se os utilizadores estiverem a fazer upload de ficheiros:
http {
    client_max_body_size 50M;
}
Reveja também o large_client_header_buffers — se os cabeçalhos da solicitação (incluindo cookies) excederem o tamanho do buffer, o Nginx retorna um 400:
http {
    large_client_header_buffers 4 16k;
}
Após editar, recarregue sem tempo de inatividade:
nginx -s reload
9. Aumentar os Limites de Upload de Ficheiros
Se o erro 400 ocorrer especificamente durante uploads de ficheiros, o corpo da solicitação está provavelmente a exceder o limite configurado do servidor.
PHP (php.ini):
upload_max_filesize = 50M
post_max_size = 55M
Apache (httpd.conf ou .htaccess):
LimitRequestBody 52428800
Nginx (nginx.conf):
client_max_body_size 50M;
Note que post_max_size no PHP deve ser sempre maior que upload_max_filesize, ou o PHP descartará silenciosamente o upload e a aplicação pode retornar um 400.
10. Rever as Regras WAF e Plugins de Segurança
Se estiver a executar ModSecurity, Cloudflare WAF, ou um plugin de segurança WordPress (Wordfence, iThemes Security), desative temporariamente o conjunto de regras WAF e teste se o 400 desaparece. Se desaparecer, reveja o registo de auditoria WAF para identificar qual regra está a ser acionada:
tail -f /var/log/modsec_audit.log
Não desative simplesmente o WAF permanentemente. Em vez disso, crie uma exceção direcionada para o padrão de solicitação legítima que está a ser bloqueado.
400 Bad Request vs. Códigos de Erro HTTP Relacionados
Compreender onde o 400 se situa na taxonomia de erros HTTP previne diagnósticos incorretos.



Código de Status
Nome
Localização da Falha
Causa Típica








—
—
—
—








400
Bad Request
Cliente
Sintaxe de solicitação malformada, cabeçalhos inválidos, codificação incorreta








401
Unauthorized
Cliente
Credenciais de autenticação em falta ou inválidas








403
Forbidden
Política do servidor
Solicitação válida, mas o acesso é negado pelas regras do servidor








404
Not Found
Servidor
O recurso não existe no URI solicitado








413
Content Too Large
Cliente
O corpo da solicitação excede o limite de tamanho configurado pelo servidor








414
URI Too Long
Cliente
O URI da solicitação excede o comprimento máximo de URI do servidor








422
Unprocessable Content
Cliente
Sintaticamente válido mas semanticamente incorreto (comum em REST APIs)








431
Request Header Fields Too Large
Cliente
O tamanho individual ou total do cabeçalho excede os limites do servidor








500
Internal Server Error
Servidor
Exceção não tratada ou má configuração no servidor








502
Bad Gateway
Servidor/Proxy
O servidor upstream retornou uma resposta inválida





Uma distinção operacional importante: 413 (Content Too Large) é o código semanticamente mais preciso para uploads excessivamente grandes, mas muitos servidores — particularmente configurações mais antigas de Apache e Nginx — retornam 400 em vez disso. Se vir um 400 no upload de ficheiros, verifique sempre os limites de tamanho do corpo em primeiro lugar.
Erros 400 em Contextos de API
As APIs REST e GraphQL usam o 400 extensivamente como resposta padrão para falhas de validação de entrada. Se estiver a construir ou a consumir uma API, um corpo de resposta 400 conterá tipicamente um payload de erro estruturado:
{
  "error": "Bad Request",
  "message": "The 'email' field must be a valid email address.",
  "field": "email",
  "code": 400
}
Ao depurar erros 400 de API:

Verifique se o cabeçalho Content-Type corresponde ao formato do corpo (application/json para payloads JSON, multipart/form-data para uploads de ficheiros)
Confirme que os campos e cabeçalhos obrigatórios estão presentes e corretamente tipados
Verifique que os valores de string não excedem as restrições de comprimento máximo
Valide os formatos de data e hora em relação à especificação da API (ISO 8601 é o padrão: 2024-01-15T10:30:00Z)
Inspecione o formato do cabeçalho Authorization — os tokens Bearer devem ter o prefixo Bearer , não ser passados em bruto

Para equipas que executam serviços de API em Servidores Dedicados, ativar o registo detalhado de solicitações ao nível da aplicação (não apenas ao nível do servidor web) é fundamental para diagnosticar padrões 400 em escala.
Diagnosticar Erros 400 com as Ferramentas de Desenvolvimento do Navegador
O painel de Rede do navegador é a ferramenta de diagnóstico do lado do cliente mais precisa disponível.

Abra as DevTools (F12)
Navegue até ao separador Rede
Reproduza a solicitação que desencadeia o 400
Clique na solicitação falhada na cascata
Inspecione o separador Cabeçalhos — reveja tanto os Cabeçalhos da Solicitação como os Cabeçalhos da Resposta
Verifique o separador Resposta para qualquer detalhe de erro retornado pelo servidor

O painel de Cabeçalhos da Solicitação mostrará exatamente o que o navegador enviou. Compare isto com o que o servidor espera. Procure especificamente em:

Valor do cabeçalho Host

• Tamanho e conteúdo do cabeçalho Cookie
• Content-Type e Content-Length para solicitações POST/PUT
• Quaisquer cabeçalhos personalizados injetados por extensões

Prevenir Erros 400 em Aplicações Web

Para programadores e administradores de servidores, medidas proativas reduzem significativamente a incidência de erros 400.

Sanitização e validação de entrada ao nível da aplicação — Valide toda a entrada fornecida pelo utilizador antes de chegar à camada de encaminhamento do servidor. Retorne respostas 400 descritivas com mensagens de erro ao nível do campo em vez de falhas genéricas.

Implementar codificação de URL adequada no código do cliente — Use funções de codificação integradas em vez de manipulação manual de strings:

// JavaScript — correct approach
const query = encodeURIComponent("hello world & more");
const url = `https://example.com/search?q=${query}`;

# Python — correct approach
from urllib.parse import urlencode
params = urlencode({"q": "hello world & more"})
url = f"https://example.com/search?{params}"

Definir limites de tamanho do corpo explícitos e razoáveis — Não deixe client_max_body_size no padrão de 1 MB se a sua aplicação aceitar uploads de ficheiros. Igualmente, não o defina como ilimitado — isto cria um vetor de negação de serviço.

Monitorizar as taxas de 400 em produção — Um pico repentino de erros 400 é frequentemente o primeiro indicador de um bot a analisar vulnerabilidades, um formulário do lado do cliente quebrado, ou uma implementação que introduziu uma alteração de API incompatível. Configure alertas na sua taxa de erros 4xx na sua pilha de monitorização (Grafana, Datadog, CloudWatch).

Usar HTTPS com um certificado SSL válido — Alguns erros 400 surgem quando os clientes enviam solicitações HTTPS para um servidor que não está devidamente configurado para TLS, ou quando uma incompatibilidade de certificado faz com que o handshake TLS falhe antes mesmo de a camada HTTP ser alcançada. Garantir que os seus Certificados SSL são válidos, corretamente instalados e cobrem todos os subdomínios necessários elimina completamente esta classe de erros.

Configurar corretamente os ambientes do painel de controlo — Se gerir vários sites através de um painel de controlo, as definições de host virtual mal configuradas são uma fonte comum de erros 400. Os ambientes que usam VPS com cPanel devem verificar que a raiz do documento de cada domínio, a ligação SSL e as regras de reescrita estão corretamente delimitadas para evitar contaminação de solicitações entre domínios.

Matriz de Decisão: Diagnosticar um Erro 400 por Sintoma

Lista de Verificação Técnica: Resolver um 400 Bad Request

Para utilizadores finais:

• Inspecionar e reescrever manualmente o URL, corrigindo quaisquer problemas de codificação
• Limpar cookies e cache especificamente para o domínio afetado
• Testar numa janela privada/anónima para excluir extensões
• Limpar a cache DNS local
• Testar noutro navegador, dispositivo e ligação de rede

Para programadores e consumidores de API:

• Validar que Content-Type corresponde ao formato do corpo da solicitação
• Confirmar que todos os campos e cabeçalhos obrigatórios estão presentes e corretamente tipados
• Verificar que os valores de string, datas e tipos numéricos estão em conformidade com o contrato da API
• Usar curl com saída detalhada para inspecionar a troca HTTP bruta:

curl -v -X POST https://api.example.com/endpoint 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer YOUR_TOKEN" 
  -d '{"key": "value"}'

Para administradores de servidores:

• Extrair e filtrar os registos de erros do servidor para entradas 400
• Validar a sintaxe da configuração do servidor web (nginx -t / apachectl -t)
• Verificar client_max_body_size (Nginx) e LimitRequestBody (Apache)
• Rever large_client_header_buffers no Nginx se solicitações com muitos cookies estiverem a falhar
• Auditar as regras WAF e verificar o registo de auditoria ModSecurity
• Verificar a validade e cobertura do certificado SSL/TLS
• Confirmar que as regras de reescrita .htaccess estão sintaticamente corretas

—

FAQ

Qual é a diferença entre um erro 400 e um erro 404?

Um erro 400 significa que o servidor não conseguiu compreender a solicitação porque estava malformada — a culpa está na forma como a solicitação foi construída. Um erro 404 significa que a solicitação era válida e compreendida, mas o recurso solicitado simplesmente não existe no servidor. Requerem correções completamente diferentes.

Um erro 400 Bad Request pode ser causado pelo servidor e não pelo cliente?

Sim, indiretamente. Uma má configuração do servidor — como uma regra WAF excessivamente restritiva, uma configuração incorreta de large_client_header_buffers no Nginx, ou uma diretiva .htaccess quebrada — pode fazer com que o servidor rejeite solicitações que são tecnicamente válidas. Nestes casos, a especificação HTTP ainda está a ser seguida (o servidor está a rejeitar o que percebe como uma solicitação incorreta), mas a falha real está na configuração do servidor, não na solicitação do cliente.

Por que razão limpar os cookies resolve um erro 400?

Os cookies são enviados no cabeçalho de solicitação Cookie em cada solicitação ao domínio relevante. Se um cookie armazenado no navegador estiver malformado, expirado de uma forma que o servidor não aceita, ou tiver crescido demasiado (excedendo os limites large_client_header_buffers no Nginx), o servidor rejeita toda a solicitação com um 400 antes de a processar. Eliminar o cookie corrompido remove os dados incorretos do cabeçalho.

Como posso corrigir um erro 400 ao fazer upload de ficheiros para o meu site?

O upload está a exceder o limite de tamanho do corpo do servidor web ou o limite de tamanho de upload do PHP. No Nginx, aumente client_max_body_size em nginx.conf. No Apache, ajuste LimitRequestBody em .htaccess ou httpd.conf. Para aplicações PHP, atualize upload_max_filesize e post_max_size em php.ini, garantindo que post_max_size é maior que upload_max_filesize. Reinicie os serviços relevantes após efetuar as alterações.

Como posso saber se um erro 400 está a vir de um CDN ou WAF em vez do meu servidor de origem?

Verifique os cabeçalhos da resposta. O Cloudflare adiciona cabeçalhos cf-ray e server: cloudflare. O AWS CloudFront adiciona x-amz-cf-id. Se estes cabeçalhos estiverem presentes na resposta 400, a rejeição aconteceu na extremidade, não na sua origem. Reveja os registos WAF do CDN ou o painel de eventos de firewall para identificar qual regra acionou o bloqueio, depois crie uma exceção direcionada para o padrão de tráfego legítimo.