Cole as suas regras de redirecionamento e veja-as rodar salto a salto até o loop aparecer. Cobre loops de HTTPS atrás de proxy, loops de www e loops de cookie, com correções.
O ERR_TOO_MANY_REDIRECTS aparece quando uma página continua mandando o navegador para outro endereço que, no fim, o manda de volta, então a cadeia nunca termina e o navegador desiste. Os culpados de sempre são duas camadas forçando HTTPS ou www em direções opostas. Corrija deixando exatamente uma camada responsável por cada redirecionamento.
Os loops por trás da maioria dos erros de redirecionamentos demais
Loop
Como acontece
Correção
HTTPS atrás de um proxy
O proxy fala HTTP simples com o servidor, que redireciona para HTTPS de novo
Redirecione com base em X-Forwarded-Proto, ou redirecione só no proxy
www versus domínio sem www
Uma camada adiciona www, outra remove
Escolha um host e redirecione para ele em um só lugar
Loop de cookie ou login
A página de login manda você para a página da conta, que manda você de volta porque o cookie nunca foi salvo
Confira as flags Domain, Path e Secure do cookie
Barra no final
Uma regra adiciona a barra, outra remove
Escolha uma forma para todas as URLs
Escreva cada redirecionamento que o seu site faz em uma linha própria, como from -> to, informe o endereço de partida, e o simulador segue a cadeia como um navegador faria. Ele para quando um endereço se repete, quando nenhuma regra corresponde ou depois de 20 saltos, o limite do Fetch Standard.
Liste todos os redirecionamentos que você conhece: configuração do servidor, painel da hospedagem, regras da CDN, código do app.
Escreva um por linha, como endereços completos ligados por ->.
Informe o endereço que falha no navegador e leia a lista de saltos.
Remova ou altere a regra que manda a cadeia de volta a um endereço já visitado.
Limpe os cookies do site antes de testar de novo. Um cookie antigo pode manter um loop de login mesmo depois de a configuração estar corrigida.
Os navegadores guardam redirecionamentos 301 em cache. Teste as correções em uma janela anônima, ou use curl -I para ver cada resposta sem cache nenhum.
Redirecione direto para o endereço final. http://example.com deve ir para https://www.example.com em um salto, não em dois.
Quando uma CDN ou um host oferece uma opção de forçar HTTPS, use ela ou a regra do seu servidor, nunca as duas sem verificar como interagem.
Perguntas frequentes
O que significa redirecionou você muitas vezes?
Essa mensagem e o código de erro ERR_TOO_MANY_REDIRECTS descrevem a mesma coisa: o site respondeu com um redirecionamento atrás do outro e o navegador parou de seguir. Nada no seu computador está quebrado, embora um cookie antigo possa fazer parte do loop.
Quantos redirecionamentos um navegador segue?
O Fetch Standard, que os navegadores implementam, retorna um erro de rede quando a contagem de redirecionamentos de uma requisição chega a 20.
Por que forçar HTTPS causa um loop atrás de um proxy ou CDN?
O visitante se conecta com HTTPS, mas o proxy encaminha a requisição para o seu servidor por HTTP simples. O servidor vê HTTP e redireciona para HTTPS, e o ciclo se repete. A Cloudflare documenta exatamente esse loop no modo de criptografia Flexible.
Limpar os cookies resolve redirecionamentos demais?
Só quando um cookie faz parte do loop, como uma sessão de login que nunca é armazenada. Se o loop está nas regras do servidor, limpar os cookies não muda nada.
Um loop de redirecionamento pode prejudicar o SEO?
Uma página presa em um loop nunca carrega, então os crawlers também não conseguem lê-la. Corrija os loops rápido e mantenha as cadeias de redirecionamento curtas.
Por que os loops acontecem em camadas
Um site moderno costuma ter três ou quatro lugares que podem redirecionar: a CDN, a plataforma de hospedagem, o servidor web e o app. Cada um é configurado em uma tela própria, então dois deles podem discordar em silêncio sobre o esquema, o host ou a barra no final.
O simulador acima modela exatamente isso. Coloque as regras de todas as camadas na mesma lista e a discordância vira um ciclo visível.
O problema do esquema no proxy
Quando o TLS termina em um proxy ou load balancer, o seu servidor só vê HTTP simples. Uma regra que diz para redirecionar tudo o que chega por HTTP para HTTPS dispara então em todas as requisições, incluindo as que eram HTTPS para o visitante. Os proxies enviam o esquema original no cabeçalho X-Forwarded-Proto, então o servidor deve verificar esse cabeçalho.
Configuração que redireciona exatamente uma vez
nginx terminando o próprio TLS
Um bloco server captura toda requisição HTTP e a manda direto para o host final.
nginx atrás de um proxy que termina o TLS
Redirecione só quando o esquema original do visitante, enviado pelo proxy em X-Forwarded-Proto, era http.
Veja cada salto pela linha de comando
-I pede só os cabeçalhos, -L segue os redirecionamentos. Cada bloco da saída é um salto.
Simulador de loop de redirecionamento
Regras de redirecionamento, uma por linha (from -> to)
Endereço de partida
Saltos que o navegador seguiria
Loop: a cadeia volta para {v}, então o navegador para com redirecionamentos demais.
Sem loop: a cadeia termina em {v} depois de {n} redirecionamentos.
A cadeia passou de {n} saltos sem terminar, então o navegador desiste.
Nenhuma regra corresponde ao endereço de partida, então ele carrega sem redirecionamento.