Loop de Redirecionamento: Como Encontrar e Corrigir o ERR_TOO_MANY_REDIRECTS

Um loop de redirecionamento é uma cadeia de redirecionamentos HTTP que nunca chega a lugar nenhum: a URL A manda o navegador para a URL B, B manda de volta para A, e depois de mais ou menos vinte saltos o navegador desiste de tentar e exibe ERR_TOO_MANY_REDIRECTS. Nada está quebrado na página de destino. Duas regras estão simplesmente discordando sobre onde a URL deveria estar, e cada uma continua desfazendo a outra.

Um redirecionamento em loop é um dos poucos erros da web que revela a sua própria causa, desde que você olhe para a coisa certa. Não o navegador, não a página de erro, e definitamente não o cache: a cadeia de redirecionamento. Cada salto carrega um cabeçalho Location, e os dois endereços que continuam se repetindo são as duas regras que você precisa reconciliar. Este guia percorre o diagnóstico em um comando, as causas por trás de quase todo ciclo de redirecionamento que já tive que desmontar, e a correção que não cria silenciosamente um segundo loop em outro lugar. Se a própria família de redirecionamentos ainda estiver confusa, tipos de redirecionamento de URL é o mapa; este aqui é a versão de solução de problemas.

O Que o ERR_TOO_MANY_REDIRECTS Realmente Significa

Os navegadores seguem redirecionamentos em seu nome, mas não para sempre. Cada cliente mantém um orçamento de saltos e abandona a solicitação quando ele se esgota: o Chrome para em 20 e não deixa você mudar isso, o Firefox traz o mesmo padrão sob network.http.redirection-limit, e o curl permite 50 antes de reclamar. A especificação deixa o número em aberto. A RFC 9110 só diz que um cliente deveria detectar e intervir em redirecionamentos cíclicos, que é a forma educada da especificação de dizer que todo navegador precisa de um disjuntor.

Essa distinção importa para o diagnóstico, porque o erro não prova que exista um ciclo. Uma cadeia de vinte e um saltos distintos sem repetições dispara exatamente a mesma mensagem que duas URLs ficando de um lado para o outro para sempre. Vale a pena corrigir os dois casos, mas só um deles tem um par de endereços para reconciliar. A referência de redirecionamento do MDN cobre as duas formas, e a diferença prática aparece no instante em que você imprime a cadeia.

Mais uma coisa que a página de erro esconde: um redirecionamento permanente fica em cache no navegador. Se o loop foi construído com respostas 301, os visitantes continuam entrando em loop localmente mesmo depois que você corrige o servidor, até que essa entrada de cache expire ou eles a limpem. Esse único fato é o motivo pelo qual eu testo mudanças de redirecionamento com um 302 e só promovo para 301 depois que a cadeia estiver correta, um hábito que 301 vs 302: qual redirecionamento usar argumenta a favor por completo.

Rastreie a Cadeia de Redirecionamento em Um Comando

Deixe o navegador de lado. A leitura mais rápida de qualquer loop de redirecionamento é o terminal, porque o curl imprime cada salto em vez de colapsá-los em uma única página de erro:

curl -sIL https://example.com | grep -E '^HTTP|^[Ll]ocation'

Você recebe uma linha de status e um cabeçalho Location por salto, em ordem. Leia de cima para baixo e um de três padrões aparece. Duas URLs se alternando significa um ciclo de verdade, e o par identifica as duas regras culpadas. Uma longa sucessão de URLs distintas significa uma cadeia que alguém foi empilhando ao longo dos anos, cada salto legítimo por conta própria. E uma cadeia que resolve bem no terminal mas ainda falha no navegador significa que o loop é causado por cookies, já que o curl não envia cookies por padrão.

Esse último caso merece uma verificação própria, porque é o que faz as pessoas culparem o DNS delas por uma tarde inteira:

curl -sIL -c jar.txt -b jar.txt https://example.com/account | grep -E '^HTTP|^[Ll]ocation'

Com um cookie jar anexado, um loop de login ou de consentimento se reproduz na linha de comando, onde você consegue ver exatamente qual endpoint fica definindo e depois rejeitando a sessão. No navegador, a visão equivalente é o painel Network com "Preserve log" ativado, que evita que os saltos anteriores sejam apagados quando a página navega. Se você preferir nem abrir um terminal, o nosso verificador de links rastreia a cadeia no navegador e imprime o código de status em cada salto.

As Causas por Trás de Quase Todo Ciclo de Redirecionamento

Assim que você consegue ver a cadeia, a causa geralmente é uma entre um punhado de opções. O par de URLs que se repete diz qual camada olhar: o esquema alternando entre si aponta para o encerramento de TLS, o hostname alternando aponta para uma regra de host canônico, e um caminho que fica ganhando e perdendo uma barra aponta para a ordem das regras de reescrita.

regras de https atrás de um proxy que encerra o TLS

Esse é o redirecionamento infinito mais comum na web moderna, e ele apareceu no momento em que os proxies começaram a encerrar o TLS na frente das origens. O proxy aceita uma solicitação HTTPS do visitante, depois busca a sua origem por HTTP simples. A sua origem vê uma solicitação insegura, faz o que você mandou fazer, e redireciona para HTTPS. O proxy serve esse redirecionamento, recebe a pergunta de novo, busca a origem por HTTP de novo, e o ciclo continua. A Cloudflare documenta exatamente essa falha sob o modo de criptografia flexible, e todo outro proxy tem a mesma armadilha com um nome diferente.

Existem duas correções limpas. Mude o proxy para um modo de criptografia full para que ele fale com a sua origem por TLS, que é a resposta correta em quase todos os casos. Ou, se o salto até a origem realmente precisar continuar simples, faça a regra da origem ler o cabeçalho X-Forwarded-Proto em vez da conexão bruta, para que ela pare de redirecionar solicitações que já estavam seguras na borda.

www e domínio raiz discordando sobre qual host prevalece

Uma regra de host canônico está tudo bem. Duas delas, escritas em momentos diferentes por pessoas diferentes, viram um loop. A versão clássica tem uma configuração de servidor mandando o domínio raiz para www enquanto a configuração da aplicação manda www de volta para o domínio raiz, e as duas têm certeza de que estão certas. Você vai ver isso instantaneamente na cadeia: example.com para www.example.com para example.com, para sempre.

Escolha um host, aplique-o em exatamente um lugar, e exclua a outra regra em vez de tentar fazer as duas concordarem. O mesmo vale para uma reescrita de barra final ou de minúsculas: quando duas regras normalizam a mesma URL em direções opostas, você tem um ciclo de redirecionamento mesmo que cada regra seja individualmente sensata.

a configuração de URL do CMS ou da aplicação que não corresponde mais

A maioria das aplicações armazena o seu próprio endereço canônico, e esse campo é uma regra de redirecionamento com um nome simpático. Mude o domínio, migre para um ambiente novo, ou restaure um snapshot de banco de dados de outro host, e a aplicação começa a redirecionar cada solicitação para um endereço que redireciona de volta. Como a configuração vive no banco de dados em vez de na configuração do seu servidor web, ela sobrevive à auditoria de configuração que você acabou de fazer, o que é o que torna tão irritante encontrá-la.

A assinatura é uma cadeia que sai do seu hostname atual e nunca volta para ele. Corrija o endereço armazenado para o domínio que você está realmente servindo, e depois limpe qualquer cache de aplicação ou de página que tenha capturado o endereço errado.

loops de cookie e sessão que só afetam usuários logados

Aqui as regras são inocentes e o estado é o problema. Uma barreira redireciona visitantes não autenticados para uma página de login, a página de login redireciona os autenticados de volta, e um cookie de sessão que não pode ser lido no domínio de destino deixa os dois lados convencidos de que o outro deveria cuidar disso. Banners de consentimento causam a mesma forma quando o próprio redirecionamento que define o cookie de consentimento é bloqueado.

O sinal é o mesmo da seção anterior: uma janela anônima limpa funciona, ou o curl sem cookie jar resolve normalmente. Verifique o domínio do cookie e o escopo Path, os atributos Secure e SameSite em relação ao esquema que você está realmente servindo, e se ele está sendo definido no apex enquanto é lido em www.

Loops de redirecionamento raramente são um mistério depois que a cadeia está na tela, mas eles comem uma tarde inteira quando você chuta em vez de rastrear. Se você preferir ser dono da camada de redirecionamento em vez de discutir com ela, o plano gratuito da Elido te dá links cujo destino é um único valor armazenado que você pode reapontar, com cada salto registrado.

Corrija Sem Criar um Segundo Loop

A correção em si é curta, e a ordem importa mais do que a sintaxe. Mude uma regra, depois rastreie de novo. Mudar três e recarregar não diz nada sobre qual delas importava, e eu já vi uma equipe passar uma hora assim em um loop causado por uma regra que eles já tinham corrigido na primeira tentativa.

1. Remova ou inverta exatamente uma das duas regras que a cadeia identificou, para que uma solicitação consiga chegar a um 200 em um único salto.
2. Execute o rastreamento curl -sIL de novo e confirme que a cadeia agora tem no máximo um redirecionamento, sem hostname repetido.
3. Limpe o cache do navegador, ou teste em uma janela anônima, porque qualquer 301 que você serviu antes ainda está em cache localmente e vai simular uma falha que não existe mais.
4. Só então promova redirecionamentos temporários para permanentes, depois que a forma da cadeia estiver resolvida.

Duas armadilhas ficam no final dessa lista. O HSTS é uma delas: assim que um host envia um cabeçalho Strict-Transport-Security, os navegadores passam a fazer o upgrade de toda solicitação para HTTPS por conta própria, então uma regra de origem que também força HTTPS fica redundante e pode transformar uma configuração errada de proxy em um loop que você não consegue reproduzir sem limpar a entrada de HSTS. A outra é o cache na frente do loop. Uma CDN que colocou um 301 em cache vai continuar servindo-o feliz mesmo depois que a origem parar de enviá-lo, e é por isso que uma limpeza de cache faz parte da correção, não vem depois dela. Cadeias longas que nunca entram em loop também valem a pena aparar na mesma passada: cada salto extra é mais uma chance de uma query string se perder, que é exatamente como os parâmetros UTM somem no GA4, e é parte do motivo pelo qual os links curtos não precisam prejudicar o SEO desde que continuem com apenas um salto de profundidade.

Quando o Loop Está em um Link Curto

Links curtos adicionam mais um lugar onde um ciclo pode se formar, e não é o redirecionamento do encurtador. Um link curto é um único salto armazenado: slug entra, destino sai. O loop aparece quando o destino aponta de volta, o que acontece com mais frequência do que parece. Alguém edita um link de campanha para apontar para uma landing page, a landing page tem uma regra antiga redirecionando para a URL curta porque esse era o endereço canônico de compartilhamento no trimestre passado, e agora os dois ficam quicando. Os dois saltos estão se comportando exatamente como configurados.

Duas outras variantes aparecem na mesma cadeia. Uma é um par de links curtos apontando um para o outro depois de uma edição em massa, geralmente de uma importação de planilha em que a coluna de destino continha URLs curtas em vez de URLs finais. A outra é um domínio personalizado ainda resolvendo para um host que redireciona de volta para o encurtador, o que é um resíduo de DNS em vez de um problema de link, e domínios personalizados para links curtos cobre como os registros deveriam estar. Nos três casos, a correção é definir o destino como a página final em vez de outro redirecionamento, o que você pode fazer sem tocar em nada que já esteja impresso ou publicado.

Como o destino é armazenado em vez de embutido na URL, nada disso exige reimpressão. Esse é todo o argumento a favor dos links gerenciados, e link curto não está funcionando é o guia mais amplo de triagem para quando o sintoma não é especificamente um loop.

Impeça que o Próximo Seja Lançado

Loops de redirecionamento são um bug de desvio de configuração, então as correções duradouras são as chatas. Mantenha a decisão do host canônico em um único lugar e trate qualquer segunda regra que mexa em esquema ou hostname como um bug assim que a vir. Rastreie novos redirecionamentos com curl -sIL antes de anunciá-los, não depois que alguém relatar uma página em branco. Se os links importam para a receita, coloque uma verificação neles: um rastreamento agendado que falha quando a cadeia passa de um salto detecta o desvio bem antes de um cliente detectar, e monitoramento de redirecionamentos de link mostra como isso fica quando conectado a alertas de verdade.

O hábito mais amplo é tratar os destinos como dados que você pode auditar. Prevenção de link rot cobre a mesma disciplina para links que silenciosamente param de resolver, e é a mesma verificação semanal de qualquer forma. Sinceramente, a maioria dos loops que já vi foi lançada por duas pessoas competentes que cada uma corrigiu o mesmo problema em uma camada diferente, com um mês de diferença. Escreva a regra uma vez e o loop deixa de ser possível.

Leia a Série Principal

Este artigo está no cluster de engenharia. Para a forma do próprio caminho de redirecionamento, alcançando p95 abaixo de 15ms para redirecionamentos cobre quanto custa um único salto bem-comportado, e tipos de redirecionamento de URL cobre qual código de status pertence a cada situação antes de você começar a empilhar regras.

Relacionado no Blog

• Tipos de redirecionamento de URL: 301, 302, 307, 308 e mais
• Redirecionamentos 301 vs 302: qual usar em links curtos
• Link curto não está funcionando? Diagnostique em um comando
• Domínios personalizados para links curtos: DNS, TLS e a borda
• Vulnerabilidades de redirecionamento aberto e como preveni-las
• Monitoramento de links curtos com Sentry e Datadog