ERR_TOO_MANY_REDIRECTS

O que este erro significa e como reconhecê-lo

• O navegador exibe “Esta página não está funcionando — [domain] redirecionou você muitas vezes” ou o código de erro ERR_TOO_MANY_REDIRECTS.
• A barra de endereço alterna repetidamente entre HTTP e HTTPS, ou entre hostnames www e não-www, antes de o navegador interromper o carregamento.
• O site inteiro pode falhar, ou o problema pode estar limitado a uma URL, à área administrativa, a sessões autenticadas ou a determinados dispositivos.
• O problema geralmente começa após ativar o HTTPS, adicionar uma CDN ou um reverse proxy, alterar o hostname canônico ou instalar um plugin de redirecionamento ou SSL.
• Limpar os cookies pode alterar temporariamente o comportamento quando há lógica de autenticação ou sessão envolvida, mas isso não corrige um conflito de redirecionamento no servidor.

Causas principais, por probabilidade

1. Regras conflitantes de HTTP/HTTPS — uma camada redireciona HTTP para HTTPS enquanto outra redireciona incorretamente HTTPS de volta para HTTP. Isso ocorre com frequência quando um proxy ou CDN termina o TLS, mas a origem não reconhece que a solicitação original era segura.
2. Incompatibilidade no modo SSL/TLS da CDN — uma CDN pode usar HTTP para se conectar a uma origem que força o HTTPS. A origem redireciona para HTTPS, mas a CDN repete a solicitação HTTP para a origem, criando um loop.
3. Regras canônicas conflitantes entre www e não-www — a CDN, o servidor web, o CMS ou um plugin pode discordar sobre qual hostname é canônico.
4. Processamento incorreto de proxy ou protocolo encaminhado — a aplicação pode não confiar no proxy configurado ou não processar corretamente X-Forwarded-Proto ou um cabeçalho equivalente e, assim, tratar repetidamente uma solicitação segura como HTTP.
5. Cache de redirecionamento desatualizado — um navegador, CDN, reverse proxy ou cache de página pode continuar entregando um redirecionamento de antes da correção da configuração.
6. Regras duplicadas da aplicação ou de plugins — plugins de forçar SSL, login, manutenção ou redirecionamento podem entrar em conflito com regras no nível do servidor.
7. Problemas na configuração de cookies ou sessão — configurações incorretas de Secure, domínio ou caminho podem causar redirecionamentos de autenticação apenas para alguns usuários, especialmente visitantes autenticados.

Como corrigir

1. Capture primeiro a cadeia de redirecionamentos

Use uma solicitação somente leitura no terminal, substituindo o placeholder pelo hostname afetado:

curl -IL https://[your-hostname]

Isso solicita os cabeçalhos e segue os redirecionamentos. Registre cada valor de Location: e cada código de status HTTP. Teste a URL exata que falha, a versão HTTP e as formas www e não-www quando relevante. O painel Network do navegador fornece evidências semelhantes.

Procure padrões como:

• HTTPS → HTTP → HTTPS
• não-www → www → não-www
• uma URL redirecionando repetidamente para ela mesma
• um redirecionamento para uma URL de login ou canônica que redireciona imediatamente de volta

Não comece limpando caches ou alterando várias configurações ao mesmo tempo. A cadeia ajuda a identificar qual camada precisa de atenção.

2. Corrija um loop de HTTP/HTTPS ou da CDN

Se uma CDN ou um reverse proxy gerencia a conexão HTTPS pública, verifique o modo SSL/TLS e o certificado e a configuração HTTPS da origem. O modo de conexão entre a CDN e a origem deve corresponder ao que a origem suporta. Na Cloudflare, uma origem que oferece suporte correto a HTTPS geralmente requer Full ou Full (strict), em vez de Flexible, quando a própria origem força o HTTPS.

Antes de alterar o modo, confirme que você tem autorização para modificar a CDN e que a origem possui um certificado válido para o hostname quando a validação estrita de certificados estiver sendo usada. Alterar as configurações de TLS da CDN pode afetar o tráfego em produção; portanto, siga o processo de mudança aprovado ou os requisitos da janela de manutenção.

3. Corrija a detecção de HTTPS pelo proxy

Se a aplicação força o HTTPS enquanto é executada atrás de um proxy, configure a aplicação ou o framework para confiar no proxy pretendido e reconhecer o protocolo encaminhado. Dependendo da plataforma, as configurações podem ser chamadas de trust proxy, proxies confiáveis ou configurações de force-SSL.

Confie nos cabeçalhos de protocolo encaminhado somente quando vierem de um caminho de proxy conhecido e controlado. Não confie cegamente em cabeçalhos enviados pelo cliente em uma origem diretamente exposta. Consulte a documentação da plataforma para obter a configuração correta e teste novamente a cadeia de redirecionamentos.

4. Resolva a divergência entre www e não-www

Escolha um hostname canônico e documente-o. Inspecione a CDN, a configuração do servidor web, as regras de .htaccess quando aplicável, as configurações de URL do CMS e os plugins de redirecionamento.

Mantenha um único redirecionamento de hostname autoritativo — por exemplo, de não-www para www ou de www para não-www — e remova regras duplicadas ou opostas. Verifique todas as variantes HTTP e HTTPS após a alteração. Uma configuração de URL canônica diferente do destino do servidor web pode recriar o loop mesmo quando o HTTPS está configurado corretamente.

5. Revise o comportamento da aplicação, do login e dos cookies

Se usuários anônimos conseguem carregar a página, mas usuários autenticados não, compare a cadeia de redirecionamentos com e sem o cookie de sessão usando uma conta de teste autorizada ou uma janela privativa. Inspecione os plugins de force-SSL, login, associação e redirecionamento, além da URL do site configurada na aplicação.

Verifique se os cookies de sessão usam o atributo Secure, o domínio e o caminho corretos para o hostname HTTPS escolhido. Desative ou altere um plugin suspeito por vez, seguindo o processo de controle de mudanças. Não remova controles de autenticação ou segurança de um site em produção sem um plano de reversão.

6. Limpe redirecionamentos desatualizados e teste novamente

Depois de corrigir a configuração, limpe as entradas relevantes da CDN, do reverse proxy e do cache de página, se você tiver autorização para isso. Redirecionamentos do navegador também podem persistir; portanto, teste novamente com curl, em uma janela privativa e, se necessário, em outra rede ou dispositivo.

Um teste bem-sucedido deve chegar à página pretendida sem uma sequência Location repetida. Verifique o hostname canônico, o comportamento de HTTP para HTTPS, o fluxo de login e URLs internas representativas, em vez de testar apenas a página inicial.

Prevenção e como verificar a correção

• Documente o hostname canônico e o comportamento pretendido de HTTP para HTTPS antes de adicionar uma CDN, reverse proxy, plugin de CMS ou regra de servidor.
• Sempre que possível, mantenha cada decisão de redirecionamento como autoridade em uma única camada e garanta que as outras camadas não emitam uma regra oposta.
• Ao colocar um site atrás de um proxy, configure deliberadamente o tratamento de proxy confiável e protocolo encaminhado; não aceite indiscriminadamente cabeçalhos de encaminhamento enviados pelo cliente.
• Teste a cadeia completa de redirecionamentos após alterações de HTTPS, hostname, CDN, CMS ou plugins, usando as URLs exatas acessadas pelos usuários.
• Inclua testes anônimos, autenticados, www, não-www, HTTP e HTTPS nas verificações de deploy quando esses caminhos forem compatíveis.
• Limpe ou versione os caches relevantes após alterações de redirecionamento e verifique o resultado em uma janela privativa ou em um cliente limpo.

Perguntas frequentes