ERR_TOO_MANY_REDIRECTS: como encontrar e corrigir um loop de redirecionamento

O navegador exibe ERR_TOO_MANY_REDIRECTS quando uma navegação passa por redirecionamentos repetidos e nunca chega a uma resposta final. O caso mais simples alterna entre duas URLs: http envia para https, enquanto uma aplicação atrás do proxy acredita estar em http e manda de volta. Outros loops dependem de cookies, login, idioma, domínio com ou sem www ou barras no final.

Limpar todos os cookies pode fazer a página abrir para um usuário, mas não explica a origem. Este guia mostra como registrar a cadeia com curl e DevTools, comparar cabeçalhos Location, isolar regras por camada e corrigir o ciclo sem remover redirecionamentos necessários ao SEO ou à segurança.

Legenda: quando A aponta para B e B aponta novamente para A, nenhuma resposta de conteúdo é alcançada.

O que o navegador considera redirecionamento demais

Respostas HTTP da classe 3xx indicam mudança de localização ou um passo intermediário. O cabeçalho Location informa o destino. O navegador segue a resposta automaticamente até obter conteúdo, encontrar erro ou alcançar seu limite interno.

Um loop não precisa repetir exatamente a mesma URL visível. Parâmetros podem crescer:

/login?next=/painel
/login?next=/login?next=/painel
/login?next=/login?next=/login?next=/painel

Também pode alternar status 301, 302, 307 ou 308. A diferença entre temporário, permanente e preservação do método importa, mas qualquer combinação circular permanece um loop.

Capture a cadeia antes de alterar configurações

Use curl sem seguir o destino:

curl -I https://exemplo.test

Observe status e Location. Depois siga redirecionamentos, mostre cabeçalhos e limite o total:

curl -sS -D - -o /dev/null -L --max-redirs 10 https://exemplo.test

Para ver cada URL solicitada com menos ruído:

curl -sS -o /dev/null -L --max-redirs 10 \
  -w '%{url_effective} %{http_code}\n' https://exemplo.test

O resumo final não substitui os cabeçalhos intermediários; guarde a saída de -D -. Remova cookies, tokens e domínios internos antes de compartilhá-la.

No DevTools, abra a aba Network, ative “Preserve log”, recarregue e filtre por Doc. Compare a coluna Status, Request URL e o cabeçalho Location de cada resposta. Essa evidência revela a primeira camada que tomou uma decisão errada.

Reproduza um loop local em segurança

Crie loop.py:

from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        destino = "/b" if self.path == "/a" else "/a"
        self.send_response(302)
        self.send_header("Location", destino)
        self.end_headers()

HTTPServer(("127.0.0.1", 8080), Handler).serve_forever()

Execute python loop.py e, em outro terminal:

curl -I http://127.0.0.1:8080/a
curl -L --max-redirs 5 http://127.0.0.1:8080/a

O primeiro comando mostra apenas /a → /b; o segundo comprova a alternância até o limite. Encerre o servidor com Ctrl+C. Esse laboratório torna o conceito observável sem afetar um site real.

HTTP e HTTPS atrás de proxy reverso

Uma origem recebe tráfego do proxy por HTTP interno, embora o visitante tenha usado HTTPS. Se a aplicação decide redirecionar com base apenas na conexão interna, ela envia https://... repetidamente. O proxy termina TLS, chama a origem em HTTP e o ciclo recomeça.

O proxy costuma informar o protocolo original em Forwarded ou X-Forwarded-Proto. A aplicação só deve confiar nesses cabeçalhos quando a requisição veio de proxies conhecidos; aceitar valores fornecidos diretamente pela internet permite falsificação.

Fluxo correto:

visitante HTTPS → proxy confiável → origem HTTP
                         └─ X-Forwarded-Proto: https

Configure a lista de proxies confiáveis no framework e concentre a regra HTTP→HTTPS em uma camada. Se CDN, balanceador, servidor web e aplicação tentam corrigir o protocolo independentemente, fica mais difícil provar quem gerou cada Location.

Legenda: uma única política canônica evita que camadas discordem sobre protocolo e domínio.

Domínio com www e domínio sem www

Outro ciclo comum:

www.exemplo.com → exemplo.com
exemplo.com → www.exemplo.com

Escolha um host canônico e aplique a mesma decisão na CDN, no servidor e na aplicação. Confirme se a variável usada contém somente o host ou também a porta. Em ambiente de desenvolvimento, uma regra rígida para o domínio público pode redirecionar localhost para produção.

Teste todas as variantes:

for url in \
  http://exemplo.com \
  https://exemplo.com \
  http://www.exemplo.com \
  https://www.exemplo.com
do
  curl -sS -o /dev/null -L --max-redirs 10 \
    -w "$url -> %{url_effective} %{http_code}\n" "$url"
done

Cada entrada deve convergir para uma URL final, preferencialmente com o menor número de saltos. Evite http sem www → https sem www → https com www quando uma resposta direta pode chegar ao canônico.

Cookies, sessão e login circular

O usuário acessa /painel; a aplicação não reconhece a sessão e envia para /login. O login reconhece outra condição e devolve ao painel. Se o cookie não é enviado, o ciclo continua.

Verifique no DevTools:

• domínio e caminho do cookie;
• atributo Secure em ambiente HTTPS;
• política SameSite no fluxo entre sites;
• data de expiração;
• tamanho e número de cookies;
• resposta Set-Cookie e envio posterior em Cookie.

Teste sem cookies e com um arquivo isolado:

curl -c cookies.txt -b cookies.txt -L --max-redirs 10 https://exemplo.test/login

Não publique cookies.txt; ele pode conter uma sessão válida. Apague-o com o mecanismo seguro do sistema após o teste.

Se limpar somente os cookies daquele domínio resolve, investigue migração de formato, assinatura, domínio e regra de autenticação. Limpar todo o navegador sacrifica evidências e pode desconectar o usuário de serviços não relacionados.

Barra final, idioma e normalização de URL

Frameworks podem normalizar /produto para /produto/, enquanto o servidor remove a barra. Plugins de idioma podem mandar / para /pt-br/, e outra regra entende que /pt-br/ deve voltar à raiz. Reescritas que alteram maiúsculas, percent-encoding ou parâmetros também podem oscilar.

Construa uma tabela da cadeia:

Etapa	URL recebida	Status	Location	Camada provável
1	/produto	301	/produto/	framework
2	/produto/	302	/produto	servidor

A tabela transforma uma sensação de “o navegador enlouqueceu” em duas regras concretas. O criador de fluxogramas do IATechNerds pode registrar as condições e destinos antes de editar a configuração.

301, 302, 303, 307 e 308: escolha consciente

301 e 308 comunicam mudança permanente; 302 e 307, temporária. 307 e 308 preservam o método e o corpo. O 303 orienta uma requisição GET ao destino, sendo comum após envio de formulário. A documentação de redirecionamentos HTTP reúne as diferenças.

Uma regra de login não deveria ser armazenada como redirecionamento permanente por engano. Migrações de URL voltadas ao SEO precisam de destino estável, sem cadeias e sem retornar ao endereço antigo.

Ao depurar formulários, use curl -X POST com cuidado: definir -X pode forçar o método após redirecionamentos e não simular exatamente um navegador. Comece com uma requisição sem dados sensíveis e consulte a documentação da aplicação.

Cache, CDN e service worker

Mesmo após corrigir a origem, uma CDN pode manter um 301 em cache. Navegadores também armazenam redirecionamentos permanentes, e um service worker pode interceptar navegações. Compare respostas com e sem CDN usando um ambiente controlado e cabeçalho Host, sem expor diretamente uma origem que deveria ser privada.

No DevTools, ative “Disable cache” enquanto a janela estiver aberta e verifique a coluna “Size” ou indicação de service worker. Em Application, confira os workers registrados. Não remova o worker de todos os usuários como primeira ação; determine se ele participa da navegação.

Inspecione cabeçalhos como Age, Via, identificadores da CDN e Cache-Control. Uma resposta antiga na borda não será corrigida reiniciando apenas a aplicação. Invalide a URL específica conforme o procedimento do provedor e confirme em mais de um ponto.

Ordem segura de correção

Primeiro, capture a cadeia. Depois, identifique a decisão em cada salto: CDN, proxy, servidor, framework, plugin ou código. Desative ou ajuste uma regra por vez em ambiente de teste. Faça todas as variantes convergirem para um canônico e só então limpe o cache relacionado.

Evite substituir temporariamente todos os 301 por 200 em produção. Isso pode expor páginas duplicadas, remover HTTPS ou alterar indexação. A correção deve interromper o ciclo preservando a política desejada.

Depois do ajuste, repita:

curl -sS -o /dev/null -D headers.txt -L --max-redirs 10 https://exemplo.test

Confirme status final 200 ou outro resultado esperado, número de saltos, protocolo, host e ausência de cookies sensíveis no arquivo antes de arquivá-lo.

Quando o loop afeta somente parte dos usuários

Se o erro ocorre apenas para usuários autenticados, uma região, um navegador ou uma conta, compare requisições em vez de concluir que o servidor está saudável. Cookies antigos, sinal de idioma, experimento A/B, regra geográfica e permissões podem selecionar caminhos diferentes.

Crie uma matriz controlada: sessão nova e antiga; autenticado e anônimo; URL com e sem parâmetro; rede corporativa e conexão comum, quando autorizado. Altere uma dimensão por vez. Não peça que usuários enviem cookies ou tokens; esses valores podem conceder acesso à conta.

Um identificador de requisição ajuda a correlacionar a cadeia entre CDN, proxy e aplicação. Gere o ID na primeira camada confiável, propague-o e registre status, host, caminho normalizado e destino sem parâmetros sensíveis. Assim, o suporte consegue localizar os saltos de um caso específico sem reproduzir a sessão da pessoa.

Se uma regra depende de cabeçalho como Accept-Language, User-Agent ou localização, documente a prioridade. O destino não deve imediatamente aplicar uma regra inversa. Por exemplo, a raiz envia português para /pt-br/; essa rota não pode voltar à raiz apenas porque a preferência foi armazenada em cookie.

Teste também a experiência quando cookies são recusados. Autenticação pode exigir armazenamento, mas a página deve explicar a necessidade em vez de alternar silenciosamente entre login e consentimento.

Logs que revelam quem emitiu o Location

Padronize um evento por resposta de redirecionamento:

request_id=7f2 camada=app status=302 host=exemplo.test path=/painel location=/login motivo=sessao_ausente

O campo motivo é mais útil que registrar uma pilha inteira. Defina valores conhecidos como https_obrigatorio, host_canonico, sessao_ausente e idioma. Não inclua query string completa quando ela puder conter e-mail, código ou token.

Compare o mesmo identificador nos logs do proxy e da aplicação. Se o proxy registra 301 antes de encaminhar, a aplicação nunca recebeu aquela etapa. Se a aplicação registra 302, mas o navegador vê 301, a CDN pode ter cacheado ou reescrito a resposta.

Métricas úteis incluem redirecionamentos por requisição, distribuição de destinos e quantidade de respostas que voltam a uma URL já visitada. Um alerta para salto médio crescente pode detectar uma cadeia nova antes que ela atinja o limite do navegador.

Depois da correção, mantenha observação por tempo suficiente para cobrir caches e sessões antigas. Uma queda imediata no erro geral não prova que usuários com cookie legado foram recuperados.

Testes automatizados contra regressão

Uma função simples pode falhar o CI quando há ciclo ou cadeia excessiva:

import urllib.request

url = "https://exemplo.test"
with urllib.request.urlopen(url, timeout=10) as resposta:
    final = resposta.geturl()
    status = resposta.status

assert status == 200, (status, final)
assert final == "https://exemplo.test/", final

Para contar saltos e inspecionar cada Location, use um cliente ou manipulador que exponha o histórico. Mantenha casos para http, https, www, domínio raiz, página de login e URL com barra final. Não execute testes destrutivos nem autentique com credenciais reais em logs públicos.

Use as ferramentas do IATechNerds para organizar verificações e a biblioteca de Python para aprofundar o script de monitoramento.

Checklist para corrigir ERR_TOO_MANY_REDIRECTS

• a cadeia completa foi capturada antes das mudanças;
• cada Location foi associado a uma camada provável;
• HTTP e HTTPS convergem para um protocolo canônico;
• www e domínio raiz convergem para um único host;
• proxies confiáveis estão configurados explicitamente;
• cookies de sessão têm domínio, caminho e atributos corretos;
• barra final, idioma e parâmetros não oscilam;
• CDN, cache do navegador e service worker foram considerados;
• todas as variantes chegam ao destino em poucos saltos;
• testes automatizados protegem o comportamento final.

Documentação primária

• RFC 9110 — redirecionamentos HTTP
• MDN — redirecionamentos em HTTP
• MDN — cabeçalho Location
• curl — manual oficial
• Python — urllib.request

Nota de produção

Rascunho autoral criado para a intenção “como corrigir ERR_TOO_MANY_REDIRECTS”. O laboratório local e os comandos de diagnóstico não dependem de um provedor específico. A semântica dos status foi conferida na RFC 9110 e na documentação da MDN. A revisão humana deve testar os comandos nos sistemas suportados, validar o comportamento do domínio real em ambiente controlado e revisar os links antes de publicar.

Camada extra: como tomar uma decisão melhor neste cenário

Em uso real, ERR_TOO_MANY_REDIRECTS: como encontrar e corrigir um loop de redirecionamento costuma envolver mais de uma camada. O ganho de qualidade aparece quando cada camada tem uma pergunta de verificação antes de qualquer mudança definitiva.

O navegador exibe **ERR_TOO_MANY_REDIRECTS** quando uma navegação passa por redirecionamentos repetidos e nunca chega a uma resposta final. O caso mais simples alterna entre duas URLs: `http` envia para `https`, enquanto uma aplicação atrás A ideia central pode ser testada com quatro perguntas: o que foi observado, qual hipótese explica o sintoma, qual mudança é reversível e qual evidência prova que funcionou. Esse encadeamento evita que uma coincidência seja confundida com causa e torna o procedimento repetível por outra pessoa.

Intenção vale mais que repetição

Em HTTP, redirecionamento, SEO, proxy reverso, a pergunta editorial é: o leitor chegou aqui para aprender, comparar, resolver um erro ou escolher uma ferramenta? O texto precisa responder essa intenção nos primeiros blocos e depois aprofundar critérios, exceções e exemplos. Repetir a mesma expressão de busca em todos os subtítulos pode prejudicar a leitura sem acrescentar contexto.

Uma boa revisão procura lacunas: que pergunta surge depois do primeiro passo? Qual cenário faz a recomendação mudar? O que o leitor precisa medir para saber se melhorou? Essas respostas formam corpo editorial de verdade e evitam parágrafos escritos apenas para aumentar contagem de palavras.

Métricas que contam uma história

Sinal	Interpretação possível	Próxima análise
Impressões sem clique	Snippet pouco atraente ou intenção diferente	Título, descrição e consulta
Clique e saída imediata	Promessa não entregue rápido	Abertura e estrutura
Leitura longa sem ação	Conteúdo útil, CTA fraco ou desnecessário	Objetivo da página

Atualização editorial

Conteúdo tech envelhece. Registre a data de revisão e diferencie conceitos estáveis de telas, preços, limites e versões. Quando uma interface mudar, o artigo continua útil se a lógica de decisão estiver clara; quando ele depende apenas de capturas de tela, precisa ser refeito quase do zero.

Checklist de fechamento

• Registre o estado inicial antes de alterar qualquer coisa.
• Faça uma mudança por rodada e anote o efeito.
• Teste um caso normal, um caso-limite e o cenário que originalmente falhou.
• Confirme que a solução continua válida depois de reiniciar, reabrir ou repetir o fluxo.
• Guarde uma forma de voltar ao estado anterior quando a alteração for destrutiva.

Esse método acrescenta profundidade sem transformar o artigo em teoria abstrata: o leitor entende por que cada passo existe e como reconhecer quando a situação exige uma decisão diferente.