Resolva err_too_many_redirects (redirecionamento em excesso)

Você clica em um link para uma loja ou para uma página de login. A aba carrega por um instante e o Chrome mostra "Esta página não está funcionando", uma linha "Redirecionamento em excesso por example.com" e ERR_TOO_MANY_REDIRECTS no final. O Firefox chama isso de "A página não está sendo redirecionada corretamente"; o Safari diz que ocorreram muitos redirecionamentos.

Nada perigoso aconteceu. O site ficou mandando seu navegador de um endereço para outro até o navegador parar de seguir. A seguir: o que é um loop de redirecionamento, as soluções para visitantes, o que mudar se o site é seu (Cloudflare, regras de HTTPS e www, WordPress), um comando que mostra a cadeia e o mesmo erro dentro de um scraper.

O que significa ERR_TOO_MANY_REDIRECTS?#

Um redirecionamento é uma resposta curta do servidor que diz "esta página está em outro lugar, vá para lá", e o navegador a segue sem perguntar nada a você. Os sites usam redirecionamentos o tempo todo: de http:// para https://, de uma página antiga para uma nova, de uma página só para membros para o formulário de login e de volta.

Um loop de redirecionamento é um caminho que nunca termina: a página A manda você para a B, e a B manda você de volta para a A. A RFC 9110, seção 15.4 pede que os clientes detectem redirecionamentos cíclicos e intervenham, e o padrão Fetch que os navegadores implementam encerra uma requisição com um erro de rede depois de 20 redirecionamentos. O Chrome e o Firefox param exatamente aí.

Como o erro aparece em cada navegador?#

Os textos do Chrome e do Firefox vêm dos próprios arquivos de texto dos navegadores e das traduções para o português. Edge, Opera e Brave são feitos sobre o motor do Chrome (Chromium) e mostram o mesmo código.

A página de ajuda arquivada da Apple sobre a mensagem do Safari descreve o mesmo loop. Os três navegadores apontam primeiro para os cookies.

Como um loop de redirecionamento acontece, passo a passo?#

Pense em uma página só para membros:

1. Você abre https://example.com/account.
2. O servidor procura o cookie de sessão, um pequeno trecho de texto que o site guardou antes no seu navegador. Não encontra nenhum e redireciona você para /login.
3. A página de login vê que você está logado do lado dela, cria um cookie novo e manda você de volta.
4. Se o navegador não guarda ou não envia esse cookie (bloqueado, já expirado, criado para outro endereço), o passo 2 se repete.
5. Depois de 20 voltas, o navegador para e mostra o erro.

A outra família não precisa de cookies: duas regras que discordam. Uma camada força https://, outra manda os visitantes de volta para http://; ou uma regra adiciona www. e outra o remove.

O que causa o erro e de quem é o problema?#

Como resolver sendo visitante?#

Recarregue a página depois de cada passo.

1. Tente uma janela anônima. No Chrome, selecione Mais > Nova janela anônima. Ela abre sem cookies, e as extensões só rodam nela se você permitiu. Se a página abrir, a causa é um cookie ou uma extensão.
2. Exclua os cookies desse único site, o que aparece na mensagem. Com isso, você sai da conta apenas nesse site.
   • Chrome no computador: Mais > Configurações > Privacidade e segurança > Cookies de terceiros > Ver todos os dados e as permissões do site, pesquise o site e selecione Excluir (passos do Google).
   • Chrome no Android: no site, toque em Informações da página à esquerda da barra de endereço, depois em Cookies e dados de sites e em Excluir.
   • Firefox: clique no ícone de escudo à esquerda da barra de endereços e depois em Limpar cookies e dados do site (passos da Mozilla).
   • Safari no Mac: Safari > Ajustes > Privacidade > Gerenciar Dados de Sites, selecione o site e clique em Remover (passos da Apple).
   • Safari no iPhone: Ajustes > Apps > Safari > Avançado > Dados do Site > Remover Todos os Dados. Isso apaga os dados de todos os sites, então você vai precisar entrar de novo em outros lugares.
3. Desative as extensões. Bloqueadores de anúncios, ferramentas de privacidade e extensões de "sempre HTTPS" ou de VPN podem mudar o destino de uma página. No Chrome, abra Mais > Extensões > Gerenciar extensões e desative uma de cada vez (passos do Google).
4. Confira a data e a hora. O navegador descarta um cookie cuja data de validade já passou pelo relógio do seu dispositivo (RFC 6265, seção 5.3), então um relógio adiantado em vários dias pode fazer sumir um cookie de sessão recém-criado. No Windows, selecione Iniciar > Configurações > Hora e idioma > Data e hora e ative Definir horário automaticamente (passos da Microsoft). Um relógio errado também causa o aviso Sua conexão não é particular.
5. Desligue a VPN ou o proxy e recarregue; a próxima seção explica o porquê.
6. Teste outra rede. Se a página também falha no celular pelos dados móveis, o loop está no site: informe ao dono o endereço e o horário, e espere. Uma página que nem consegue se conectar mostra outro erro.

Por que isso acontece tanto no login?#

O login pula entre endereços de propósito: uma loja manda você para um serviço de login (o dela, o do Google ou o da Microsoft), que cria um cookie e manda você de volta. Se o cookie de qualquer um dos lados está faltando ou bloqueado, você dá outra volta. Quando a mensagem cita o serviço, como em "Redirecionamento em excesso por accounts.google.com", exclua os cookies desse serviço além dos do site, e permita cookies para os dois se você os bloqueia.

Por que uma VPN ou um proxy às vezes causa um loop de redirecionamento?#

Muitos sites escolhem uma versão por país a partir do seu endereço IP, como /de/ para a Alemanha, e também guardam a escolha em um cookie. Quando o IP diz um país e o cookie diz outro, as duas regras podem mandar você de um lado para o outro (O que é bloqueio geográfico e como os sites localizam você?).

Uma VPN muda o país que o site vê, e um proxy rotativo pode até enviar dois passos da mesma cadeia a partir de dois endereços. Desligue a VPN e recarregue; se funcionar, exclua os cookies do site antes de reconectar ou escolha o país no próprio site. Se você navega por um proxy de propósito, mantenha uma única saída durante a visita: os Proxies de sessão fixa mantêm o mesmo IP por um tempo definido (Diferença entre proxy e VPN).

Se o site é seu: de onde vem o loop?#

Leia primeiro a cadeia (seção "Nível avançado", mais abaixo); o padrão dela aponta a regra errada.

O modo SSL Flexible do Cloudflare#

No modo Flexible, os visitantes chegam ao Cloudflare por HTTPS, mas o Cloudflare se conecta ao seu servidor por HTTP sem criptografia (modos de criptografia do Cloudflare). Um servidor que redireciona HTTP para HTTPS vê cada requisição do Cloudflare como HTTP e redireciona de novo, então https://example.com/ redireciona para si mesmo.

No painel, abra SSL/TLS > Overview (Visão geral) e escolha Full (strict) quando o servidor tiver um certificado válido, ou Full enquanto você obtém um. O inverso também gera loop: Full com um servidor que manda HTTPS de volta para HTTP. A página do Cloudflare sobre esse erro também cita Always Use HTTPS, HSTS e regras de redirecionamento conflitantes.

Regras de HTTPS e www em dois lugares#

Um painel de hospedagem adiciona www. enquanto a aplicação o remove, ou uma CDN força HTTPS enquanto o servidor força HTTP. Escolha um único endereço público, aplique-o em uma só camada e apague as outras regras, incluindo plugins de redirecionamento e linhas do .htaccess. Forward proxy e reverse proxy: qual é a diferença? explica qual camada vê o quê quando há uma CDN na frente.

As configurações de endereço do WordPress#

O WordPress monta os redirecionamentos a partir de Endereço do WordPress (URL) e Endereço do site (URL), em Configurações > Geral. O guia do WordPress diz que os dois precisam de https:// e de nenhuma barra no final; um esquema errado ou um www a mais faz os visitantes andarem em círculos. Se o loop impedir o acesso ao painel, defina os valores no wp-config.php:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Atrás de um balanceador de carga ou reverse proxy que cuida do HTTPS enquanto o WordPress roda em HTTP sem criptografia, o WordPress trata cada requisição como insegura e, nas palavras da documentação, cai em um loop de redirecionamento infinito. Deixe o WordPress ler o cabeçalho X-Forwarded-Proto do proxy, como mostra o guia de HTTPS.

Teste a correção em uma janela anônima#

O padrão HTTP permite que os navegadores guardem um redirecionamento 301 ("Moved Permanently"), então seu próprio navegador pode continuar em loop depois da correção. Teste em uma janela anônima e use redirecionamentos temporários 302 enquanto faz experimentos.

Nível avançado: veja a cadeia de redirecionamentos com um comando#

Para quem se sente à vontade com a linha de comando: o curl vem no Windows 10, no Windows 11 e no macOS (no PowerShell, digite curl.exe). Este comando segue os redirecionamentos, mostra os cabeçalhos de cada passo e para depois de dez:

curl -sSIL --max-redirs 10 https://example.com/

Rodamos o comando contra um servidor de teste no nosso computador que reproduz o loop do Flexible. Linhas principais, resumidas (curl 8.21.0, Windows 11):

HTTP/1.1 301 Moved Permanently
Location: https://example.com/
HTTP/1.1 301 Moved Permanently
Location: https://example.com/
HTTP/1.1 301 Moved Permanently
Location: https://example.com/
curl: (47) Maximum (10) redirects followed

Como ler:

• Location repete o endereço que você pediu: o servidor acha que a requisição chegou por HTTP (modo Flexible ou um proxy que descarta X-Forwarded-Proto).
• O endereço alterna entre duas formas, como com e sem www: duas regras discordam.
• Alterna entre uma página e uma página de login: um cookie não está sendo mantido; confira as linhas Set-Cookie.
• Termina com 200: o servidor está bem, e o loop está nos cookies ou no cache de um navegador.

Se você está escrevendo um scraper ou crawler#

Provocamos as duas mensagens abaixo contra uma página de teste em loop:

O Requests desiste depois de 30 redirecionamentos, os navegadores depois de 20, e aumentar o limite nunca ajuda. As causas comuns no código:

• Nenhum pote de cookies compartilhado. Chamadas separadas de requests.get() não compartilham cookies; use uma requests.Session() por site (Sessões e cookies em Python).
• Um cookie que o seu cliente nunca recebe. Algumas páginas criam o cookie com JavaScript ou com um clique, como em um banner de consentimento, e um cliente HTTP simples nunca executa nada disso. Nesses casos, use a API do site ou um navegador de verdade. Se a cadeia termina em uma página de bloqueio, pare: essa é a decisão do site (Sorry, you have been blocked: o que é e por que aparece).
• O IP de saída muda no meio do caminho. Com rotação por requisição, cada passo pode sair de um IP diferente, até de outro país, e um site que escolhe a versão por país pelo IP manda o passo dois para um lugar que o passo um nunca pediu. Mantenha uma saída por cadeia com uma sessão fixa e defina o país pela segmentação geográfica; os Proxies residenciais oferecem as duas coisas (O que é rotação de IP e como ela funciona?).

Para ver onde uma cadeia faz a volta, siga-a um passo de cada vez:

from urllib.parse import urljoin, urlsplit

import requests

PROXY = "http://user:pass@pr.proxynet.io:8000"  # use um nome de usuário com sessão fixa
START = "https://example.com/account"


def trace(url, session, max_hops=10):
    """Segue os redirecionamentos um a um e para na primeira repetição."""
    seen = set()
    for hop in range(max_hops):
        r = session.get(url, allow_redirects=False, timeout=15)
        target = r.headers.get("Location", "")
        cookie = "sets a cookie" if "Set-Cookie" in r.headers else "no cookie"
        print(hop, r.status_code, urlsplit(url).path, "->", target, f"({cookie})")
        if not r.is_redirect:
            return r
        if url in seen:
            print("Loop found: this URL was already requested")
            return None
        seen.add(url)
        url = urljoin(url, target)
    print(f"Stopped after {max_hops} hops")
    return None


with requests.Session() as s:  # um único pote de cookies para toda a cadeia
    s.proxies = {"http": PROXY, "https": PROXY}
    s.headers["User-Agent"] = "example-crawler/1.0 (+https://example.com/bot)"
    trace(START, s)

Rodamos o código por um proxy de teste local com autenticação user:pass contra uma página de teste que reproduz um loop de consentimento, em que o cookie normalmente viria de um botão (requests 2.34.2, Python 3.13):

0 302 /account -> /consent (no cookie)
1 302 /consent -> /account (no cookie)
2 302 /account -> /consent (no cookie)
Loop found: this URL was already requested

Nenhum passo cria um cookie, então este cliente nunca chega a /account. Se um passo cria um cookie e o loop continua, compare o domínio e o caminho do cookie com o próximo endereço e depois confira se o seu IP de saída continuou o mesmo. Depure com educação: uma cadeia por vez, um User-Agent que identifique você e as regras do robots.txt.

Onde você pode encontrar esse erro#

• Links de anúncios que passam por vários redirecionamentos de rastreamento, verificados a partir de um IP (Como funciona a verificação de anúncios com proxies).
• Crawlers que encontram um loop depois da migração de um site (Como criar um web crawler em Python).
• Ferramentas de monitoramento que acusam um loop depois de uma mudança de configuração (Como monitorar alterações em um site).
• Automação de navegador com um perfil novo ou um proxy (Playwright com proxy).

Erros comuns#

• Excluir todos os cookies primeiro. Isso faz você sair da conta em todos os sites; comece pelo site citado na mensagem.
• Reinstalar o navegador ou reiniciar o roteador. O loop está em um cookie, em uma extensão ou nas regras do site.
• Aumentar o limite de redirecionamentos no código. Um loop continua sendo um loop com 30 saltos e com 100.
• Testar uma correção do servidor no mesmo navegador, onde um 301 memorizado mantém o loop antigo vivo.
• Desativar o HTTPS para parar o loop em vez de fazer as camadas concordarem.

Guia de decisão#

Perguntas frequentes#

ERR_TOO_MANY_REDIRECTS é vírus ou sinal de invasão?#

Não. Vem de um cookie, de uma extensão ou das próprias regras de redirecionamento do site, e o navegador parou de propósito.

Por que o erro aparece em um site e não em outros?#

O loop está nas regras desse site ou nos cookies guardados para ele; os outros sites têm os seus.

Preciso excluir todos os meus cookies?#

Não. Exclua os cookies do site citado na mensagem e, se o loop começa no login, os do serviço de login. Com isso, você sai da conta apenas nesses sites.

Por que o loop só acontece com a VPN ligada?#

O site escolhe uma versão por país a partir do seu IP, enquanto um cookie lembra outra. Desligue a VPN, exclua os cookies do site e reconecte, ou escolha o país no site.

Quantos redirecionamentos o Chrome permite?#

Vinte, o limite do padrão Fetch; o Firefox usa o mesmo número, e a biblioteca Requests do Python, 30. Uma página normal precisa de um ou dois.

Como resolver redirecionamento em excesso no Cloudflare?#

Mude o modo SSL/TLS para Full (strict), que exige um certificado válido no servidor, ou retire o redirecionamento de HTTP para HTTPS do próprio servidor se continuar no Flexible. Depois, confira Always Use HTTPS, o HSTS e as suas regras de redirecionamento em busca de duplicatas.

Em resumo#

ERR_TOO_MANY_REDIRECTS significa que um site fez seu navegador andar em círculos e que o navegador parou depois de 20 saltos. Os visitantes resolvem a maioria dos casos excluindo os cookies de um site, tentando uma janela anônima, desativando extensões e VPN e conferindo o relógio; um loop em todos os dispositivos precisa ser corrigido pelo próprio site. Os donos devem procurar duas regras que discordam. No código, mantenha uma sessão e uma saída fixa por cadeia. Você pode comparar os tipos de proxy e seus usos na nossa página de proxies.