ERR_TOO_MANY_REDIRECTS: achar o loop de redirecionamentos e fechá-lo

O que o erro significa

O navegador pediu uma página e o servidor respondeu “vá para este outro endereço”. O navegador foi, e o servidor respondeu de novo “vá para outro lugar”, até o destino voltar a ser o primeiro. Depois de uns vinte saltos o Chrome para e mostra “Esta página não está funcionando” com a linha “example.com redirecionou você muitas vezes” e o código ERR_TOO_MANY_REDIRECTS; o Firefox diz “A página não está redirecionando corretamente”.

O servidor está ligado, o DNS funciona, o certificado é válido: o site gira em círculo. Quase sempre o loop nasce de duas regras que se contradizem: uma exige HTTPS e outra devolve para HTTP, ou uma acrescenta www e outra tira.

Causas frequentes

1. Loop HTTP ↔ HTTPS com o Cloudflare no modo “Flexible”. O Cloudflare fala HTTPS com o visitante, mas HTTP com seu servidor. O servidor vê um pedido HTTP e redireciona para HTTPS; o Cloudflare devolve em HTTP; e assim por diante. A causa mais comum de todas.
2. Redirecionamento HTTPS duplicado. O servidor web redireciona para HTTPS, e a aplicação também (WordPress, um plugin, um .htaccess copiado), com uma condição que não enxerga o TLS porque há um proxy na frente.
3. URLs erradas no WordPress. siteurl e home apontam para http:// ou para o domínio sem www, enquanto o servidor exige https://www.: o WordPress devolve cada pedido para o endereço dele, o servidor manda de volta.
4. www ↔ sem www. Um .htaccess acrescenta www, o bloco server do nginx ou o painel da hospedagem tira.
5. Dois return 301 ou duas RewriteRule esquecidos de uma configuração antiga, em um arquivo incluído ou em um .htaccess de subpasta.
6. Um plugin de redirecionamento ou de cache com uma regra velha, um idioma forçado ou uma versão mobile que aponta para si mesma.

Se você é visitante

Exclua os cookies daquele site (nas configurações do navegador, só para aquele domínio) e tente em uma janela anônima ou em outro navegador. Se o erro continuar, o loop está no servidor e só o dono pode fechá-lo.

Se o site é seu: verifique primeiro

Abra o website down checker: ele mostra a cadeia de redirecionamentos vista de fora, com cada código e cada destino. O mesmo na linha de comando:

# segue os redirecionamentos e mostra os cabeçalhos (máx. 10 saltos)
curl -IL --max-redirs 10 https://example.com/

# um único pedido, sem seguir: o que o servidor responde?
curl -I https://example.com/
curl -I http://example.com/
curl -I https://www.example.com/

Leia as linhas HTTP/… e location:. Se https://example.com/ manda para o mesmo endereço, ou para http:// que manda de novo para https://, você achou o loop. O destino diz quem o produz: http:// depois de um pedido https:// indica quase sempre um proxy ou o Cloudflare; www que aparece e some indica duas regras de domínio. Para saber se é o servidor web ou a aplicação, peça um arquivo estático que a aplicação não toca:

curl -I https://example.com/robots.txt

Se o arquivo estático responde 200 e a página inicial gira em círculo, o loop está na aplicação (WordPress, plugin). Se o arquivo estático também é redirecionado, o loop está no servidor web, no .htaccess ou no proxy.

Soluções no seu servidor ou na sua hospedagem

1. Cloudflare: passar de “Flexible” para “Full (strict)”

No painel do Cloudflare, seção SSL/TLS, mude o modo para “Full (strict)”. É preciso um certificado válido no servidor de origem; se não houver, crie com o certbot ou com o certificado de origem do Cloudflare. Enquanto ficar no “Flexible”, tire o redirecionamento HTTPS do servidor e deixe o Cloudflare fazer isso com “Always Use HTTPS”. Nunca as duas coisas ao mesmo tempo.

2. Atrás de um proxy: redirecionar pelo cabeçalho certo

Atrás de um proxy, o servidor sempre vê HTTP. A regra precisa olhar X-Forwarded-Proto, não a porta:

# .htaccess (Apache)
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

No nginx, deixe o redirecionamento só no bloco que escuta na porta 80 e nenhum return 301 https://… no bloco 443.

3. WordPress: alinhar siteurl e home

Confira os dois valores e coloque-os exatamente no endereço que o servidor exige (esquema e www incluídos):

wp option get siteurl
wp option get home
wp option update siteurl https://www.example.com
wp option update home https://www.example.com

Sem WP-CLI, no wp-config.php:

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

Se o WordPress está atrás de um proxy, acrescente no wp-config.php, antes da linha require_once ABSPATH . 'wp-settings.php';:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

4. Uma única regra para o domínio

Decida uma forma canônica (https://www.example.com ou https://example.com) e deixe uma única regra que leva até ela: no servidor web, no .htaccess ou no painel da hospedagem, nunca em dois lugares. No nginx:

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

Procure regras duplicadas com grep -ri "RewriteRule\|return 301" /etc/nginx /var/www/example.com/.htaccess e nas subpastas.

5. Plugins de redirecionamento e cache

Desative por um momento os plugins de redirecionamento, cache, idioma e segurança (wp plugin deactivate nome-do-plugin, ou renomeando a pasta em wp-content/plugins/). Se o loop sumir, reative um por vez e corrija a regra no culpado; depois limpe o cache do plugin e o do Cloudflare.

Se o problema está na sua hospedagem

Em uma hospedagem compartilhada, o redirecionamento HTTPS ou www costuma ser uma opção do painel do cliente, que se soma ao seu .htaccess. Desative a opção ou sua regra, não as duas. Se não achar a origem, envie esta mensagem:

Prezados, desde aproximadamente 14h (UTC) meu site example.com responde ERR_TOO_MANY_REDIRECTS: curl -IL mostra um loop entre http e https. No meu .htaccess há uma única regra de redirecionamento. Existe um redirecionamento HTTPS ou www ativo também do lado de vocês, pelo painel ou por um proxy na frente da minha hospedagem?

Para não acontecer de novo

Um loop de redirecionamentos aparece quase sempre logo depois de uma mudança: um certificado novo, um plugin, uma troca de modo no Cloudflare. Uma verificação HTTP vinda de fora percebe na primeira volta e avisa antes dos visitantes. O servidor de origem não responde atrás do Cloudflare? É outro caso: erro 521 e 522. O navegador para no certificado? Leia “Sua conexão não é particular”. Para um site WordPress, a manutenção WordPress sob demanda acompanha atualizações e plugins, sem contrato.

Fora do ar? Nós resolvemos. No seu servidor ou em uma hospedagem compartilhada com acesso SSH, o Quick Fix, o reparo automático a preço fixo, corrige pequenos erros de configuração como uma regra de redirecionamento duplicada, com cópia de segurança antes, 24 horas por dia, inclusive nos fins de semana; o Deep Fix cuida de proxy, Cloudflare e URLs do WordPress, em blocos de 15 minutos; a estimativa é o valor máximo.