ERR_TOO_MANY_REDIRECTS: como corrigir (todos os navegadores)

O que é ERR_TOO_MANY_REDIRECTS?

ERR_TOO_MANY_REDIRECTS significa que a página mandou seu navegador para outro endereço mais de 20 vezes sem nunca carregar: um loop de redirecionamento. O Chrome em português mostra "Esta página não está funcionando" e "Redirecionamento em excesso por example.com"; em inglês, "This page isn't working. example.com redirected you too many times". O Edge mostra uma página parecida, com o mesmo código. O Firefox diz "A página não está sendo redirecionada corretamente" e o Safari, "too many redirects occurred".

Se você só está visitando o site, exclua os cookies daquele site e recarregue a página: um cookie antigo é a causa mais comum quando o site funciona para todo mundo. Se o site é seu, o loop quase sempre é o HTTPS (ou o www) sendo forçado em dois lugares ao mesmo tempo, na maioria das vezes o modo SSL Flexible do Cloudflare somado a um redirecionamento para HTTPS no servidor.

O limite é o mesmo em todo lugar porque o Fetch Standard, que os navegadores implementam, determina: "se a contagem de redirecionamentos da requisição for 20, retorne um erro de rede". O loop em si costuma ser duas respostas 301 ou 302 apontando uma para a outra: a URL A manda você para a URL B, a URL B manda de volta para A, e o navegador para de contar em 20.

O que causa loops de redirecionamento?

Loops de redirecionamento acontecem quando duas ou mais regras de redirecionamento entram em conflito. O servidor envia o navegador para uma URL, e essa URL envia o navegador de volta. Estas são as causas mais comuns:

• Configuração incorreta de SSL/HTTPS — A causa mais comum. Seu servidor força HTTP para HTTPS, mas seu CDN ou load balancer se conecta à origem via HTTP, criando um loop: CDN → HTTP → servidor redireciona para HTTPS → CDN remove HTTPS → HTTP → loop
• Cloudflare Flexible SSL — O modo Flexible SSL do Cloudflare envia requisições para a origem via HTTP. Se a origem também tem um redirecionamento HTTP para HTTPS, você obtém um loop infinito entre o Cloudflare e o servidor
• Regras conflitantes no .htaccess — Múltiplas regras de redirecionamento no .htaccess que se contradizem, como uma regra forçando www e outra forçando sem www simultaneamente
• URLs incompatíveis no WordPress — O Endereço do WordPress (URL) e o Endereço do Site (URL) em Configurações > Geral não correspondem, ou um usa HTTP enquanto o outro usa HTTPS
• Cookies antigos do navegador — Cookies antigos contendo instruções de redirecionamento ou dados de sessão que forçam o navegador a acessar uma URL que não existe mais ou foi movida
• Redirecionamentos em cache no CDN ou proxy — Seu CDN armazenou em cache um redirecionamento 301 antigo que agora conflita com a configuração atual do servidor
• Conflitos na configuração do servidor — Arquivos de configuração do Nginx ou Apache com blocos de redirecionamento concorrentes, como redirecionar tanto no bloco server quanto no .htaccess simultaneamente
• Loops de login em apps — uma página de login que redireciona visitantes não logados para ela mesma, ou um cookie de sessão que o navegador se recusa a guardar (OAuth, Supabase Auth, NextAuth). Veja a Correção 8

Como diagnosticar um loop de redirecionamento

Antes de tentar correções, identifique a cadeia exata de redirecionamento. Isso revela exatamente quais URLs estão envolvidas e quais regras de redirecionamento estão causando o loop.

Método 1: use curl para rastrear redirecionamentos

A maneira mais rápida de ver uma cadeia de redirecionamento é com o curl no terminal. A flag -I busca apenas os cabeçalhos, -L segue os redirecionamentos, e --max-redirs limita quantos serão seguidos:

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

Se você vir as mesmas duas URLs alternando nos cabeçalhos Location, você confirmou um loop de redirecionamento. Observe os códigos de status: 301 é um redirecionamento permanente que os navegadores guardam em cache, e 302 é um redirecionamento temporário que não fica em cache, a menos que a resposta diga o contrário.

Observe o esquema em cada cabeçalho Location: um loop entre as versões http:// e https:// da mesma URL é o padrão mais comum e aponta direto para uma configuração de SSL.

Método 2: aba Network do DevTools do navegador

Você também pode rastrear redirecionamentos visualmente no DevTools do Chrome:

• Passo 1 — Abra o DevTools do Chrome com F12 ou Ctrl+Shift+I (Mac: Cmd+Option+I)
• Passo 2 — Vá para a aba Network e marque Preserve log (isso mantém os registros entre redirecionamentos)
• Passo 3 — Carregue a página que dispara o erro
• Passo 4 — Observe a sequência de requisições. Cada redirecionamento aparece como uma entrada separada com status 301 ou 302. A coluna Location mostra para onde cada redirecionamento aponta

A aba Network mostra a cadeia completa de redirecionamentos em ordem cronológica. Você verá o padrão — normalmente duas ou três URLs se repetindo em ciclo. Use o Verificador de headers HTTP do DNS Robot para inspecionar os cabeçalhos de resposta de fora do cache do seu navegador.

Método 3: verificador online de redirecionamentos

Se você não tem um terminal, cole a URL no Verificador de redirecionamento do DNS Robot. Ele segue cada salto a partir do nosso servidor, mostra cada código de status e cabeçalho Location e avisa quando a cadeia volta para si mesma. Como roda sem os cookies do seu navegador, ele mostra na hora se o loop é do site ou do seu navegador.

Correção 1: limpar cookies e cache do navegador

Comece pela correção mais simples. Cookies antigos ou redirecionamentos em cache no navegador podem causar loops mesmo quando a configuração do servidor está correta. Isso é especialmente comum após a migração de um site de HTTP para HTTPS — cookies antigos podem ainda referenciar URLs HTTP.

Limpar cookies no Chrome

Limpe os cookies do site específico em vez de todos os cookies — isso preserva seus logins em outros sites:

• Passo 1 — Clique no ícone de cadeado (ou ícone de ajuste) na barra de endereço ao lado da URL
• Passo 2 — Clique em Configurações de sites
• Passo 3 — Clique em Excluir dados para remover cookies e dados em cache apenas daquele site
• Passo 4 — Recarregue a página

# Chrome keyboard shortcut to open Delete browsing data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

Ou limpe tudo de todos os sites: pressione Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete) para abrir Excluir dados de navegação, marque Cookies e outros dados de sites e Imagens e arquivos em cache, escolha Todo o período e clique em Excluir dados.

Limpar cookies no Firefox e Safari

Firefox: Pressione Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), marque Cookies e dados de sites e Cache temporário de arquivos e páginas, defina o período para Tudo e clique em Limpar.

Safari: Vá em Safari > Ajustes > Privacidade > Gerenciar Dados de Sites, pesquise o domínio afetado, selecione-o e clique em Remover. Em seguida, limpe o cache com Cmd+Option+E.

Se excluir os cookies resolver, uma regra de redirecionamento no servidor mudou recentemente e seu navegador ainda guardava o estado antigo. Visitantes com sessões novas podem nunca ver o erro.

Redirecionamento em excesso no Gmail, Google Drive ou accounts.google.com

Quando a mensagem cita accounts.google.com, mail.google.com ou drive.google.com, o loop está entre as páginas de login do Google e os cookies do seu navegador, não em um site quebrado. No Chrome em português ela aparece como "Esta página não está funcionando" e "Redirecionamento em excesso por accounts.google.com"; no Chrome em inglês, como "This page isn't working" e "accounts.google.com redirected you too many times.". O login do Google só funciona quando o navegador mantém os cookies do Google, então qualquer coisa que bloqueie ou reescreva esses cookies deixa você andando em círculos:

• Exclua só os cookies do Google — abra chrome://settings/content/all (Ver todos os dados e as permissões do site), pesquise google.com, exclua os dados dele e faça login de novo. Segundo a ajuda do Google, depois você precisará fazer login de novo na sua Conta do Google naquele navegador
• Permita cookies para o Google — tire google.com de qualquer lista de sites que não podem usar cookies e, se você bloqueia cookies de terceiros, adicione [*.]google.com em Sites em que o uso de cookies de terceiros foi permitido (Chrome: Configurações → Privacidade e segurança → Cookies de terceiros)
• Saia de todas as contas e entre com uma só — várias contas conectadas, ou uma conta de trabalho que passa o login para a página de login da própria empresa, podem ficar indo e voltando entre as duas
• Desative extensões de cookies e privacidade — extensões que excluem ou reescrevem cookies durante o login são um gatilho comum. O Chrome mantém as extensões desligadas no modo de navegação anônima, a menos que você as permita, então teste primeiro em uma janela anônima

Correção 2: verificar configuração de SSL/HTTPS

A configuração incorreta de SSL é a causa número 1 de loops de redirecionamento. O cenário mais comum é um conflito entre seu CDN/proxy e seu servidor de origem sobre usar HTTP ou HTTPS.

O que geralmente acontece é o seguinte: seu CDN se conecta à origem via HTTP (porque ele cuida da terminação SSL), mas a origem tem um redirecionamento de HTTP para HTTPS. A origem envia o CDN de volta para HTTPS, o CDN remove o HTTPS e envia HTTP novamente — loop infinito.

Um certificado com problema nessa mesma configuração mostra outro erro; veja ERR_SSL_PROTOCOL_ERROR e "Sua conexão não é particular".

• Verifique seu certificado SSL — Use o Verificador de certificado SSL do DNS Robot para verificar se seu certificado é válido, não está expirado e cobre o domínio correto
• Compatibilize os protocolos — Se seu CDN termina o SSL, remova o redirecionamento HTTP para HTTPS na origem, ou configure o CDN para se conectar à origem via HTTPS
• Verifique as configurações de forçar HTTPS — Se você tem tanto um redirecionamento no servidor (Nginx/Apache) QUANTO um forçar HTTPS no CDN, remova um deles
• Verifique o cabeçalho X-Forwarded-Proto — Quando atrás de um proxy, sua origem deve verificar este cabeçalho em vez do protocolo bruto da conexão para determinar se a requisição original era HTTPS

Correção 3: corrigir loops de redirecionamento do Cloudflare

O Cloudflare é o gatilho mais comum porque o modo de criptografia decide se ele chega ao seu servidor por HTTP ou por HTTPS. A página de solução de problemas do Cloudflare (atualizada em setembro de 2026) lista cinco configurações que geram loop, cada uma combinada com algo que o seu servidor de origem faz:

A correção mais comum para um loop de redirecionamento do Cloudflare: altere o modo de criptografia SSL/TLS de Flexible para Full ou Full (Strict). Isso diz ao Cloudflare para se conectar à origem via HTTPS, eliminando o loop HTTP para HTTPS.

Passo a passo para corrigir no Cloudflare

• Passo 1 — Faça login no painel do Cloudflare
• Passo 2 — Selecione seu domínio
• Passo 3 — Vá em SSL/TLS > Overview
• Passo 4 — Altere o modo de criptografia para Full (strict) se sua origem tem um certificado válido (um certificado Origin CA gratuito do Cloudflare serve), ou para Full só se ele for autoassinado
• Passo 5 — Vá em SSL/TLS > Edge Certificates e verifique se Always Use HTTPS está ativado. Se sua origem já redireciona para HTTPS, desative isso para evitar um redirecionamento duplo
• Passo 6 — Verifique as Page Rules e Redirect Rules em busca de redirecionamentos de URL conflitantes
• Passo 7 — Limpe o cache do Cloudflare: vá em Caching > Configuration > Purge Everything

Correção 4: corrigir regras de redirecionamento no .htaccess (Apache)

Em servidores Apache, o .htaccess é o local mais comum para regras de redirecionamento — e o local mais comum para loops de redirecionamento se originarem. Regras conflitantes, redirecionamentos duplicados ou verificações de condição ausentes podem criar loops.

• Verifique redirecionamentos HTTPS duplicados — Se seu painel de hospedagem (cPanel, Plesk) força HTTPS, remova o redirecionamento manual do .htaccess
• Verifique as condições RewriteCond — Toda RewriteRule que redireciona deve ter uma RewriteCond que impede que ela dispare em URLs que já correspondem. Sem isso, a regra dispara em cada requisição, incluindo a redirecionada
• Atenção à flag [L] — A flag [L] significa 'última regra', mas apenas para a passagem atual. Se outro .htaccess existir em um subdiretório, ele executa novamente. Use [END] no Apache 2.4+ em vez disso
• Verifique os cabeçalhos de proxy — Atrás de um CDN, use %{HTTP:X-Forwarded-Proto} em vez de %{HTTPS} para detectar o protocolo original

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Se você não tem certeza de qual regra causa o loop, renomeie temporariamente o .htaccess para .htaccess.bak e teste se o site carrega. Se carregar, o problema está no seu arquivo .htaccess. Reative as regras uma de cada vez até encontrar a regra que causa o problema.

Correção 5: corrigir loops de redirecionamento no WordPress

Loops de redirecionamento no WordPress geralmente vêm de três fontes: URLs incompatíveis nas Configurações, conflitos de plugins ou valores incorretos no wp-config.php. Se você não consegue acessar o painel do WordPress por causa do loop, será necessário corrigir diretamente no banco de dados ou nos arquivos de configuração.

Verificar configurações de URL do WordPress

O WordPress tem duas configurações de URL que devem corresponder: Endereço do WordPress (URL) e Endereço do Site (URL) em Configurações > Geral. Se um usa http:// e o outro usa https://, ou um tem www. e o outro não, você terá um loop de redirecionamento.

Se você não consegue acessar o painel, defina as URLs diretamente no wp-config.php:

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Desativar plugins para encontrar conflitos

Plugins de redirecionamento e cache são frequentemente os culpados. Plugins como Redirection, Yoast SEO, Really Simple SSL, WP Super Cache e W3 Total Cache podem adicionar regras de redirecionamento que conflitam com as configurações do servidor ou CDN.

Se você não consegue acessar o painel, desative todos os plugins via FTP ou SSH:

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

Se desativar os plugins corrigir o erro, reative-os um por um para identificar o plugin conflitante. Os mais comuns são plugins de SSL que adicionam redirecionamentos HTTP para HTTPS quando o servidor ou CDN já cuida disso.

Correção 6: corrigir redirecionamentos no servidor (Nginx e Apache)

Arquivos de configuração do servidor podem conter regras de redirecionamento que conflitam com redirecionamentos no nível da aplicação (WordPress, .htaccess) ou configurações do CDN.

Nginx: verificar conflitos de redirecionamento

Loops de redirecionamento no Nginx normalmente acontecem quando o bloco server HTTP redireciona para HTTPS, mas algo no bloco HTTPS redireciona de volta para HTTP. Verifique a configuração do seu site:

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Execute nginx -t depois de editar para pegar erros de sintaxe e, em seguida, systemctl reload nginx para aplicar a mudança sem downtime.

Apache: verificar redirecionamentos no VirtualHost

No Apache, verifique tanto a configuração do VirtualHost quanto o .htaccess. Um redirecionamento na configuração do VirtualHost mais um redirecionamento no .htaccess cria um redirecionamento duplo que pode gerar um loop:

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

Remova redirecionamentos duplicados — mantenha o redirecionamento em apenas um local. A melhor prática é lidar com redirecionamentos HTTPS na configuração do VirtualHost (não no .htaccess), pois as regras do VirtualHost são processadas uma vez por requisição, enquanto o .htaccess é processado em cada requisição.

Correção 7: solução de problemas específicos do navegador

Se o erro aparece apenas em um navegador, o problema provavelmente é um redirecionamento em cache ou conflito de extensão, e não um problema no servidor.

Chrome: limpar HSTS e pool de sockets

O Chrome armazena em cache políticas HSTS (HTTP Strict Transport Security) que forçam HTTPS. Se um site anteriormente enviou um cabeçalho HSTS mas não usa mais HTTPS corretamente, o Chrome continuará redirecionando para HTTPS mesmo após limpar os cookies.

• Limpar cache HSTS — Acesse chrome://net-internals/#hsts, insira o domínio em Delete domain security policies e clique em Delete
• Limpar pools de sockets — Acesse chrome://net-internals/#sockets e clique em Flush socket pools para limpar conexões em cache
• Limpar cache DNS — Acesse chrome://net-internals/#dns e clique em Clear host cache (mais maneiras em como fazer flush DNS)
• Testar no modo Anônimo — Abra uma janela Anônima (Ctrl+Shift+N) e teste a URL. Se funcionar no modo Anônimo mas não na janela normal, um redirecionamento em cache ou extensão é a causa

Correções para Firefox e Safari

Firefox: Digite about:config na barra de endereço, pesquise network.http.redirection-limit e verifique se está em 20 (o padrão). Um valor menor, definido manualmente ou por uma política corporativa, faz os redirecionamentos falharem antes. Também tente limpar os dados do site: Configurações > Privacidade e Segurança > Gerenciar Dados > pesquise o domínio > Remover Selecionados.

Safari: O Safari mostra "Safari Can't Open the Page" com "too many redirects occurred" (textos da versão em inglês); o console do Web Inspector diz "Load cannot follow more than 20 redirections". Vá em Safari > Ajustes > Privacidade > Gerenciar Dados de Sites, encontre o domínio e remova os dados dele. Se o loop continuar, teste em uma janela de navegação privada: se ela também entrar em loop, o site está mal configurado.

Correção 8: loops de redirecionamento no login de apps web

Em um app web, o loop muitas vezes está no seu próprio código: uma página que exige usuário logado redireciona para /login, e algo manda /login (ou o callback de login) direto de volta. O console do navegador mostra isso como net::ERR_TOO_MANY_REDIRECTS na requisição que falha.

• A página de login também está protegida — um middleware de autenticação que roda em todas as rotas também redireciona /login e a rota de callback para /login. Exclua essas rotas da verificação
• O cookie de sessão nunca fica salvo — um cookie definido com SameSite=None também precisa ser Secure, senão o navegador o descarta; um cookie definido para o domínio errado nunca é enviado de volta. Nos dois casos, toda requisição continua parecendo deslogada
• A URL de callback não confere — o provedor (Google, GitHub, Supabase Auth) manda os usuários para um callback que seu app não trata, e essa rota redireciona para o login de novo
• HTTP vs HTTPS atrás de um proxy — o app monta as URLs de redirecionamento com http:// porque ignora o X-Forwarded-Proto: o loop da Correção 2, uma camada acima

// Next.js: proxy.ts (middleware.ts before Next.js 16).
// Never run the sign-in check on the sign-in pages themselves.
export const config = {
  matcher: ["/((?!login|auth/callback|_next/static|_next/image|favicon.ico).*)"],
};

Teste a correção com o Verificador de Redirecionamento ou com curl -IL estando deslogado: uma cadeia saudável termina na página de login com um 200, não em outro redirecionamento.

Como prevenir loops de redirecionamento

Após corrigir o erro imediato, siga estas práticas para evitar que loops de redirecionamento aconteçam novamente:

• Redirecione em apenas um local — Escolha uma camada para o redirecionamento HTTPS: o CDN, o servidor web ou a aplicação. Nunca redirecione em múltiplas camadas simultaneamente
• Use 302 durante testes — Enquanto faz debug, use redirecionamentos 302 (temporários) em vez de 301 (permanentes). Os navegadores armazenam 301 em cache agressivamente, dificultando testar alterações. Mude para 301 quando confirmar que o redirecionamento funciona corretamente
• Sempre teste com curl — Após adicionar uma regra de redirecionamento, execute curl -ILs https://seusite.com | grep -i 'HTTP/\|location:' para verificar se a cadeia resolve para uma resposta final 200
• Monitore com ferramentas — Use o Verificador de headers HTTP do DNS Robot regularmente para verificar se seu site retorna uma resposta limpa 200 sem redirecionamentos inesperados
• Documente seus redirecionamentos — Mantenha um registro de todas as regras de redirecionamento na configuração do servidor, .htaccess, regras do CDN e configurações da aplicação. Quando múltiplos membros da equipe gerenciam um site, redirecionamentos não documentados são a causa número 1 de loops
• Limpe o cache do CDN após alterações — Após modificar qualquer regra de redirecionamento, limpe o cache do CDN imediatamente. Redirecionamentos 301 em cache podem persistir por dias

Uma cadeia saudável tem no máximo um ou dois saltos (por exemplo, HTTP → HTTPS → 200 OK). Três ou mais geralmente indicam um redirecionamento de que você não precisa mais.

Impacto dos loops de redirecionamento no SEO

Loops de redirecionamento tiram páginas da busca. A documentação de rastreamento do Google diz que os rastreadores do Google "seguem até 10 saltos de redirecionamento"; um loop nunca chega ao conteúdo, então o Search Console informa um erro de redirecionamento e a URL sai do índice até o loop ser corrigido.

Cadeias longas custam caro mesmo quando terminam: cada salto é mais uma requisição que o navegador e o Googlebot precisam fazer antes de a página carregar, então aponte links e redirecionamentos direto para a URL final.

• Perda de indexação — Páginas presas em loops de redirecionamento não são indexadas e desaparecem completamente dos resultados de busca
• Desperdício de orçamento de rastreamento — O Googlebot gasta seu orçamento limitado de rastreamento seguindo redirecionamentos em vez de rastrear conteúdo real
• Páginas mais lentas — cada salto é mais uma requisição e uma ida e volta antes de qualquer conteúdo carregar, e um salto para outro host ainda precisa de uma nova conexão