Como Corrigir o Erro 'ERR_TOO_MANY_REDIRECTS'

ERR_TOO_MANY_REDIRECTS significa que o navegador seguiu uma cadeia de redirecionamentos que nunca se resolve — mais comumente URL A → URL B → URL A — e desistiu após atingir o limite interno de saltos.

Se você se deparou com esse erro, provavelmente alterou alguma configuração de proxy ou SSL e então observou cada requisição ficar alternando entre duas URLs em vez de carregar a página. É um erro frustrante justamente porque a página funcionava bem uma hora atrás e nada parece obviamente quebrado. Não se trata de um bug do navegador ou de uma falha transitória; ele sinaliza que duas ou mais regras de redirecionamento na sua stack discordam sobre para onde uma URL deve apontar. Este guia adota uma abordagem diagnóstico-primeiro: você rastreia o loop antes de alterar qualquer configuração e, em seguida, corrige a causa raiz real — que, para a maioria dos desenvolvedores, é uma incompatibilidade de protocolo atrás de um proxy ou CDN, e não um plugin do WordPress.

O que significa ‘ERR_TOO_MANY_REDIRECTS’?

Um loop de redirecionamento ocorre quando seu site continua respondendo a uma URL com um redirecionamento para outra que eventualmente aponta de volta para a primeira, de modo que o navegador nunca alcança uma resposta final 200. Os navegadores limitam o número de saltos que seguirão: o Chromium e o Firefox param em 20, e o Safari para antes — momento em que abandonam a requisição e exibem um erro.

A mensagem varia de acordo com o navegador, mas todas descrevem a mesma condição:

Os próprios redirecionamentos são respostas 3xx comuns, geralmente 301 ou 302, cada uma carregando um cabeçalho Location. Em um loop, os mesmos dois valores de Location se alternam até o navegador desistir.

Diagnostique primeiro: rastreie a cadeia de redirecionamentos

Antes de alterar qualquer configuração, rastreie a cadeia pela linha de comando. O comando curl -I -L https://yourdomain.com imprime os cabeçalhos de resposta para cada salto, e um loop aparece como as mesmas duas URLs se repetindo em linhas Location: sucessivas. No manual do curl, -I (--head) busca apenas os cabeçalhos e -L (--location) segue cada cabeçalho Location até a próxima URL.

Uma origem em loop produz uma saída como esta:

HTTP/2 301
location: https://app.example.com/

HTTP/2 301
location: http://app.example.com/

HTTP/2 301
location: https://app.example.com/
...
curl: (47) Maximum (50) redirects followed

A alternância entre http:// ↔ https:// aqui é a assinatura de um loop por incompatibilidade de protocolo. Se você também quiser os corpos das respostas, use curl -sSL -o /dev/null -D - https://yourdomain.com, que exibe todos os cabeçalhos enquanto descarta o corpo.

Alternativas sem instalação: a aba Network do DevTools do navegador mostra a mesma cadeia de 301/302 com cada Location, e a extensão Redirect Path ou um verificador de redirecionamentos online renderizará a cadeia para uma URL. Em qualquer saída que você usar, procure a URL que se repete: esse par repetido é o loop.

A causa nº 1 para desenvolvedores: loops HTTP↔HTTPS por encerramento de SSL

O loop de redirecionamento mais comum que os desenvolvedores enfrentam não é causado por um plugin. É uma incompatibilidade de protocolo: um proxy ou CDN encerra o TLS e encaminha HTTP simples para sua origem; sua aplicação vê http, redireciona para https, e o ciclo se repete indefinidamente. O navegador se comunica via HTTPS com a borda; a borda se comunica via HTTP com sua aplicação; sua aplicação “prestativamente” redireciona de volta para HTTPS.

No Cloudflare, definir SSL/TLS como Flexible enquanto sua origem também força HTTPS garante um loop, pois o modo Flexible sempre envia HTTP para a origem. O gatilho frequente é o toggle separado “Always Use HTTPS” aplicado em cima do modo Flexible. A correção: instale um certificado na origem e então mude o modo para Full (strict). O conjunto de modos atual é Off, Flexible, Full, Full (strict) e Strict — não os “três modos” que guias mais antigos descrevem.

Atrás do seu próprio proxy ou balanceador de carga, configure a aplicação para confiar no cabeçalho de protocolo encaminhado em vez de redirecionar novamente. O proxy deve enviar X-Forwarded-Proto com o esquema original do navegador, e a aplicação deve lê-lo em vez do salto em texto simples. No Express, habilite trust proxy para que req.protocol e req.secure reflitam o valor encaminhado:

// Trust the first proxy hop, then req.secure reflects X-Forwarded-Proto
app.set('trust proxy', 1);

app.use((req, res, next) => {
  if (!req.secure) {
    return res.redirect(301, `https://${req.headers.host}${req.originalUrl}`);
  }
  next();
});

Sem trust proxy, req.secure permanece false atrás de um proxy que encerra TLS, e esse middleware exato entra em loop. No Nginx fazendo o redirecionamento de origem, proteja a regra com base no esquema encaminhado para que ela não possa ser acionada por tráfego que já chegou como HTTPS:

# Only redirect when the edge saw plain HTTP
if ($http_x_forwarded_proto = "http") {
  return 301 https://$host$request_uri;
}

Um loop em produção que só ocorre para usuários autenticados ou apenas atrás do CDN é invisível para uma execução anônima do curl. Uma reprodução de sessão (session replay) da sessão afetada mostra quais duas URLs estavam alternando sob os cookies e o contexto de borda reais do usuário, reproduzindo a condição que os logs do servidor descrevem, mas não permitem visualizar.

Loops de cookies e guarda de autenticação

Cookies obsoletos e autenticação mal roteada são a segunda grande categoria. Um cookie contendo um estado de redirecionamento antigo, ou uma política HSTS armazenada em cache pelo navegador, pode forçar um único cliente a entrar em loop enquanto todos os outros carregam o site normalmente — esse é o sintoma do “falha na minha janela normal, funciona no modo anônimo”. Limpe os cookies e os dados do site para o domínio afetado primeiro.

A versão programática é um guarda de autenticação que entra em loop na própria página de login. Se /login estiver ela mesma protegida pela regra “redirecionar usuários não autenticados para /login”, cada visita retorna para /login. Exclua a rota de login do guarda. O mesmo acontece quando um manipulador de login redireciona para uma página protegida cujo guarda imediatamente reenvia o usuário de volta, porque o cookie de sessão nunca foi definido — um efeito colateral frequente da incompatibilidade de req.secure mencionada acima, onde um cookie Secure é recusado pelo salto HTTP do proxy.

Erros em regras de redirecionamento: duas camadas em desacordo

Um loop de redirecionamento é quase sempre causado por duas camadas em desacordo sobre a URL canônica (framework, servidor web e CDN, cada um aplicando uma regra diferente), portanto a correção duradoura é gerenciar os redirecionamentos HTTP→HTTPS e www/não-www em exatamente uma camada. Casos clássicos: uma camada força www, outra remove; uma regra cujo destino ainda corresponde à sua própria condição; ou o mesmo redirecionamento duplicado entre framework, host e CDN.

Os frameworks são uma camada de redirecionamento de primeira classe, não um recurso secundário:

• Next.js define redirecionamentos com async redirects() em next.config.js, onde permanent: true emite 308 e false emite 307. Observe que, a partir do Next.js 16, a convenção antiga do arquivo middleware foi renomeada para Proxy (proxy.ts); um middleware.ts remanescente ainda funciona para casos de uso do Edge runtime, mas está depreciado e será removido em uma versão futura, portanto a lógica de redirecionamento ou autenticação ali deve ser migrada para proxy.ts.
• Nginx usa a diretiva return 301: proteja-a, como mostrado acima, para que não seja acionada novamente atrás de um proxy.
• Express usa middleware; mantenha exatamente um middleware de redirecionamento HTTPS na cadeia.
• WordPress é uma instância do mesmo padrão: uma incompatibilidade entre as configurações de WordPress Address e Site Address é simplesmente duas camadas em desacordo, resolvida fazendo ambas coincidirem.

No lado do servidor, o Apache também pode gerar um erro distinto “request exceeded the limit of 10 internal redirects”, cujo limite interno de reescrita de 10 é separado do limite de 20 saltos do navegador — um indício útil de que o loop está no .htaccess, não no cliente. No Cloudflare, coloque o redirecionamento HTTP→HTTPS em uma Redirect Rule no moderno mecanismo de Rules; as Page Rules estão sendo descontinuadas em favor do mecanismo moderno de Rules.

Como prevenir loops de redirecionamento?

A maioria dos loops é introduzida por uma mudança de configuração, portanto faça alterações de redirecionamento de forma deliberada. Mantenha este checklist:

1. Uma camada gerencia cada redirecionamento. Decida se a canonicalização de HTTPS e www/não-www fica no CDN, no servidor web ou na aplicação, e remova as duplicatas das outras duas.
2. Confie no proxy, não redirecione novamente. Atrás de qualquer salto que encerre TLS, leia X-Forwarded-Proto em vez de forçar HTTPS de forma indiscriminada.
3. Rastreie a cadeia novamente após cada alteração. Execute curl -I -L na URL afetada após qualquer mudança de HTTPS, domínio ou estrutura de URL, e confirme que termina em um único 200.

O caminho mais rápido para sair de um loop de redirecionamento é sempre o rastreamento, não o palpite. Execute curl -I -L na URL com falha, encontre as duas URLs alternando nos cabeçalhos Location e, em seguida, corrija a camada que está redirecionando na direção errada — na maioria das vezes, um proxy entregando HTTP para uma origem que insiste em HTTPS.

Perguntas Frequentes

Por que o loop de redirecionamento desaparece no modo anônimo, mas não na minha janela normal do navegador?

O modo anônimo começa sem cookies armazenados nem política HSTS em cache, portanto um loop que persiste na navegação normal, mas desaparece em uma janela privada, aponta para um estado do lado do cliente, não para uma regra do servidor. Um cookie obsoleto contendo um estado de redirecionamento antigo, ou uma política HSTS em cache que força HTTPS em uma origem mal configurada, causará loop apenas no perfil afetado, enquanto outros usuários carregam o site normalmente. Limpe os cookies e os dados do site para o domínio e, se suspeitar de HSTS, inspecione chrome://net-internals/#hsts.

Qual é a diferença entre o SSL Flexible e o Full (strict) do Cloudflare em relação a loops de redirecionamento?

O modo Flexible sempre envia HTTP simples do Cloudflare para sua origem; portanto, se a origem redirecionar à força HTTP para HTTPS, a requisição entrará em loop indefinidamente. O modo Full (strict) envia HTTPS para a origem e valida um certificado confiável lá, correspondendo ao que a origem espera e quebrando o loop. Instale um certificado válido na origem primeiro e, em seguida, mude o modo SSL/TLS de Flexible para Full (strict). O toggle separado 'Always Use HTTPS' aplicado sobre o modo Flexible é um gatilho comum.

Por que o curl e o navegador mostram comportamentos de redirecionamento diferentes para a mesma URL?

O curl é executado como um cliente anônimo sem cookies, sem política HSTS em cache e sem sessão de login, portanto reproduz apenas loops causados por regras de servidor ou CDN que se aplicam a todas as requisições. Loops que dependem de um cookie específico, de uma sessão autenticada ou de uma borda de CDN específica não aparecerão em um rastreamento anônimo com curl. Para esses casos, capture o contexto real do usuário: o DevTools do navegador na sessão afetada, ou uma reprodução de sessão (session replay) mostrando quais duas URLs estavam alternando sob os cookies e o estado de autenticação daquele usuário.

Um redirecionamento do Next.js 16 definido em next.config.js se aplica à navegação do lado do cliente com Link ou router.push?

Ao usar o Pages Router, os redirecionamentos definidos na função redirects() de next.config.js não são aplicados ao roteamento do lado do cliente via Link ou router.push, a menos que um arquivo Proxy — anteriormente middleware — esteja presente e corresponda ao caminho. Os redirecionamentos de next.config.js são executados no servidor para carregamentos completos de página e requisições iniciais, portanto as transições do lado do cliente podem contorná-los. No Next.js 16, a convenção do arquivo middleware foi renomeada para Proxy (proxy.ts); um middleware.ts remanescente deve ser migrado, pois a lógica de redirecionamento e autenticação deixada ali pode parar de funcionar.