Causas Subjacentes e Correções para o Erro “Too Many Redirects”

O erro "Too Many Redirects" — exibido nos navegadores como ERR_TOO_MANY_REDIRECTS e correspondendo a um loop de redirecionamento HTTP — ocorre quando um servidor web e um cliente entram numa cadeia circular de redirecionamentos que nunca resolve para um destino final. O navegador interrompe o pedido após exceder o seu limite de redirecionamentos (tipicamente 20 saltos no Chrome) e apresenta este erro em vez de carregar a página.

Isto não é uma falha de rede vaga. É uma falha determinística causada por uma configuração incorreta específica nas regras do seu servidor, definições SSL, valores da base de dados do CMS, configuração do CDN ou dados de redirecionamento em cache. Cada instância tem uma causa raiz rastreável, e cada causa raiz tem uma correção precisa. Este guia percorre todas elas com a profundidade técnica necessária para resolver o problema permanentemente — seja a executar um site WordPress, uma aplicação personalizada ou uma stack de servidor puro num ambiente de VPS Hosting.

O Que Acontece Realmente Durante um Loop de Redirecionamento

Quando um navegador solicita um URL, o servidor pode responder com um código de estado 301 Moved Permanently, 302 Found ou 307 Temporary Redirect apontando para uma nova localização. O navegador segue esse cabeçalho de localização, faz outro pedido e espera uma resposta 200 OK em algum ponto da cadeia.

Um loop de redirecionamento forma-se quando:

• O URL A redireciona para o URL B, e o URL B redireciona de volta para o URL A (loop de dois saltos)
• O URL A redireciona para o URL B, que redireciona para o URL C, que redireciona de volta para o URL A (loop de múltiplos saltos)
• Um único URL redireciona para si mesmo (loop auto-referencial)

Os navegadores não fazem loops indefinidamente. O Chrome e o Firefox terminam ambos após aproximadamente 20 redirecionamentos e exibem ERR_TOO_MANY_REDIRECTS. O Safari mostra "Safari Can't Open the Page." O comportamento HTTP subjacente é idêntico em todos eles.

Causas Raiz e Correções Precisas

1. Regras de Redirecionamento Mal Configuradas no .htaccess ou Nginx

A causa tecnicamente mais comum são regras de reescrita conflituantes ou circulares na camada de configuração do servidor.

Exemplo de loop quebrado no .htaccess do Apache:

RewriteEngine On
RewriteRule ^page$ /page [R=301,L]

Esta regra redireciona /page para /page — um loop auto-referencial. Da mesma forma, duas regras que redirecionam entre /old-url e /new-url em direções opostas causarão a mesma falha.

Como diagnosticar:

Abra o seu ficheiro .htaccess e rastreie manualmente cada diretiva RewriteRule e Redirect. Procure qualquer regra onde o padrão de destino possa corresponder à origem de outra regra.

grep -n "Redirect|RewriteRule|RewriteCond" /var/www/html/.htaccess

Para o Nginx, o problema equivalente aparece em blocos server ou location:

# Broken example — loop between two location blocks
location /old {
    return 301 /new;
}
location /new {
    return 301 /old;
}

Audite a sua configuração Nginx com:

nginx -T | grep -A3 "return 301|rewrite"

Correção: Certifique-se de que cada regra de redirecionamento tem uma origem e destino únicos e não sobrepostos. Use o sinalizador [L] no Apache para parar o processamento de regras assim que uma correspondência for encontrada. No Nginx, prefira return 301 em vez de rewrite para maior clareza e para evitar encadeamento não intencional.

2. Configuração Incorreta do Redirecionamento HTTP para HTTPS

Esta é a causa mais comum em ambientes de hospedagem modernos, particularmente após adicionar um Certificado SSL sem atualizar a configuração ao nível da aplicação.

O padrão de falha é o seguinte:

• O servidor web força todo o tráfego HTTP para HTTPS via .htaccess ou configuração Nginx
• A aplicação (por exemplo, WordPress) tem a sua opção siteurl ou home definida como http:// na base de dados
• A aplicação redireciona então os pedidos HTTPS de volta para HTTP
• O loop é: HTTP → HTTPS (server) → HTTP (app) → HTTPS (server) → ...

Redirecionamento HTTPS correto no .htaccess do Apache:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Redirecionamento HTTPS correto no Nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Armadilha crítica: Se estiver atrás de um balanceador de carga ou proxy reverso (incluindo Cloudflare), o servidor backend pode não ver HTTPS diretamente. O proxy termina o SSL e encaminha o pedido como HTTP para a sua origem. O seu servidor vê então %{HTTPS} = off e redireciona para HTTPS novamente — criando um loop.

A correção é verificar o cabeçalho X-Forwarded-Proto em vez disso:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3. Incompatibilidade do Modo SSL entre Cloudflare e CDN

Se estiver a usar Cloudflare ou outro CDN à frente do seu servidor de origem, o modo de encriptação SSL/TLS deve corresponder ao estado real do certificado da sua origem.

O cenário de loop Cloudflare mais comum: O modo SSL está definido como Flexible, e o servidor de origem tem uma regra .htaccess a forçar HTTP para HTTPS. O Cloudflare envia HTTP para a origem, a origem redireciona para HTTPS, o Cloudflare recebe esse redirecionamento, envia HTTP novamente — loop infinito.

Correção: Defina o modo SSL do Cloudflare como Full (Strict) e certifique-se de que a sua origem tem um certificado válido. Alternativamente, se tiver de usar Flexible, remova o redirecionamento HTTP→HTTPS do seu servidor de origem completamente e deixe o Cloudflare tratá-lo via uma Page Rule ou o botão "Always Use HTTPS".

Desative também as Automatic HTTPS Rewrites no Cloudflare se a sua origem já estiver a tratar os redirecionamentos — ter ambos ativos duplica a lógica de redirecionamento.

4. Incompatibilidade nas Definições de URL do WordPress

O WordPress armazena os seus URLs canónicos em dois campos da base de dados: siteurl (o URL de instalação do núcleo do WordPress) e home (o URL público). Quando estes valores entram em conflito com as regras de redirecionamento do servidor ou entre si, um loop é quase inevitável.

Verificar os valores atuais via WP-CLI:

wp option get siteurl
wp option get home

Ou consultar a base de dados diretamente:

mysql -u dbuser -p dbname -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"

Ambos os valores devem usar o mesmo protocolo (https://) e o mesmo formato de domínio (com ou sem www) que a configuração do seu servidor impõe.

Correção via WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Correção via wp-config.php (substitui os valores da base de dados, útil quando sem acesso ao painel de administração):

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

Conflitos de plugins: Plugins de gestão de redirecionamentos (Redirection, Simple 301 Redirects, módulo de redirecionamento do Yoast SEO) podem criar regras de redirecionamento armazenadas na base de dados que entram em conflito com regras ao nível do servidor. Renomeie temporariamente o diretório de plugins para isolar o problema:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Reative os plugins um de cada vez após confirmar que o loop desapareceu.

5. Cache do Navegador e Redirecionamentos 301 em Cache

Os navegadores fazem cache de respostas 301 Moved Permanently de forma agressiva — por design. Se um redirecionamento 301 foi anteriormente servido para um URL e depois o destino do redirecionamento foi alterado, o navegador pode ainda seguir o antigo redirecionamento em cache, que pode apontar para um destino agora em loop.

Este é um cenário particularmente enganoso porque o loop pode não se reproduzir num navegador novo ou noutro dispositivo, levando os administradores a concluir incorretamente que o servidor está bem.

Passos de diagnóstico:

1. Abra o URL numa janela anónima/privada (sem dados em cache)
2. Teste com curl para contornar completamente o cache do navegador:

curl -I -L --max-redirs 10 https://example.com

1. Use um rastreador de cadeia de redirecionamentos online (por exemplo, redirect-checker.org ou httpstatus.io) para ver cada salto do lado do servidor

Correção: Limpe o cache e os cookies do navegador para o domínio afetado. No Chrome: Definições > Privacidade e Segurança > Limpar Dados de Navegação > selecione Imagens e Ficheiros em Cache + Cookies.

Para cache do lado do servidor (Varnish, Redis, OPcache ou um plugin de cache como W3 Total Cache):

# Flush Varnish cache
varnishadm ban req.url ~ .

# Flush OPcache via PHP CLI
php -r "opcache_reset();"

6. Conflitos de Redirecionamento www vs. Não-www

Uma fonte frequentemente ignorada de loops de redirecionamento é o tratamento inconsistente do subdomínio www. Se o seu servidor redireciona www.example.com para example.com e simultaneamente redireciona example.com para www.example.com, tem um loop.

Verifique a sua configuração atual de DNS e redirecionamento:

curl -sI http://www.example.com | grep -i location
curl -sI http://example.com | grep -i location

Configuração correta do Apache (não-www canónico):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Certifique-se de que esta regra não está emparelhada com outra regra que redireciona a versão não-www de volta para www.

7. Cookies Corrompidos ou em Conflito

Algumas aplicações usam cookies para gerir o estado de redirecionamento (por exemplo, redirecionamentos de login, deteção de localidade, frameworks de testes A/B). Se um cookie armazena um destino de redirecionamento que por si mesmo desencadeia outro redirecionamento, o loop é conduzido pela lógica da aplicação em vez da configuração do servidor.

Diagnóstico: Teste o URL com todos os cookies limpos para esse domínio. No Chrome DevTools (F12), vá a Application > Storage > Cookies, selecione o domínio e elimine todas as entradas. Recarregue a página.

Se o erro desaparecer após limpar os cookies, o problema está na sessão da sua aplicação ou na lógica de redirecionamento, não na configuração do servidor.

Comparação: Cenários Comuns de Loop de Redirecionamento e as Suas Correções

Fluxo de Trabalho de Diagnóstico Sistemático

Antes de tocar em qualquer ficheiro de configuração, siga esta sequência para isolar a causa:

Passo 1 — Reproduzir sem cache:

curl -v -L --max-redirs 25 https://example.com 2>&1 | grep -E "Location:|< HTTP"

Isto mostra cada salto de redirecionamento e o código de resposta final. Se vir os mesmos URLs a repetir-se, confirmou o loop e identificou quais os URLs envolvidos.

Passo 2 — Verificar os logs de erros do servidor:

# Apache
tail -100 /var/log/apache2/error.log | grep -i redirect

# Nginx
tail -100 /var/log/nginx/error.log | grep -i rewrite

Passo 3 — Isolar a camada:

• Se o loop desaparecer quando comentar as regras .htaccess, o problema está na configuração do Apache
• Se desaparecer quando contornar o Cloudflare (testar via IP direto), o problema está nas definições do CDN
• Se desaparecer quando renomear o diretório de plugins, o problema está num plugin do WordPress
• Se desaparecer em modo anónimo mas não no modo normal, o problema é cache do navegador ou cookies

Passo 4 — Validar a vinculação do certificado SSL:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "subject|issuer|Verify"

Um certificado inválido ou incompatível pode causar falhas de redirecionamento HTTPS que se manifestam como loops.

Prevenção de Loops de Redirecionamento em Produção

Uma vez resolvidos, estas práticas previnem a recorrência:

• Use uma única regra de redirecionamento canónica que trate tanto HTTP→HTTPS como www→não-www numa única passagem, não duas regras separadas que possam interagir
• Teste as cadeias de redirecionamento antes de implementar usando curl -L ou um verificador de redirecionamentos online após qualquer alteração de configuração
• Defina redirecionamentos 301 apenas quando permanentes — use 302 durante os testes para que os navegadores não façam cache do redirecionamento
• Documente cada regra de redirecionamento no seu .htaccess ou configuração Nginx com comentários inline explicando a intenção
• Monitorize com ferramentas de uptime que seguem cadeias de redirecionamento e alertam quando a contagem de saltos excede um limite

Para equipas que gerem múltiplos sites num VPS com cPanel, o módulo de Redirecionamentos do cPanel fornece uma interface visual para gerir regras de redirecionamento, mas escreve para .htaccess — verifique sempre o resultado manualmente após usar a GUI.

Se estiver a executar um site de alto tráfego ou múltiplos domínios, um Servidor Dedicado dá-lhe controlo total sobre a configuração Nginx ou Apache ao nível do sistema, eliminando restrições de ambientes partilhados que podem complicar a depuração de redirecionamentos.

Para sites que usam Painéis de Controlo VPS como Plesk ou DirectAdmin, as regras de redirecionamento podem ser geridas através da interface do painel, bem como diretamente nos ficheiros de configuração — verifique ambos os locais para garantir que não se contradizem.

Lista de Verificação Técnica de Pontos-Chave

Use isto como lista de verificação pré-voo ao diagnosticar ERR_TOO_MANY_REDIRECTS:

• [ ] Execute curl -v -L --max-redirs 25 para mapear a cadeia completa de redirecionamentos antes de tocar em qualquer configuração
• [ ] Confirme que tanto siteurl como home no WordPress correspondem ao protocolo e domínio que o seu servidor impõe
• [ ] Verifique se o modo SSL do Cloudflare é Full (Strict) se a sua origem tem um certificado válido
• [ ] Verifique se o .htaccess ou a configuração Nginx usa X-Forwarded-Proto em vez de %{HTTPS} quando atrás de um proxy
• [ ] Certifique-se de que os redirecionamentos www e não-www são unidirecionais — apenas uma forma canónica
• [ ] Desative temporariamente todos os plugins relacionados com redirecionamentos e reative um de cada vez
• [ ] Limpe o cache do navegador e teste em modo anónimo para descartar respostas 301 em cache
• [ ] Inspecione os cookies da aplicação para estado de redirecionamento que possa estar a conduzir um loop
• [ ] Valide que o certificado SSL é válido e está corretamente vinculado ao domínio
• [ ] Após corrigir, use 302 temporariamente antes de mudar para 301 para evitar re-cache de um redirecionamento quebrado

FAQ

Qual é a diferença entre ERR_TOO_MANY_REDIRECTS e um código de estado HTTP 310?

ERR_TOO_MANY_REDIRECTS é um erro do lado do cliente do navegador acionado após o navegador exceder o seu limite de seguimento de redirecionamentos (tipicamente 20). HTTP 310 é um código de estado raramente usado que significa "Too Many Redirects" ao nível do protocolo. Na prática, quase todos os erros de loop de redirecionamento que encontra em produção são o ERR_TOO_MANY_REDIRECTS do lado do navegador — não uma resposta 310 emitida pelo servidor.

Por que é que o loop de redirecionamento aparece apenas em alguns navegadores ou dispositivos mas não noutros?

A razão mais comum é um redirecionamento 301 em cache armazenado no navegador que aponta para um destino agora inválido. Como as respostas 301 são armazenadas em cache indefinidamente por padrão, um navegador que visitou anteriormente o URL pode seguir uma cadeia de redirecionamentos desatualizada. Testar em modo anónimo ou num dispositivo novo contorna este cache e revela o comportamento atual do servidor.

Como corrijo um loop de redirecionamento no WordPress quando não consigo aceder ao painel de administração?

Adicione as seguintes linhas diretamente ao wp-config.php para substituir os valores de URL da base de dados, depois aceda ao painel de administração para corrigir as definições corretamente:

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

Alternativamente, atualize os valores diretamente na base de dados usando wp-cli ou uma consulta MySQL direta contra a tabela wp_options.

Um loop de redirecionamento pode afetar as classificações SEO?

Sim. Um loop de redirecionamento não retorna nenhuma resposta 200 OK, o que significa que o Googlebot não consegue rastrear ou indexar o URL afetado. Se o loop afetar a sua página inicial ou páginas de destino principais, resultará em desindexação ao longo do tempo. Além disso, qualquer equidade de links 301 que passe pelo URL em loop é efetivamente perdida. Resolver o loop prontamente e verificar a rastreabilidade no Google Search Console é essencial.

Como evito que o Cloudflare cause loops de redirecionamento com a minha configuração SSL?

Defina o modo de encriptação SSL/TLS do Cloudflare como Full (Strict) no painel SSL/TLS. Isto garante que o Cloudflare comunica com a sua origem via HTTPS usando um certificado validado, eliminando o loop HTTP↔HTTPS que o modo Flexible cria quando o servidor de origem também impõe HTTPS. Além disso, desative "Automatic HTTPS Rewrites" se a sua origem ou .htaccess já trata o redirecionamento de HTTP para HTTPS, para evitar lógica de duplo redirecionamento.