ERR_TOO_MANY_REDIRECTS: causas de um loop e como corrigir

O que significa ERR_TOO_MANY_REDIRECTS

Um redirecionamento diz ao navegador "a página que você quer está em outro lugar, vá para lá". Um único redirecionamento, ou até dois ou três em sequência, é normal: um domínio sem www encaminhando para www, ou uma URL antiga encaminhando para a nova. Um loop acontece quando uma URL redireciona para uma segunda que redireciona de volta para a primeira, ou para si mesma. Como o navegador nunca chega a uma página que realmente devolve conteúdo, ele interrompe a cadeia e mostra o erro em vez de ficar preso indefinidamente.

Como o erro aparece

Chrome e Edge mostram "Esta página não está funcionando - redirecionou você muitas vezes" com o código ERR_TOO_MANY_REDIRECTS. O Firefox mostra "A página não está sendo redirecionada corretamente". O Safari diz "O Safari não pode abrir a página porque ocorreram muitos redirecionamentos".

O curl com a flag -L segue os redirecionamentos do mesmo jeito que um navegador, e imprimir cada salto mostra exatamente onde o loop se repete:

curl -sIL https://example.com/ | grep -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/1.1 301 Moved Permanently
location: http://example.com/

Esse padrão, de HTTP para HTTPS e de volta para HTTP, é a forma mais comum desse erro. O curl para sozinho no seu limite padrão (50 redirecionamentos) em vez de seguir para sempre, e as linhas location se repetindo deixam o loop óbvio sem precisar nem abrir um navegador.

O que causa um loop de redirecionamento

• Um desencontro entre HTTP e HTTPS envolvendo um proxy ou CDN e a origem. Esse é o caso clássico. Se o modo SSL/TLS do Cloudflare está definido como Flexible, o Cloudflare encerra o TLS na borda e se conecta à origem por HTTP simples. Se a origem também tem uma regra que redireciona todo HTTP para HTTPS (um padrão de segurança comum), a origem manda o navegador de volta para HTTPS, o Cloudflare rebaixa para HTTP de novo no próximo salto, e as duas configurações brigam eternamente.
• Regras de www e sem www apontando uma para a outra. Uma regra redireciona o domínio puro para www, e uma regra separada, muitas vezes adicionada depois por outro administrador ou plugin, redireciona www de volta para o domínio puro.
• Um desencontro no siteurl ou home do WordPress. Se a URL configurada do site no banco de dados não corresponde à URL que os visitantes realmente usam (uma URL de staging esquecida, um desencontro de esquema depois de adicionar SSL), o WordPress continua redirecionando na direção do valor configurado.
• Cookies que o servidor espera mas nunca recebe, ou um redirecionamento de login que falha silenciosamente. Uma página que redireciona visitantes não autenticados para uma etapa de login, que redireciona de volta para a mesma página porque o cookie de sessão nunca foi gravado (muitas vezes bloqueado pelas regras de cookies de terceiros do navegador ou por um atributo Secure/SameSite ausente), entra em loop indefinidamente.
• Regras de barra final ou de prefixo de idioma que se contradizem. Uma regra adiciona uma barra final, outra remove; uma regra adiciona um prefixo de idioma baseado na localidade do navegador, outra remove para manter URLs canônicas, e as duas se anulam.
• Uma camada de cache servindo um redirecionamento desatualizado. Um CDN ou proxy reverso guardou em cache um 301 antigo que apontava para uma URL que, depois de alterada, redireciona de volta para a original.

Como saber de quem é a culpa

Se o loop acontece para todo visitante em toda rede, é um problema de configuração do servidor ou do CDN, não algo local. Se acontece só com você, limpe os cookies do site primeiro, já que um cookie de sessão ruim ou expirado causa boa parte dos loops que afetam um único visitante. Rodar uma verificação HTTP a partir de vários locais resolve isso numa única requisição: se a mesma cadeia de redirecionamento (ou a mesma falha) aparece em todo lugar, a correção é do lado do servidor.

Como corrigir o ERR_TOO_MANY_REDIRECTS

Se você é o visitante

1. Limpe os cookies do site. No Chrome, clique no cadeado ou no ícone de ajustes ao lado da barra de endereço, abra as configurações do site e limpe cookies e dados apenas daquele domínio.
2. Tente uma janela anônima ou privada. Isso descarta uma extensão do navegador ou um cookie salvo como causa, sem mexer no seu perfil normal.
3. Tente outra rede, como dados móveis em vez de Wi-Fi. Alguns proxies corporativos ou de provedores de internet reescrevem as requisições de um jeito que cria um loop só naquela rede.
4. Limpe o cache do navegador, caso o próprio redirecionamento tenha sido cacheado de antes do site ser corrigido.

Se você administra o site

1. Confira o modo SSL do seu CDN contra a regra de redirecionamento da sua origem. No Cloudflare, abra SSL/TLS e defina o modo como Full ou Full (strict), não Flexible, sempre que a origem redirecionar HTTP para HTTPS. O Full ainda permite que a origem use um certificado autoassinado; o Full (strict) exige um certificado válido.
2. Confie no cabeçalho de protocolo encaminhado em vez de redirecionar às cegas. Quando um proxy fica na frente da sua aplicação, a origem precisa redirecionar com base no X-Forwarded-Proto, não na conexão bruta, que sempre parece HTTP vista de trás do proxy. No nginx:

   if ($http_x_forwarded_proto = "http") {
       return 301 https://$host$request_uri;
   }

   e confirme que o CDN ou balanceador de carga está de fato definindo esse cabeçalho em toda requisição.
3. Revise suas regras de redirecionamento em ordem, incluindo .htaccess, blocos server do nginx, middleware da aplicação e qualquer regra de página do CDN, procurando duas regras que apontam uma para a outra. Um padrão comum do Apache que entra em loop atrás de um proxy:

   RewriteCond %{HTTPS} off
   RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

   falha do mesmo jeito que o caso do nginx acima, já que %{HTTPS} lê a conexão que o proxy faz, não a que o visitante fez; verifique %{HTTP:X-Forwarded-Proto} em vez disso.
4. Corrija a URL do site no WordPress, se for o caso: em wp-admin > Configurações > Geral, confirme que tanto o Endereço do WordPress quanto o Endereço do Site correspondem à URL que os visitantes realmente usam, protocolo incluído. Se o próprio painel de administração ficou inacessível por causa do loop, defina WP_HOME e WP_SITEURL diretamente no wp-config.php.
5. Escolha uma forma canônica e redirecione tudo o resto para ela uma única vez, não em cadeia: com ou sem www, com ou sem barra final, uma regra por decisão em vez de várias regras acumuladas por ferramentas diferentes ao longo do tempo.
6. Limpe o cache do CDN depois de corrigir a regra, já que um 301 ou 302 cacheado continua enviando a resposta antiga até expirar ou ser limpo.

Erros relacionados

• Códigos de status de redirecionamento 3xx explica o que 301, 302, 303, 307 e 308 significam individualmente.
• 301 versus 302 aborda quando um redirecionamento deve ser permanente ou temporário, o que importa para mecanismos de busca e cache, não só para loops.

Como prevenir o ERR_TOO_MANY_REDIRECTS

Um loop de redirecionamento quase sempre surge de uma mudança de configuração: um novo CDN, um novo certificado SSL, uma atualização de plugin ou uma migração que mexeu na URL do site. Uma verificação HTTP que acompanha o código de resposta e segue redirecionamentos em intervalos regulares detecta um loop no momento em que ele aparece, a partir de mais de 300 pontos de verificação em 158 cidades, em vez de esperar por um chamado de suporte. A HostTracker monitora sites desde 2004 e pode avisar por e-mail, SMS, chamada de voz, Slack, Telegram e outros canais assim que uma verificação começa a falhar.

Perguntas frequentes

Quantos redirecionamentos um navegador aceita antes de desistir?

Chrome e navegadores baseados em Chromium param por volta de 20. O limite padrão do curl com -L é 50. O número exato varia por cliente, mas todos eles eventualmente param em vez de seguir um loop para sempre.

Por que o loop só começou depois que mudei para o Cloudflare (ou outro CDN)?

Quase sempre é o modo SSL/TLS. O modo Flexible fala HTTP simples com a origem; se a origem insiste em HTTPS, os dois lados se redirecionam indefinidamente. Mudar para Full ou Full (strict) costuma resolver na hora.

Uma extensão do navegador pode causar isso?

Sim, principalmente extensões que forçam HTTPS, reescrevem requisições ou gerenciam cookies. Testar numa janela anônima com extensões desativadas descarta isso rapidamente.

Isso afeta o SEO?

Sim. Os rastreadores dos mecanismos de busca desistem de um loop de redirecionamento do mesmo jeito que um navegador, e uma URL em loop não vai ser indexada ou vai sair do índice se antes funcionava.

Vejo o erro só numa página específica, não no site todo. O que é diferente nela?

Procure uma regra específica daquela página: uma página que exige login, um redirecionamento antigo cacheado só para aquela URL, ou um desencontro de barra final que existe só naquela rota. Compare a cadeia de redirecionamento exata dessa URL com uma página que funciona usando curl -sIL.

Um único redirecionamento (como de sem www para com www) é algo que precisa corrigir?

Não, um único redirecionamento por si só é normal e esperado. Só uma cadeia que se repete e nunca chega a uma resposta 200 final é o problema que este erro descreve.