HTTP 302 Found: o que significa, 302 vs 301 e erro 302

O que é o código de status 302?

HTTP 302 Found é um redirecionamento temporário. O servidor responde "o que você pediu está em outro lugar por enquanto" e informa a outra URL no cabeçalho Location. O navegador carrega essa URL na hora, mas favoritos, links e mecanismos de busca devem continuar usando a original (RFC 9110 §15.4.3).

Esse "por enquanto" é toda a diferença para o 301 Moved Permanently, que diz que a URL antiga acabou de vez. O HTTP/1.0 chamava o 302 de "Moved Temporarily" (RFC 1945); a RFC 2616 o renomeou para "Found" em 1999, mas o significado não mudou.

Como visitante, você quase nunca vê um 302, porque o navegador o segue antes de qualquer coisa aparecer. Você o encontra no DevTools, no curl, em clientes de API e em auditorias de SEO.

Anatomia de uma resposta 302

Uma resposta 302 é pequena. Suas partes:

• Linha de status — HTTP/1.1 302 Found, ou só HTTP/2 302 (o HTTP/2 não tem frase de motivo)
• Location — a URL de destino. A RFC 9110 diz que o servidor DEVERIA enviá-la; sem ela, o navegador não tem para onde ir e mostra o corpo do próprio 302, em geral em branco
• Corpo — a RFC 9110 diz que ele "normalmente contém uma breve nota em hipertexto" com um link. Os navegadores o ignoram; nginx, Apache e Express enviam uma nota de uma linha por padrão, enquanto muitos sites grandes enviam o corpo vazio
• Cabeçalhos de cache — nenhum é necessário. Os navegadores não guardam um 302 em cache, a menos que você adicione Cache-Control: max-age ou Expires; já 301 e 308 são guardados por padrão. Um CDN ainda pode guardá-lo (veja "Um 302 que gruda" abaixo)

HTTP/1.1 302 Found
Location: https://www.example.com/login?next=%2Fdashboard
Content-Length: 0
Date: Mon, 26 Oct 2026 14:00:00 GMT

Location pode ser uma URL completa ou um caminho relativo como /login: a RFC 9110 aceita qualquer referência de URI, e os navegadores a resolvem em relação à URL que pediram. No código do aplicativo (Express, por exemplo), um caminho relativo evita expor um nome de host interno ou um http:// atrás de um proxy; nginx e Apache transformam o caminho em URL absoluta de qualquer forma, a menos que você use absolute_redirect off ou RedirectRelative On.

Por que recebo um 302 em vez de um 200?

Porque a página quer algo que a sua requisição não trouxe, ou a URL usada não é a que o site serve. Os motivos mais comuns:

• Você não está logado — páginas protegidas por login respondem 302 para a página de entrada, com a página que você queria em um parâmetro de retorno. Sem login, github.com/settings leva você a /login?return_to=…. No curl ou em um cliente de API, envie o cookie de sessão ou o token.
• Seu cliente não segue redirecionamentos — navegadores, fetch() e o requests do Python os seguem automaticamente. O curl não, a menos que você use -L; ele para no 302 e imprime só o corpo, muitas vezes nada (adicione -i para ver o status e o Location).
• A URL não é a que o site serve — uma barra final a mais ou a menos, um caminho de idioma, ou um link de rastreamento que redireciona você. O res.redirect() do Express, o return do nginx só com uma URL e o Redirect do Apache enviam 302, a menos que você indique outro código.
• Algo na frente do servidor adiciona o redirecionamento — se o servidor de origem responde 200 quando você o testa direto, mas a URL pública dá 302, uma regra de CDN, balanceador de carga ou proxy está redirecionando.

APIs costumam responder a um login ausente com 401 Unauthorized, não com um redirecionamento. Para ver cada salto e seu código de status, passe a URL pelo Verificador de redirecionamento.

302 vs 301 vs 307 vs 308: qual redirecionamento usar?

Cinco códigos de redirecionamento cobrem quase todos os casos. Eles diferem em dois pontos: se a mudança é permanente e se um POST continua sendo POST:

303 e 307 existem por causa do 302. O HTTP/1.1 acrescentou o 303 em 1997 e, em 1999, a RFC 2616 admitiu que "a maioria das implementações de agentes de usuário existentes trata o 302 como se fosse uma resposta 303", acrescentou o 307 e renomeou o 302 para "Found" (RFC 2616 §10.3.3). Se um redirecionamento temporário puder receber um POST, use 307 para mantê-lo ou 303 para carregar a próxima página com GET.

Quando usar um redirecionamento 302?

Use um 302 quando você espera que o redirecionamento deixe de existir. Casos típicos:

• Redirecionamentos de login — enviar um usuário sem login de /dashboard para /login e trazê-lo de volta depois da entrada
• Testes A/B — enviar parte dos visitantes a uma página variante; a própria orientação do Google para testes diz para usar 302, não 301 (Google Search Central)
• Páginas em reparo — enviar os visitantes a um aviso por alguns dias enquanto uma página é refeita
• URLs de campanhas curtas — /black-friday apontando para a página da promoção deste ano só durante a promoção
• Manutenção — só para visitantes; para os mecanismos de busca, um 503 com Retry-After é a melhor resposta durante uma parada planejada

Se qualquer um desses casos virar permanente, troque para 301.

Como enviar um código de status 302

A maioria dos servidores e frameworks tem uma forma de uma linha para enviar um 302. Cada um dos exemplos abaixo envia 302 Found com um cabeçalho Location, tudo de que um 302 precisa.

Nginx

No nginx, use return com o código. return só com uma URL também envia um 302 (documentação do nginx):

server {
    listen 80;
    server_name example.com;

    # Temporary redirect (302 Found)
    location /old-page {
        return 302 https://example.com/new-page;
    }
}

Apache (.htaccess)

No Apache, use Redirect (302 é o padrão quando você não informa um status) ou um RewriteRule com [R=302,L]:

# Simple temporary redirect
Redirect 302 /old-page https://example.com/new-page

# Or with mod_rewrite for pattern matching
RewriteEngine On
RewriteRule ^maintenance$ /maintenance.html [R=302,L]

Node.js (Express)

O res.redirect() do Express usa 302 por padrão quando nenhum código de status é informado:

// Temporary redirect (302 Found by default)
app.get('/dashboard', (req, res) => {
  if (!req.user) {
    return res.redirect('/login') // sends 302
  }
  // ...render dashboard
})

// Or be explicit:
res.redirect(302, '/login')

Como testar um código de status 302

A verificação mais rápida é o curl no terminal: ele mostra o código de status e o cabeçalho Location sem cache de navegador no caminho.

# Status and headers, without following the redirect
curl -sI https://example.com/old-page

# -I sends HEAD, which some servers answer differently; this sends a real GET
curl -s -o /dev/null -D - https://example.com/old-page

# Expected:
# HTTP/2 302
# location: https://example.com/new-page

# Follow the whole chain and print each hop's status and Location
curl -sL -o /dev/null -D - https://example.com/old-page | grep -iE '^(HTTP/|location:)'

Sem terminal? O Verificador de redirecionamento do DNS Robot segue cada salto (301, 302, 303, 307, 308 e meta refresh) a partir do nosso servidor e mostra cada código de status e a URL final, e o Verificador de headers HTTP mostra os cabeçalhos brutos de cada salto em Redirects.

Redirecionamentos 302 e SEO

O Google trata os dois tipos de redirecionamento como instruções diferentes. Em um redirecionamento temporário (302, 303, 307), o Googlebot o segue, mas o Google não o toma como sinal de que o destino deve ser a URL canônica, então a página de origem normalmente continua nos resultados da pesquisa. O destino ainda pode ser indexado se outros sinais apontarem para ele (Google Search Central).

Um redirecionamento permanente (301, 308) diz o contrário: mostre a nova URL. Então a pergunta real não é "o 302 transfere PageRank?", e sim "qual URL eu quero nos resultados da pesquisa?". A tag rel=canonical é um dos outros sinais; o Verificador de meta tags mostra qual URL uma página declara.

• Use 301 ou 308 para mudanças permanentes — novo domínio, nova estrutura de URLs, páginas unificadas
• Use 302 para as temporárias — logins, testes A/B, campanhas
• Não deixe uma mudança permanente em 302 — o Google pode continuar mostrando a URL antiga
• Mantenha as cadeias curtas — cada salto custa uma ida e volta, e o Googlebot segue até 10 saltos por padrão (Google)

Por que um 302 transforma requisições POST em GET

Esta é a parte mais surpreendente do 302. As primeiras especificações nunca permitiram que os clientes mudassem o método, mas os navegadores transformavam POST em GET em um 302 mesmo assim. Hoje o Fetch Standard, que os navegadores implementam, registra esse hábito: em um 301 ou 302, um POST vira GET e o corpo é descartado (Fetch Standard).

Assim, quando um navegador envia POST /submit-form e o servidor responde 302 Found, o navegador segue com GET /thank-you, e os dados do formulário se perdem. Os navegadores mantêm PUT e DELETE como estão; outros clientes se comportam de outra forma: o requests do Python transforma todo método, exceto HEAD, em GET em um 302, e o curl -L transforma POST em GET em 301, 302 e 303 (--post302 mantém o POST em um 302).

# What you send:
POST /submit-form HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

name=Alice&email=alice@example.com

# Server responds with 302:
HTTP/1.1 302 Found
Location: /thank-you

# Browser follows with GET (form data dropped!):
GET /thank-you HTTP/1.1
Host: example.com

Se você precisa que o redirecionamento preserve o método original (POST continua POST, PUT continua PUT), use 307 Temporary Redirect. Se quer descartar o corpo e passar para GET de propósito — o clássico padrão POST/Redirect/GET — use 303 See Other. Ambos são inequívocos; o 302 não é.

Erros comuns do 302 e como corrigi-los

Quando um 302 dá errado, geralmente é um destes casos:

• Um 302 em vez de um 200 — uma página com login, um cliente que não segue redirecionamentos ou uma variação de URL (veja "Por que recebo um 302" acima)
• Um 302 sem cabeçalho Location — nada pode segui-lo, e o navegador mostra o corpo do próprio 302, em geral em branco. Defina Location antes de enviar o status
• Um 302 que aponta para si mesmo — um loop de redirecionamento: a regra dispara no próprio destino. Adicione a condição que falta
• Um formulário que perde os dados — POST → 302 → GET descarta o corpo. Use 303 para mostrar uma página de resultado de propósito, ou 307 para manter o POST
• Um 302 que gruda — o servidor enviou Cache-Control: max-age ou Expires junto, e os navegadores o guardaram em cache, ou o seu CDN o guardou (em conteúdo que a Cloudflare armazena, ela mantém um 302 por 20 minutos, a menos que os cabeçalhos digam outra coisa, documentação da Cloudflare). Remova esses cabeçalhos, limpe o cache do CDN e do navegador
• Um 302 em produção, mas não no ambiente local — muitas vezes é uma regra de CDN, balanceador de carga ou proxy que adiciona redirecionamentos. Teste a origem diretamente para descobrir

Loops de redirecionamento 302: como diagnosticar

Um loop de redirecionamento é quando a URL A manda você para B e B manda você de volta para A. Depois de 20 redirecionamentos, o limite do Fetch Standard, o Chrome desiste com ERR_TOO_MANY_REDIRECTS e o Firefox com "A página não está sendo redirecionada corretamente".

Uma causa clássica é o modo de criptografia Flexible da Cloudflare: a Cloudflare acessa o seu servidor por HTTP simples, o servidor redireciona HTTP para HTTPS, e a Cloudflare pergunta por HTTP de novo (documentação da Cloudflare).

# Trace the full redirect chain (limit to 10 hops to avoid infinite loops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example of a loop:
# HTTP/2 302
# location: http://example.com/
# HTTP/1.1 302 Found
# Location: https://example.com/
# HTTP/2 302
# location: http://example.com/  <-- loop confirmed

Se a mesma URL continua voltando em Location, seja apontando para si mesma ou com duas URLs se alternando, você tem um loop (com o modo Flexible da Cloudflare, https://example.com/ redireciona para si mesma). Para a correção completa, veja nosso guia sobre ERR_TOO_MANY_REDIRECTS. O Verificador de redirecionamento do DNS Robot rastreia a cadeia a partir do nosso servidor e para onde ela entra em loop.

Boas práticas para o código de status 302

Alguns hábitos evitam a maioria dos problemas com 302:

• Sempre envie um cabeçalho Location — sem ele, nada segue o redirecionamento
• Não adicione cabeçalhos de cache — um 302 sem max-age ou Expires não vai para o cache, que é o que você quer
• Cuidado com URLs absolutas atrás de um proxy — no código do aplicativo, um /login relativo evita expor um nome de host interno ou um http:// no Location; nginx e Apache montam URLs absolutas a partir das próprias configurações
• Mantenha em um único salto — A → B está bem; A → B → C adiciona uma ida e volta para cada visitante
• Nunca use 302 em um POST para outra página — use 303 para mostrar uma página de resultado ou 307 para manter o POST
• Revise redirecionamentos temporários antigos — eles costumam durar mais que o motivo. Verifique-os com o Verificador de redirecionamento
• Troque para 301 assim que a mudança for permanente

Como navegadores e ferramentas tratam um 302

Os clientes concordam em seguir um 302, mas diferem nos limites e no que acontece com o método:

Para a redação exata, veja a definição de 302 na RFC 9110 e a página do MDN sobre o 302.