Como resolver "400 Bad Request: Request Header Or Cookie Too Large"?

Apague os cookies daquele site e recarregue a página. O servidor, geralmente nginx, recusa pedidos com cabeçalhos maiores que o buffer dele, e cookies acumulados são o motivo mais comum. O dono do site pode aumentar o large_client_header_buffers, mas a correção de verdade é criar menos cookies.

O erro 400 é culpa minha ou do site?

O servidor está dizendo que o pedido veio errado, então algo do lado de quem enviou precisa mudar. Para um visitante comum, geralmente são cookies antigos ou uma URL errada. Se os próprios formulários do site geram 400, o erro é do site.

Uma API deve responder 400 ou 422 para erro de validação?

As duas escolhas são defensáveis. A RFC 9110 define o 422 para conteúdo sintaticamente correto mas semanticamente inválido, então muitas APIs usam 400 para entrada ilegível e 422 para regra violada. Escolha uma convenção e documente.

O erro 400 pode ser temporário?

Raramente. Reenviar o mesmo pedido traz a mesma resposta. Só parece temporário quando algo muda no meio do caminho, como cookies expirando ou um deploy afrouxando uma regra de validação.

Código de status HTTP · Erros do cliente (4xx)

Erro 400 Bad Request

O erro 400 Bad Request significa que o servidor recebeu o pedido, mas se recusa a processá-lo porque algo nele parece errado: sintaxe quebrada, formato inválido ou dados que ele não consegue interpretar. No navegador, o culpado mais comum é um cookie corrompido ou grande demais; em APIs, é um corpo que não é JSON válido ou não passa na validação.

Dados sobre este código de status
Classe	4xx, Erros do cliente
Definido em	RFC 9110 §15.5.1
Pode ir para o cache por padrão	Só com Cache-Control ou Expires explícitos
Pode repetir o pedido	Só depois de mudar o pedido; reenviar igual falha de novo
Cabeçalhos relevantes	`Content-Type`: application/problem+json (RFC 9457) é um formato padrão para detalhar o erro

O que significa o 400

A RFC 9110, seção 15.5.1, deixa o 400 propositalmente amplo: o servidor "não pode ou não vai processar o pedido por algo percebido como erro do cliente", como sintaxe malformada, enquadramento inválido da mensagem ou roteamento enganoso. Ele é o curinga da classe 4xx, e um cliente que recebe um código 4xx desconhecido deve tratá-lo como 400.

Por ser tão genérico, o código sozinho quase nunca diz o que está errado; espera-se que o servidor explique no corpo da resposta. O nginx, por exemplo, devolve 400 com o texto "Request Header Or Cookie Too Large" quando os cabeçalhos passam do large_client_header_buffers, e "The plain HTTP request was sent to HTTPS port" quando alguém fala HTTP puro numa porta TLS.

Em APIs existe uma divisão antiga entre 400 e 422 para erros de validação. Uma convenção comum: 400 quando o corpo nem pode ser interpretado (JSON inválido, Content-Type errado), 422 quando ele é lido mas os valores quebram regras de negócio. O FastAPI responde 422 para falhas de validação por padrão, enquanto o Express com express.json() responde 400 para JSON ilegível.

Causas comuns

Se você está visitando o site

Os cookies do site ficaram grandes demais ou corrompidos, e os cabeçalhos passam do limite do servidor. É a clássica tela "400 Bad Request: Request Header Or Cookie Too Large".
URL digitada ou codificada errado, como um % solto sem dois dígitos hexadecimais depois, ou caracteres colados de um documento.
Uma extensão do navegador ou uma página antiga em cache enviando um formulário com campos que o servidor não espera mais.

Se você administra o servidor

O cliente mandou um corpo que não é JSON válido (vírgula sobrando, aspas simples) ou mandou JSON com Content-Type: text/plain, e o parser falha.
Faltam parâmetros ou campos obrigatórios, ou eles vêm com o tipo errado, e o handler recusa.
Um pedido HTTP/1.1 sem cabeçalho Host, que a RFC 9112 manda o servidor recusar com 400.
HTTP puro enviado à porta HTTPS, ou um proxy repassando um pedido com cabeçalhos reescritos de forma errada.
Cabeçalhos ou cookies acima do limite do servidor: large_client_header_buffers no nginx, --max-http-header-size no Node.js (16 KB por padrão).

Como resolver

Se você está visitando o site

Apague os cookies só daquele site (no Chrome: ícone de informações na barra de endereço, depois Cookies e dados do site) e recarregue.
Digite a URL à mão em vez de colar, e tire caracteres estranhos ou símbolos no final.
Teste numa janela anônima; se funcionar lá, a causa é uma extensão ou cache antigo.

Se você administra o servidor

Devolva um corpo que diga qual é o problema, como o campo e a regra que ele violou, para o cliente corrigir sem adivinhar.
Valide o pedido antes da regra de negócio e responda 400 para entrada ilegível, em vez de deixar o parser estourar um 500.
Se os usuários tomam 400 por tamanho de cookie, descubra o que fica criando cookies (analytics, testes A/B, sessão inchada) ou aumente o large_client_header_buffers do nginx como paliativo.
Reproduza com curl -v usando exatamente os mesmos cabeçalhos e corpo; a saída detalhada mostra se o problema é o Host, a codificação ou o conteúdo.

Como enviar um 400

Express (Node.js)

app.post('/orders', (req, res) => {
  res.status(400).json({ error: 'quantity must be a positive integer', field: 'quantity' });
});

Next.js App Router (route handler)

// app/orders/route.ts
export async function POST() {
  return Response.json(
    { error: 'quantity must be a positive integer', field: 'quantity' },
    { status: 400 }
  );
}

Go net/http

mux.HandleFunc("POST /orders", func(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(http.StatusBadRequest) // 400
	w.Write([]byte(`{"error":"quantity must be a positive integer","field":"quantity"}`))
})

Python FastAPI

from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI()

@app.post("/orders")
def create_order():
    return JSONResponse(status_code=400, content={"error": "quantity must be a positive integer", "field": "quantity"})

Costuma ser confundido com

400 vs 422: O 422 indica que o corpo foi entendido, mas os valores são inválidos; muitas APIs reservam o 400 para entrada que nem pode ser lida.
400 vs 404: O 404 indica um pedido bem formado para uma URL onde não há nada; o 400 indica que o próprio pedido está quebrado.
400 vs 431: O 431 é o código específico para cabeçalhos grandes demais; o nginx ainda responde 400 para cookies e cabeçalhos excessivos.

Perguntas frequentes

Como resolver "400 Bad Request: Request Header Or Cookie Too Large"?: Apague os cookies daquele site e recarregue a página. O servidor, geralmente nginx, recusa pedidos com cabeçalhos maiores que o buffer dele, e cookies acumulados são o motivo mais comum. O dono do site pode aumentar o large_client_header_buffers, mas a correção de verdade é criar menos cookies.
O erro 400 é culpa minha ou do site?: O servidor está dizendo que o pedido veio errado, então algo do lado de quem enviou precisa mudar. Para um visitante comum, geralmente são cookies antigos ou uma URL errada. Se os próprios formulários do site geram 400, o erro é do site.
Uma API deve responder 400 ou 422 para erro de validação?: As duas escolhas são defensáveis. A RFC 9110 define o 422 para conteúdo sintaticamente correto mas semanticamente inválido, então muitas APIs usam 400 para entrada ilegível e 422 para regra violada. Escolha uma convenção e documente.
O erro 400 pode ser temporário?: Raramente. Reenviar o mesmo pedido traz a mesma resposta. Só parece temporário quando algo muda no meio do caminho, como cookies expirando ou um deploy afrouxando uma regra de validação.

Revisado em 27 de setembro de 2026 por Arielton Oberek.