Redirecionamentos HTTP: detectar loops, cadeias e links suspeitos

Por CaptainDNS
Publicado em 20 de março de 2026

Diagrama mostrando um loop de redirecionamento HTTP com detecção e resolução

TL;DR

Os loops de redirecionamento (ERR_TOO_MANY_REDIRECTS) são causados por configurações circulares entre servidores, CDN ou CMS.
As cadeias de redirecionamento excessivas (mais de 3 saltos) diluem o SEO e adicionam de 100 a 500 ms de latência por salto.
Os links encurtados (bit.ly, t.co) ocultam o destino real e podem levar a sites de phishing.
O Redirect Checker do CaptainDNS detecta automaticamente esses três problemas em uma única análise.
O Google segue no máximo 10 redirecionamentos. Além disso, a página não é indexada.

Você clica em um link e seu navegador exibe ERR_TOO_MANY_REDIRECTS. Ou a página acaba carregando, mas após um atraso suspeito de vários segundos. Ou ainda, um colega envia um link encurtado do bit.ly e você hesita antes de clicar. Essas três situações têm algo em comum: envolvem redirecionamentos HTTP que ninguém vê, mas que podem esconder problemas graves.

Os redirecionamentos são um mecanismo fundamental da web. Permitem mover páginas, forçar HTTPS, gerenciar vanity URLs. Mas quando estão mal configurados, criam três categorias de problemas distintos. Os loops impedem completamente o acesso à página. As cadeias excessivas degradam o SEO e o desempenho sem que o visitante perceba. Os links encurtados ocultam o destino real e servem como vetor de phishing em 1 caso a cada 10 segundo as pesquisas da Palo Alto Networks sobre domínios registrados recentemente (NRD).

Este guia cobre o diagnóstico e a correção desses três problemas. Cada seção explica o mecanismo técnico, os sintomas observáveis e os passos concretos para resolver a situação. O objetivo é tornar você autônomo para identificar e corrigir qualquer problema de redirecionamento, seja você administrador de sistemas, desenvolvedor ou responsável por SEO.

Analise suas URLs agora

Testar com o Redirect Checker Verificar um link suspeito

O que é um loop de redirecionamento?

Um loop de redirecionamento ocorre quando uma URL A redireciona para uma URL B, que por sua vez redireciona para a URL A. O navegador segue os redirecionamentos em círculo, sem nunca alcançar uma página de conteúdo. Após um certo número de tentativas, desiste e exibe uma mensagem de erro.

O caso mais simples é o ciclo de dois elementos: A redireciona para B, B redireciona para A. Mas os loops podem envolver três, quatro ou cinco URLs intermediárias antes de retornar ao ponto de partida.

Como o navegador reage a um loop?

Cada navegador impõe um limite ao número de redirecionamentos que segue antes de desistir. Quando esse limite é atingido, o navegador exibe uma mensagem de erro específica.

Navegador	Limite de redirecionamentos	Mensagem de erro
Chrome	20	`ERR_TOO_MANY_REDIRECTS`
Firefox	20	"A página não está sendo redirecionada corretamente"
Safari	16	"O Safari não consegue abrir a página"
Edge	20	`ERR_TOO_MANY_REDIRECTS`

O navegador não distingue entre um loop (ciclo) e uma cadeia muito longa (sequência linear). Em ambos os casos, se o limite for atingido, a exibição é bloqueada. A diferença é que uma cadeia longa acabará chegando ao destino se o limite for aumentado, enquanto um loop nunca terminará.

Do ponto de vista do Googlebot, um loop é fatal para a indexação. O Google detecta o ciclo, marca a página como inacessível e os backlinks que apontam para ela perdem todo o valor SEO.

Anatomia de um loop: o ciclo HTTP em detalhes

Aqui está o detalhe de um loop de três elementos no nível de rede.

1. GET https://captaindns.com/page-a
   → 301, Location: https://captaindns.com/page-b

2. GET https://captaindns.com/page-b
   → 302, Location: https://captaindns.com/page-c

3. GET https://captaindns.com/page-c
   → 301, Location: https://captaindns.com/page-a

4. GET https://captaindns.com/page-a   (volta ao ponto de partida)
   → 301, Location: https://captaindns.com/page-b

... (o ciclo se repete)

Cada iteração consome uma requisição de rede. Chrome e Firefox cortam após 20 requisições, ou seja, de 6 a 7 voltas completas em um loop de 3 elementos. O cabeçalho Location é o fio condutor: é seguindo-o que as ferramentas de diagnóstico reconstroem a cadeia e detectam o ponto de retorno.

Diagrama de um loop de redirecionamento de 3 elementos mostrando o ciclo A para B para C para A com o número de requisições antes do erro do navegador

As 7 causas mais frequentes de ERR_TOO_MANY_REDIRECTS

Os loops de redirecionamento quase nunca são intencionais. Resultam de conflitos entre vários componentes que tentam forçar um redirecionamento cada um por sua vez. Aqui estão as 7 causas mais comuns, classificadas por frequência de ocorrência.

1. Conflito HTTP/HTTPS entre CMS e servidor

Sintoma: o site exibe ERR_TOO_MANY_REDIRECTS desde a página inicial.

Mecanismo: o CMS (WordPress, Joomla) está configurado para forçar HTTPS em suas configurações internas. Ao mesmo tempo, o arquivo .htaccess ou a configuração do Nginx contém uma regra que redireciona HTTP para HTTPS. Quando o CMS redireciona para HTTPS e o servidor redireciona essa requisição para HTTP (ou vice-versa por causa de um proxy intermediário), cria-se um loop.

Diagnóstico: verifique a URL do site nas configurações do CMS (siteurl e home no WordPress). Compare com as regras de redirecionamento do servidor web. Se ambos forçam o protocolo em direções opostas, você encontrou a origem.

Correção: escolha um único ponto de controle para o redirecionamento HTTP para HTTPS. A boa prática é gerenciar esse redirecionamento no nível do servidor web (Nginx, Apache) ou do reverse proxy, e configurar o CMS para usar HTTPS em sua URL sem forçar o redirecionamento por conta própria.

2. Redirecionamento www/sem-www circular

Sintoma: ERR_TOO_MANY_REDIRECTS apenas na variante www ou sem-www do domínio.

Mecanismo: o DNS aponta www.captaindns.com para o servidor A e captaindns.com para o servidor B. O servidor A redireciona para a versão sem-www, o servidor B redireciona para a versão www. O navegador fica rebatendo indefinidamente entre os dois.

Diagnóstico: teste ambas as variantes separadamente com curl -I http://www.captaindns.com e curl -I http://captaindns.com. Se cada uma redireciona para a outra, o loop está confirmado.

Correção: alinhe a configuração de ambos os servidores em uma única versão canônica. Se você escolher captaindns.com como versão canônica, configure www.captaindns.com para redirecionar com 301 para captaindns.com, e certifique-se de que captaindns.com não redireciona para www.

3. Plugin de cache ou de segurança do WordPress

Sintoma: ERR_TOO_MANY_REDIRECTS após instalar ou atualizar um plugin.

Mecanismo: alguns plugins de segurança (Really Simple SSL, Wordfence) ou de cache (W3 Total Cache, WP Super Cache) adicionam suas próprias regras de redirecionamento no .htaccess ou via filtros PHP. Essas regras podem entrar em conflito com os redirecionamentos existentes do tema, do CMS ou do servidor.

Diagnóstico: desative os plugins um por um via FTP (renomeie a pasta do plugin em wp-content/plugins/). Quando o site voltar a ficar acessível, o último plugin desativado é o culpado.

Correção: reative o plugin e ajuste seus parâmetros para evitar o conflito. Se o plugin força HTTPS e seu servidor já faz isso, desative a funcionalidade no plugin. Se o plugin adiciona regras .htaccess, verifique se não estão duplicando as regras existentes.

4. Cloudflare Flexible SSL combinado com HTTPS forçado no servidor

Sintoma: ERR_TOO_MANY_REDIRECTS após a ativação do Cloudflare.

Mecanismo: o modo "Flexible SSL" do Cloudflare significa que a conexão entre o visitante e o Cloudflare é HTTPS, mas a conexão entre o Cloudflare e seu servidor é HTTP. Se seu servidor está configurado para redirecionar HTTP para HTTPS, ele redireciona a requisição do Cloudflare para HTTPS. O Cloudflare recebe esse redirecionamento, mas reenvia a requisição em HTTP (modo Flexible). O servidor redireciona novamente para HTTPS, e assim por diante.

Diagnóstico: verifique o modo SSL/TLS no dashboard do Cloudflare. Se for "Flexible" e seu servidor força HTTPS, você encontrou a causa.

Correção: mude o modo SSL/TLS do Cloudflare para "Full" ou "Full (Strict)". Com o modo Full, o Cloudflare se comunica em HTTPS com seu servidor, eliminando o conflito. Certifique-se de que seu servidor tenha um certificado TLS válido (Let's Encrypt é suficiente).

5. Cookies corrompidos ou loop de autenticação

Sintoma: ERR_TOO_MANY_REDIRECTS apenas para certos usuários, ou apenas no modo conectado.

Mecanismo: a aplicação redireciona os usuários não conectados para a página de login. A página de login verifica um cookie de sessão, detecta que o usuário não está conectado (cookie corrompido, expirado ou mal formatado) e redireciona para a página de login novamente. Ou, após o login, a aplicação redireciona para uma página protegida que não reconhece o cookie e reenvia para o login.

Diagnóstico: teste o site em navegação privada (sem cookies). Se o problema desaparece, os cookies são a causa. Peça ao usuário afetado para limpar os cookies do domínio.

Correção: se o problema é generalizado, verifique a configuração dos cookies de sessão (domínio, caminho, atributo Secure, atributo SameSite). Um cookie com Secure=true não será enviado em uma conexão HTTP. Um cookie com um domínio incorreto (.www.captaindns.com em vez de .captaindns.com) não será lido na variante sem www.

6. Arquivo .htaccess com regras conflitantes

Sintoma: ERR_TOO_MANY_REDIRECTS em um servidor Apache, geralmente após uma modificação manual do .htaccess.

Mecanismo: o arquivo .htaccess contém vários blocos RewriteRule que se contradizem. Por exemplo, uma regra redireciona /page para /page/, e outra redireciona /page/ para /page. Ou uma regra genérica (catch-all) captura URLs que deveriam ser excluídas por uma regra anterior, mas a ordem das regras está incorreta.

Diagnóstico: examine o arquivo .htaccess na raiz do site e em todos os subdiretórios. Procure os blocos RewriteRule que apontam para padrões similares.

Correção: simplifique o .htaccess. Agrupe todos os redirecionamentos em um único bloco, ordene do mais específico ao mais genérico e adicione o flag [L] (last) às regras terminais.

Exemplo de .htaccess limpo que gerencia HTTP para HTTPS e www para sem-www sem conflito:

RewriteEngine On
# Forçar HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
# Forçar sem-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

A ordem importa: primeiro forçar HTTPS, depois gerenciar o www. O flag [L] garante que cada regra é terminal: uma vez acionada, o Apache não continua com as regras seguintes.

7. CDN ou reverse proxy mal configurado

Sintoma: ERR_TOO_MANY_REDIRECTS após implementar um CDN (Cloudflare, Fastly, AWS CloudFront) ou um reverse proxy (Nginx, HAProxy).

Mecanismo: o CDN ou o reverse proxy modifica os cabeçalhos da requisição (protocolo, host, caminho) antes de transmiti-la ao servidor de origem. O servidor de origem toma uma decisão de redirecionamento baseada nesses cabeçalhos modificados e retorna uma resposta que desencadeia um novo redirecionamento no nível do CDN. O ciclo se repete.

O caso clássico: o CDN encerra a conexão TLS e transmite a requisição em HTTP ao servidor de origem. O servidor vê HTTP e redireciona para HTTPS. O CDN intercepta esse redirecionamento, mas envia novamente em HTTP.

Diagnóstico: teste o site contornando o CDN (acesse diretamente o IP do servidor). Se o site funciona sem CDN mas não com ele, o problema está na configuração do proxy.

Correção: configure o servidor de origem para reconhecer os cabeçalhos de proxy (X-Forwarded-Proto). No Nginx, use $http_x_forwarded_proto no lugar de $scheme. No Apache, verifique %{HTTP:X-Forwarded-Proto} nos RewriteCond.

Exemplo Nginx com suporte a proxy:

server {
    listen 80;
    server_name captaindns.com;

    # Redireciona para HTTPS apenas se a requisição não chega já via HTTPS pelo CDN
    if ($http_x_forwarded_proto != "https") {
        return 301 https://$server_name$request_uri;
    }
}

Como diagnosticar um loop de redirecionamento?

Uma vez que você sabe que um loop existe (o navegador exibe o erro), é preciso localizá-lo com precisão. Três métodos complementares permitem reconstruir a cadeia de redirecionamentos e identificar o ponto de retorno.

Método 1: o Redirect Checker do CaptainDNS

O método mais rápido. Insira a URL no Redirect Checker e inicie a análise. A ferramenta segue cada redirecionamento, registra o código HTTP, a URL de destino, os cabeçalhos de resposta e o tempo de resposta de cada salto. Quando detecta que uma URL aparece duas vezes na cadeia, sinaliza o loop e indica exatamente em qual salto ele começa.

A vantagem: a ferramenta segue até 30 saltos (contra 20 dos navegadores), o que permite detectar loops longos. Também exibe os cabeçalhos HTTP completos, essenciais para diagnosticar conflitos de protocolo e problemas de X-Forwarded-Proto.

Método 2: curl na linha de comando

Para os administradores que preferem o terminal, curl com a opção -v (verbose) e -L (follow redirects) mostra cada etapa da cadeia:

curl -v -L --max-redirs 25 https://captaindns.com/page-a 2>&1 | grep -E "^(< HTTP|< Location|> GET)"

Esse comando mostra o código HTTP e o cabeçalho Location de cada resposta, assim como a requisição GET enviada em cada etapa. Quando a URL da requisição GET corresponde a uma URL já vista acima na saída, você encontrou o loop.

A opção --max-redirs 25 aumenta o limite padrão do curl (50) para um nível suficiente para detectar a maioria dos loops sem gerar uma saída muito longa.

Para uma saída mais concisa, limite-se aos cabeçalhos:

curl -sI -L --max-redirs 25 https://captaindns.com/page-a 2>&1 | grep -iE "^(HTTP/|Location:)"

Método 3: os DevTools do navegador

Abra as ferramentas de desenvolvedor (F12), vá para a aba "Network" (Rede) e carregue a URL problemática. O navegador mostra cada requisição HTTP em ordem cronológica. Você verá uma série de requisições com códigos 301 ou 302, cada uma com uma URL diferente, até que o navegador atinja seu limite e exiba o erro.

A vantagem dos DevTools: mostram os cookies enviados e recebidos em cada requisição, indispensável para diagnosticar os loops de autenticação (causa 5). A limitação: o navegador mostra apenas as primeiras 20 requisições (16 no Safari).

Tabela comparativa dos três métodos

Critério	Redirect Checker	curl	DevTools
Facilidade de uso	Alta (interface web)	Média (terminal)	Média (navegador)
Número máximo de saltos	30	Configurável	16 a 20
Detecção automática de loop	Sim	Não (análise manual)	Não (análise manual)
Visualização de cookies	Não	Sim (com `-v`)	Sim
Visualização dos tempos de resposta	Sim (por salto)	Sim (com `-w`)	Sim
Requer instalação	Não	Sim (presente no Linux/macOS)	Não
Compartilhamento de resultados	Sim (URL do relatório)	Não	Não (captura de tela)

Para um diagnóstico rápido, comece pelo Redirect Checker. Complemente com os DevTools se o problema envolve cookies, ou com curl para automação em pipeline CI/CD.

As cadeias de redirecionamento: impacto SEO e desempenho

Uma cadeia de redirecionamento é uma sequência linear de redirecionamentos sucessivos. Diferente do loop, a cadeia chega a uma página de conteúdo, mas passa por uma ou várias URLs intermediárias antes de chegar. O problema não é a inacessibilidade (a página acaba carregando), mas a degradação progressiva do SEO e do desempenho.

Quantos saltos antes de se tornar um problema?

Um único salto de redirecionamento é perfeitamente normal. É o caso padrão de um link antigo que redireciona para a nova URL. O problema começa quando os saltos se acumulam.

Número de saltos	Avaliação	Impacto
1	Normal	Nenhum impacto mensurável
2	Aceitável	Impacto mínimo, nenhuma ação necessária
3	Aviso	Latência perceptível, possível diluição SEO
4 a 5	Problema	De 400 a 2500 ms de latência adicionada, perda de SEO provável
6 ou mais	Crítico	O Google pode abandonar o rastreamento, página potencialmente não indexada

O Google segue oficialmente até 10 redirecionamentos em uma cadeia. No entanto, John Mueller da equipe Google Search esclareceu que a transferência de sinal SEO pode se degradar bem antes de atingir esse limite. A recomendação prática é nunca ultrapassar 2 saltos entre a URL de origem e o destino final.

Impacto SEO: diluição do PageRank e perda de indexação

Cada redirecionamento intermediário em uma cadeia cria uma oportunidade de perda de sinal SEO. Embora o Google afirme que um redirecionamento 301 único transfere 100% do PageRank, o comportamento com cadeias múltiplas é menos documentado e menos confiável.

O problema concreto: quando o Googlebot encontra uma cadeia de 5 redirecionamentos, realiza 6 requisições HTTP. Cada uma consome crawl budget. Para sites volumosos com milhares de cadeias, o Google gasta tempo seguindo redirecionamentos em vez de rastrear conteúdo novo.

Além disso, se um redirecionamento intermediário é uma 302 em vez de uma 301, a transferência de PageRank é interrompida nesse ponto. Uma única 302 em uma cadeia de 301 basta para bloquear a transferência de autoridade.

Impacto no desempenho: a latência se soma

Cada salto de redirecionamento adiciona uma ida e volta completa entre o navegador e o servidor. Na prática, isso representa de 100 a 500 ms por salto, dependendo da latência de rede e da localização geográfica do visitante.

Para um visitante na Europa acessando um servidor na América do Norte, cada salto adiciona de 150 a 200 ms. Uma cadeia de 4 saltos adiciona de 600 a 800 ms antes que o conteúdo comece a carregar.

Esse impacto se concentra no LCP (Largest Contentful Paint), a métrica Core Web Vitals que mede o tempo de exibição do conteúdo principal. Um LCP superior a 2,5 segundos é classificado como "ruim" pelo Google. Se sua página carrega normalmente em 1,8 segundos mas uma cadeia de 3 redirecionamentos adiciona 600 ms, você entra na zona vermelha.

Boa notícia: os redirecionamentos 301 armazenados em cache pelo navegador não têm mais impacto após a primeira visita. É mais um argumento para preferir as 301 às 302 nas cadeias.

Como as cadeias se formam: o caso da migração em várias etapas

As cadeias de redirecionamento raramente são criadas intencionalmente. Acumulam-se ao longo do tempo, a cada migração, redesign ou mudança de estrutura.

Cenário típico:

2022: o site está em http://captaindns.com. Migração para HTTPS. Redirecionamento 301 de http:// para https://.
2023: redesign do site. Mudança de estrutura de URL. Redirecionamento 301 de /tools/dns-check para /pt/tools/dns/test-propagation.
2025: consolidação do subdomínio. Redirecionamento 301 de https://outils.captaindns.com/dns-check para https://captaindns.com/tools/dns-check.

Um backlink publicado em 2022 que aponta para http://outils.captaindns.com/dns-check agora atravessa 3 redirecionamentos:

http://outils.captaindns.com/dns-check
→ 301 → https://outils.captaindns.com/dns-check
→ 301 → https://captaindns.com/tools/dns-check
→ 301 → https://captaindns.com/pt/tools/dns/test-propagation

Cada migração individual foi correta. Mas o acúmulo cria uma cadeia de 3 saltos que consome crawl budget e adiciona latência.

A solução: após cada migração, atualize os redirecionamentos antigos para apontar diretamente ao destino final. Nesse exemplo, o primeiro redirecionamento deveria ser atualizado para https://captaindns.com/pt/tools/dns/test-propagation, eliminando os dois intermediários.

Diagrama mostrando uma cadeia de 4 redirecionamentos com a latência acumulada e a correção para um único salto direto

Como detectar as cadeias no seu site?

O método mais eficaz é testar suas URLs críticas (páginas com maior tráfego, páginas com mais backlinks) com o Redirect Checker. A ferramenta indica o número de saltos para cada URL e sinaliza as cadeias de mais de 2 saltos.

Para uma auditoria em grande escala, exporte a lista de suas URLs do Google Search Console (relatório "Páginas") e teste-as em lotes. Priorize as URLs com mais tráfego orgânico e mais backlinks.

Você também pode usar o Page Crawl Checker para analisar as cadeias de redirecionamento no contexto de um rastreamento completo de página, incluindo os recursos carregados (CSS, JavaScript, imagens) que também podem atravessar cadeias.

Links encurtados: para onde eles levam de verdade?

Os serviços de encurtamento de URL (bit.ly, t.co, tinyurl.com, ow.ly, goo.gl) substituem uma URL longa por uma URL curta que redireciona para o destino. Essa operação é transparente para o usuário legítimo: ele clica, o serviço redireciona, a página carrega. Mas essa transparência é também um importante vetor de ataque.

O problema de segurança dos links encurtados

Um link encurtado oculta completamente o destino. O usuário não consegue saber, antes de clicar, se o link leva a um documento legítimo do Google ou a um site de phishing que imita a página de login do seu banco.

Os atacantes exploram essa opacidade de forma sistemática. Um e-mail de phishing contendo https://bit.ly/3xYz123 é muito mais difícil de detectar do que um e-mail com uma URL suspeita em texto simples. Os filtros anti-phishing têm dificuldade em analisar os links encurtados, pois o domínio visível (bit.ly) é legítimo. É o destino final que é malicioso.

Segundo as pesquisas da Palo Alto Networks (Unit 42), mais de 70% dos domínios maliciosos foram registrados há menos de 32 dias (Newly Registered Domains). Os links encurtados são o principal vetor para distribuir esses domínios recentes.

Técnicas avançadas de ofuscação

Os atacantes não se limitam a encurtar um link malicioso. Combinam várias técnicas para tornar a detecção ainda mais difícil.

Cadeia de encurtadores: um link bit.ly redireciona para tinyurl, que redireciona para ow.ly, que leva ao site de phishing. Cada camada adiciona uma barreira para as ferramentas de detecção. O Redirect Checker segue a cadeia completa e revela o destino final.

Redirecionamentos condicionais: o serviço redireciona para um site diferente dependendo do país, do navegador ou do momento do dia. Os visitantes-alvo veem a página de phishing, os demais são redirecionados para um site legítimo.

Domínios expirados reutilizados: o atacante compra um domínio que tinha boa reputação, instala conteúdo malicioso e depois distribui links encurtados para esse domínio. A reputação histórica engana os filtros de segurança.

Como o Redirect Checker desmascara os links encurtados

Quando você insere um link encurtado no Redirect Checker, a ferramenta segue cada redirecionamento até o destino final, registrando o código HTTP, a URL de destino, os cabeçalhos e o tempo de resposta de cada salto. Sinaliza automaticamente vários indicadores de risco:

Domínios registrados recentemente (NRD): se o destino final é um domínio registrado há menos de 30 dias, a ferramenta emite um aviso. Os domínios NRD são estatisticamente muito mais propensos a serem maliciosos do que os domínios estabelecidos.

Número excessivo de redirecionamentos: um link legítimo encurtado geralmente envolve 1 ou 2 redirecionamentos (do encurtador ao destino). Se a cadeia contém 4 redirecionamentos ou mais, é um sinal de alerta.

Mudança de protocolo suspeita: se um redirecionamento na cadeia passa de HTTPS para HTTP, é um indicador de risco. Os sites legítimos usam HTTPS. Um retorno ao HTTP no meio da cadeia pode indicar uma tentativa de downgrade para interceptar o tráfego.

Homógrafos IDN: quando o domínio parece ser outro

Os ataques por homógrafo IDN (Internationalized Domain Name) exploram caracteres Unicode que se parecem visualmente com letras latinas. Por exemplo, o caractere cirílico "a" (U+0430) é visualmente idêntico ao "a" latino (U+0061), mas trata-se de um caractere diferente.

Um atacante pode registrar cаptaindns.com (com um "a" cirílico) que parece exatamente igual a captaindns.com na barra de endereços. Por trás de um link encurtado, essa diferença é totalmente invisível.

O Redirect Checker exibe a URL de destino em ASCII Punycode quando contém caracteres IDN. A URL cаptaindns.com aparece então na sua forma técnica xn--cptaindns-r6a.com, revelando imediatamente que não é o domínio esperado.

Para proteger sua marca, verifique regularmente se as variantes homógrafas do seu domínio não estão registradas por terceiros. O Phishing URL Checker analisa especificamente os riscos de homografia e typosquatting nas URLs que você enviar.

Como corrigir os problemas de redirecionamento?

O diagnóstico está feito, o problema está identificado. Aqui estão os passos de correção para cada tipo de problema.

Corrigir um loop de redirecionamento

Passo 1: identificar o ponto de entrada e o ponto de retorno. Use o Redirect Checker para reconstruir a cadeia completa. Anote em qual salto a URL reaparece.

Passo 2: identificar o componente responsável pelo retorno. É o servidor, o CDN, o CMS ou o plugin que gera o redirecionamento para a URL já vista. Consulte a seção "As 7 causas" acima para identificar o padrão.

Passo 3: quebrar o ciclo. Modifique a configuração do componente responsável para que ele não gere mais o redirecionamento circular. Na maioria dos casos, isso significa eliminar ou modificar uma regra de redirecionamento em um dos componentes envolvidos.

Passo 4: testar imediatamente. Após a correção, limpe o cache do navegador (os 301 podem estar em cache) e teste com o Redirect Checker. Verifique se a cadeia termina com um código 200 e não com um ciclo.

Exemplo concreto: loop entre Cloudflare (Flexible SSL) e um servidor Apache que força HTTPS.

Antes da correção:
https://captaindns.com → Cloudflare (HTTP para servidor) → Apache (redireciona para HTTPS)
→ Cloudflare (HTTP para servidor) → Apache (redireciona para HTTPS) → loop

Correção: mudar Cloudflare para o modo "Full (Strict)"

Depois da correção:
https://captaindns.com → Cloudflare (HTTPS para servidor) → Apache (sem redirecionamento, código 200)

Corrigir uma cadeia de redirecionamento

Princípio: encurtar a cadeia para um único salto. Cada URL de origem deve apontar diretamente para o destino final, sem intermediários.

Passo 1: listar todos os redirecionamentos da cadeia. Use o Redirect Checker para obter a sequência completa.

Passo 2: identificar o destino final. É a última URL da cadeia, a que retorna um código 200.

Passo 3: atualizar cada redirecionamento intermediário. Modifique a configuração de cada servidor ou serviço envolvido para que as URLs intermediárias redirecionem diretamente para o destino final.

Exemplo:

Antes da correção:
http://captaindns.com/old-page
→ 301 → https://captaindns.com/old-page
→ 301 → https://captaindns.com/pt/old-page
→ 301 → https://captaindns.com/pt/tools/new-page

Depois da correção:
http://captaindns.com/old-page → 301 → https://captaindns.com/pt/tools/new-page
https://captaindns.com/old-page → 301 → https://captaindns.com/pt/tools/new-page
https://captaindns.com/pt/old-page → 301 → https://captaindns.com/pt/tools/new-page

Cada URL de origem agora aponta diretamente para o destino final em um único salto. O navegador e o Googlebot têm apenas um redirecionamento a seguir.

Verificação pós-correção

Após cada correção, teste sistematicamente com o Redirect Checker:

Verifique se a cadeia termina com um código 200.
Verifique se o número de saltos é inferior ou igual a 2.
Verifique se todos os redirecionamentos intermediários usam o código 301 (exceto caso específico de redirecionamento temporário).
Verifique se o protocolo final é HTTPS.
Teste as 4 variantes da URL: http://, https://, http://www., https://www..

Se você corrigiu várias cadeias, espere de 48 a 72 horas e depois verifique no Google Search Console se os erros de redirecionamento desapareceram do relatório "Páginas".

Boas práticas para evitar problemas futuros

Usar um único ponto de controle para os redirecionamentos. Não configure o mesmo redirecionamento em dois lugares diferentes (servidor web e CDN, CMS e .htaccess). Escolha um único componente para gerenciar cada tipo de redirecionamento.

Sempre usar 301 para redirecionamentos permanentes. As 302 não transferem o PageRank e não são armazenadas em cache pelo navegador. Exceto em caso específico (redirecionamento condicional, teste A/B), a 301 é a opção padrão.

Atualizar os redirecionamentos antigos após cada migração. Não deixe as cadeias se acumularem. Após cada mudança de estrutura de URL, revise os redirecionamentos antigos e atualize-os para apontar diretamente ao destino final.

Documentar todos os redirecionamentos ativos. Mantenha uma tabela resumo de todas as regras de redirecionamento ativas, com a origem, o destino, o código HTTP e a data de criação. Essa tabela é indispensável para evitar conflitos em modificações futuras.

Testar antes de colocar em produção. Antes de colocar em produção uma nova regra de redirecionamento, teste-a em um ambiente de staging ou com curl -I. Verifique se o redirecionamento funciona e se não cria conflito com as regras existentes.

Plano de ação recomendado

Aqui está uma checklist em 5 passos para auditar e corrigir os problemas de redirecionamento no seu site.

Passo 1: escanear as URLs críticas

Identifique suas 20 a 50 URLs mais importantes: páginas iniciais, páginas de produto, artigos do blog com alto tráfego, páginas de conversão. Teste cada uma com o Redirect Checker.

Para cada URL, anote:

O número de saltos
A presença eventual de um loop
O código HTTP do destino final (deve ser 200)
O protocolo do destino final (deve ser HTTPS)

Passo 2: identificar loops e cadeias de mais de 3 saltos

Entre as URLs testadas, isole as que apresentam um problema:

Loop detectado: prioridade máxima, a página está inacessível
5 saltos ou mais: prioridade alta, impacto significativo no SEO e desempenho
3 a 4 saltos: prioridade média, a corrigir no próximo ciclo de manutenção
1 a 2 saltos: nenhuma ação necessária

Passo 3: corrigir as configurações do servidor

Para cada problema identificado, aplique a correção apropriada:

Loop: identifique o componente responsável (veja as 7 causas) e quebre o ciclo
Cadeia: atualize cada redirecionamento intermediário para apontar ao destino final
Conflito CDN/servidor: alinhe a configuração SSL/TLS entre o CDN e o servidor de origem
Conflito .htaccess: simplifique as regras, adicione os flags [L], ordene da mais específica à mais genérica

Passo 4: verificar os links encurtados nos seus e-mails e newsletters

Revise os links encurtados presentes nos seus templates de newsletter, nas suas assinaturas de e-mail e nas suas campanhas de marketing ativas. Para cada link encurtado:

Teste o destino com o Redirect Checker
Verifique se o destino é o seu site (e não um domínio de terceiros)
Substitua os links encurtados por links diretos quando possível
Se o link encurtado é necessário (tracking, QR code), verifique se a cadeia não ultrapassa 2 saltos

Passo 5: testar novamente após a correção

Após cada correção, volte às URLs corrigidas e verifique que:

O loop está resolvido (código 200 no final da cadeia)
A cadeia está encurtada (2 saltos no máximo)
As 4 variantes da URL (HTTP/HTTPS, www/sem-www) funcionam corretamente
Nenhum novo problema foi introduzido

Planeje uma auditoria de acompanhamento em 30 dias para verificar se as correções se mantêm e se nenhuma nova cadeia se formou.

Casos práticos: diagnósticos comuns e soluções

Caso 1: site WordPress inacessível após ativar Really Simple SSL

Sintoma: ERR_TOO_MANY_REDIRECTS imediatamente após a ativação do plugin.

Diagnóstico com o Redirect Checker:

Salto 1: https://captaindns.com → 301 → http://captaindns.com (plugin força HTTP?)
Salto 2: http://captaindns.com → 301 → https://captaindns.com (servidor força HTTPS)
Salto 3: https://captaindns.com → 301 → http://captaindns.com
→ Loop detectado no salto 3

Causa: o arquivo wp-config.php contém define('FORCE_SSL_ADMIN', false) ou a URL do site no banco de dados está em HTTP, o que entra em conflito com o plugin que tenta forçar HTTPS.

Solução: desative o plugin via FTP (renomeie sua pasta), atualize as opções siteurl e home em wp_options para usar HTTPS, adicione define('FORCE_SSL_ADMIN', true) em wp-config.php, e depois reative o plugin.

Caso 2: link encurtado em um e-mail que leva a um site de phishing

Sintoma: um funcionário recebe um e-mail com um link https://bit.ly/3Ab4Cd5 que supostamente leva a um documento compartilhado.

Diagnóstico com o Redirect Checker:

Salto 1: https://bit.ly/3Ab4Cd5 → 301 → https://tinyurl.com/y7x8z9
Salto 2: https://tinyurl.com/y7x8z9 → 301 → https://docs-google-verification.com/login
→ Destino final: https://docs-google-verification.com/login
→ ALERTA: domínio registrado há 3 dias (NRD)
→ ALERTA: o domínio imita "docs.google.com" (homografia potencial)

Indicadores de risco: dois encurtadores em cadeia (técnica de ofuscação), domínio de destino registrado há 3 dias (NRD), nome de domínio que imita um serviço legítimo (Google Docs), URL que contém "/login" (tentativa de roubo de credenciais).

Ação: não clicar. Reportar o e-mail como phishing. Alertar a equipe de segurança. Se o link foi clicado, alterar imediatamente a senha do serviço imitado e ativar a autenticação de dois fatores.

Redirecionamentos e segurança: os ataques baseados em redirecionamentos

Os redirecionamentos não são apenas um problema de configuração. Também são um vetor de ataque explorado ativamente por cibercriminosos.

Open redirect: quando seu próprio site se torna um vetor de ataque

Uma vulnerabilidade "open redirect" existe quando seu site aceita um parâmetro de URL que controla o destino de um redirecionamento sem validar esse parâmetro. Exemplo: https://captaindns.com/login?redirect=https://site-malicioso.com. Se sua aplicação redireciona cegamente para o valor do parâmetro redirect, um atacante pode usar seu domínio legítimo como primeiro passo de uma cadeia de phishing.

Proteção: valide sempre as URLs de redirecionamento no lado do servidor. Aceite apenas redirecionamentos para o seu próprio domínio ou para uma lista de domínios autorizados.

Ataque por cadeia de redirecionamentos

Um atacante pode explorar redirecionamentos legítimos para construir cadeias que burlam os filtros de segurança. A cadeia típica: um e-mail contém um link para um encurtador legítimo (bit.ly), o encurtador redireciona para um site de boa reputação que tem uma falha open redirect, o open redirect envia para o site de phishing. Cada etapa passa pelos filtros individualmente. É a combinação que é maliciosa. Apenas uma ferramenta que segue a cadeia completa até o destino final pode detectar o ataque.

Boas práticas de segurança para redirecionamentos

Nunca clicar em um link encurtado sem verificá-lo. Use o Redirect Checker para revelar o destino antes de clicar.
Auditar seu próprio site em busca de open redirects. Procure todos os endpoints que aceitam um parâmetro de URL como destino de redirecionamento.
Verificar os domínios NRD nos e-mails. Um domínio com menos de 30 dias em um link de e-mail é um forte sinal de alerta.
Conscientizar as equipes. Os links encurtados nos e-mails internos sempre deveriam ser acompanhados da URL completa de destino em texto simples.

FAQ

O que significa ERR_TOO_MANY_REDIRECTS?

Essa mensagem de erro significa que o navegador atingiu seu limite de redirecionamentos sucessivos (20 para Chrome e Firefox, 16 para Safari) sem chegar a uma página de conteúdo. A causa é um loop de redirecionamento (duas ou mais URLs que se redirecionam mutuamente) ou uma cadeia de redirecionamento excessivamente longa. Para identificar a causa exata, teste a URL com o Redirect Checker, que segue a cadeia completa e sinaliza automaticamente os loops.

Como corrigir um loop de redirecionamento no WordPress?

Os loops no WordPress geralmente são causados por um conflito entre um plugin (Really Simple SSL, Wordfence, W3 Total Cache) e a configuração do servidor. A correção em 4 passos: 1) desative os plugins um por um via FTP (renomeie a pasta em wp-content/plugins/) para identificar o culpado; 2) verifique se as URLs siteurl e home na tabela wp_options usam o protocolo correto (HTTPS); 3) limpe o arquivo .htaccess das regras de redirecionamento duplicadas; 4) reative o plugin e ajuste seus parâmetros para não duplicar os redirecionamentos do servidor.

Quantos redirecionamentos o Google pode seguir?

O Google segue oficialmente até 10 redirecionamentos em uma cadeia. Além disso, o Googlebot desiste e a página final não é rastreada nem indexada. Na prática, John Mueller recomenda nunca ultrapassar 2 saltos. Cada redirecionamento consome crawl budget e pode diluir o sinal SEO, especialmente se uma 302 se infiltra em uma cadeia de 301.

Os links encurtados são perigosos?

Os links encurtados não são intrinsecamente perigosos, mas ocultam o destino real, o que os torna um vetor privilegiado para phishing e distribuição de malware. Segundo as pesquisas da Palo Alto Networks, mais de 70% dos domínios maliciosos foram registrados há menos de 32 dias, e os links encurtados são o principal meio de distribuir esses domínios em e-mails. A boa prática é sempre verificar o destino de um link encurtado antes de clicar, usando uma ferramenta que siga a cadeia de redirecionamentos até o final.

Como saber para onde leva um link bit.ly?

Existem vários métodos. O mais confiável é usar o Redirect Checker do CaptainDNS: insira o link bit.ly e a ferramenta segue todos os redirecionamentos até o destino final, mostrando cada salto intermediário. Você também pode adicionar um "+" ao final da URL do bit.ly (por exemplo, https://bit.ly/3xYz123+) para acessar a página de estatísticas do bit.ly que mostra o destino, mas esse método não funciona com todos os encurtadores e não segue redirecionamentos múltiplos.

Qual é a diferença entre um loop e uma cadeia de redirecionamento?

Um loop é um ciclo: a URL A redireciona para B, que redireciona para C, que redireciona novamente para A. O navegador fica girando em círculos e nunca alcança uma página de conteúdo. O resultado é um erro ERR_TOO_MANY_REDIRECTS. Uma cadeia é uma sequência linear: A redireciona para B, que redireciona para C, que retorna um código 200 (página de conteúdo). A cadeia chega ao destino, mas cada salto intermediário adiciona latência e pode diluir o sinal SEO. Os loops são bloqueantes (a página está inacessível), as cadeias são degradantes (a página carrega, mas de forma pior).

O Redirect Checker funciona com links encurtados?

Sim. O Redirect Checker segue todos os redirecionamentos HTTP, independentemente do domínio de origem. Quando você insere um link bit.ly, tinyurl.com, t.co ou qualquer outro encurtador, a ferramenta segue a cadeia completa até o destino final. Mostra cada salto intermediário com o código HTTP, a URL de destino e o tempo de resposta. Também sinaliza os domínios registrados recentemente (NRD) e as cadeias anormalmente longas que podem indicar uma tentativa de ofuscação.

Como detectar um link de phishing oculto?

Vários indícios permitem detectar um link de phishing por trás de um encurtador. Verifique o destino com o Redirect Checker e procure estes sinais de alerta: 1) o domínio de destino foi registrado há menos de 30 dias (NRD); 2) a cadeia contém mais de 2 redirecionamentos (técnica de ofuscação); 3) o domínio imita um serviço conhecido (homógrafo IDN ou typosquatting); 4) a URL final contém palavras como "login", "verify", "secure" ou "update"; 5) o protocolo passa de HTTPS para HTTP no meio da cadeia. A presença de 2 ou mais desses indicadores sugere fortemente um link malicioso.

Os redirecionamentos meta refresh criam loops?

Sim, os redirecionamentos meta refresh podem criar loops exatamente como os redirecionamentos HTTP. A página A contém uma tag <meta http-equiv="refresh"> que redireciona para a página B, e a página B contém uma tag similar que redireciona para A. A diferença é que os meta refresh são mais lentos (o navegador precisa baixar e analisar o HTML antes de redirecionar) e mais difíceis de diagnosticar porque não são visíveis nos cabeçalhos HTTP. As ferramentas de linha de comando como curl não os detectam sem uma opção específica.

Como evitar que as cadeias de redirecionamento se acumulem ao longo do tempo?

A melhor prática é atualizar os redirecionamentos antigos após cada migração. Quando você adiciona uma nova camada de redirecionamento (mudança de domínio, mudança de estrutura de URL, migração para HTTPS), revise os redirecionamentos anteriores e atualize-os para apontar diretamente ao destino final. Documente todos os redirecionamentos ativos em uma tabela centralizada com a origem, o destino, o código HTTP e a data. Planeje uma auditoria trimestral das suas URLs principais com o Redirect Checker para detectar as cadeias antes que se tornem problemáticas.

Glossário

Loop de redirecionamento: ciclo em que duas ou mais URLs se redirecionam mutuamente. O navegador exibe ERR_TOO_MANY_REDIRECTS após 16 a 20 tentativas.
Cadeia de redirecionamento: sequência linear de redirecionamentos sucessivos. A cadeia chega ao destino, mas degrada o SEO e o desempenho.
ERR_TOO_MANY_REDIRECTS: mensagem de erro dos navegadores Chromium quando o limite de redirecionamentos é atingido. Equivalente a "A página não está sendo redirecionada corretamente" no Firefox.
NRD (Newly Registered Domain): domínio registrado há menos de 32 dias. Estatisticamente mais propenso a ser malicioso.
Homógrafo IDN: domínio internacionalizado que utiliza caracteres Unicode visualmente semelhantes a letras latinas para imitar um domínio legítimo.
Meta refresh: tag HTML <meta http-equiv="refresh"> que aciona um redirecionamento do lado do cliente. Desaconselhado pelo Google para o SEO.
Link encurtado: URL curta (bit.ly, t.co, tinyurl.com) que redireciona para um destino mais longo ocultando a URL real.
Open redirect: vulnerabilidade em que uma aplicação aceita um parâmetro de URL como destino de redirecionamento sem validação, permitindo o phishing.

Fontes

RFC 7231, seção 6.4: HTTP Redirection: definição oficial dos códigos de redirecionamento HTTP 301, 302, 303 e 307
Google Search Central: URL redirections: documentação oficial do Google sobre o tratamento dos redirecionamentos pelo motor de busca
Palo Alto Networks Unit 42: Newly Registered Domains: pesquisa sobre o uso malicioso dos domínios registrados recentemente