Não olhe só a mensagem do navegador. Primeiro use curl para ver a cadeia de redirecionamentos:

curl -I http://example.com
curl -I https://example.com

Se quiser ver o processo completo de redirecionamento:

curl -IL http://example.com

Preste atenção no Location de cada salto:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

HTTP/2 301
location: http://example.com/

Se você vir ele pular para https em um momento e voltar para http no seguinte, isso é um loop clássico.

Eu normalmente também adiciono um teste de contorno de DNS:

curl -I --resolve example.com:443:源站IP https://example.com

Isso ajuda a distinguir: o problema está na camada da Cloudflare/CDN, ou o próprio VPS de origem está mal configurado?

Se você usa Cloudflare, verifique primeiro o modo SSL/TLS.

A combinação mais perigosa é:

• Cloudflare configurado em Flexible
• O Nginx de origem também forçando HTTP para HTTPS

Flexible significa: a conexão do usuário até a Cloudflare é HTTPS, mas a da Cloudflare até o seu VPS de origem usa HTTP.

Então acontece isto:

1. O usuário acessa https://example.com
2. A Cloudflare solicita a origem via http://example.com
3. O Nginx vê HTTP e redireciona para HTTPS
4. A Cloudflare solicita a origem via HTTP de novo
5. O Nginx redireciona de volta para HTTPS de novo
6. O loop começa

Nesse caso, não fique mexendo no Nginx por um tempão: primeiro mude o SSL/TLS da Cloudflare para:

Full

O mais recomendado é:

Full (strict)

O pré-requisito é um certificado de origem válido. Você pode usar Let's Encrypt ou um Cloudflare Origin Certificate.

Se a sua origem ainda não tem certificado, o Flexible pode fazer funcionar temporariamente, mas não é adequado para uso a longo prazo. Basta a sua origem também fazer redirecionamento HTTPS para os loops ficarem fáceis de acontecer.

No próprio Nginx também é fácil escrever redirecionamentos duplicados.

Uma configuração comum é:

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

Isso está certo: significa que o HTTP redireciona uniformemente para HTTPS.

Mas se você também escrever redirecionamentos estranhos dentro do bloco server de HTTPS, como:

if ($scheme = http) {
    return 301 https://$host$request_uri;
}

Ou:

return 301 http://example.com$request_uri;

as coisas podem dar errado.

Primeiro imprima a configuração completa:

sudo nginx -T | grep -n "return 301\|rewrite\|server_name\|listen"

Depois teste a configuração:

sudo nginx -t

Um site HTTPS limpo normalmente fica assim:

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

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com;
    index index.html index.php;
}

Se você quiser remover uniformemente o www, mantenha apenas uma direção; não tenha duas direções redirecionando uma para a outra.

Por exemplo, unifique no domínio sem www:

server {
    listen 443 ssl http2;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Não redirecione também de volta para www no domínio sem www.

Muitas aplicações são implantadas atrás do Nginx, como:

用户 -> Nginx HTTPS -> Node / Django / Laravel / WordPress

O lado externo já é HTTPS, mas a aplicação backend recebe HTTP encaminhado pelo Nginx. Se você não avisar à aplicação que "a requisição original era na verdade HTTPS", ela pode enviar outro redirecionamento por conta própria.

Ao fazer proxy reverso com Nginx, recomenda-se incluir estes cabeçalhos:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Se também houver Cloudflare na frente, em alguns cenários você pode ser mais explícito:

proxy_set_header X-Forwarded-Proto https;

Mas não mude isso às cegas. Olhe primeiro a sua cadeia: se o próprio Nginx é o ponto de entrada HTTPS, $scheme normalmente está certo; se a Cloudflare até a origem ainda é HTTP, então volte ao problema do modo SSL mencionado antes.

A camada da aplicação também precisa confiar nos cabeçalhos do proxy.

Por exemplo, o Laravel precisa dos trusted proxies configurados corretamente; o Django depende de SECURE_PROXY_SSL_HEADER; o Express precisa de:

app.set('trust proxy', true)

Caso contrário, a aplicação não vê o protocolo real e pode redirecionar de forma errática por conta própria.

O WordPress é um ponto crítico de loops de redirecionamento.

Primeiro verifique os dois endereços nas configurações do painel:

WordPress Address (URL)
Site Address (URL)

Eles devem corresponder ao endereço que você acessa no final, por exemplo:

https://example.com

Se você não conseguir entrar no painel, consulte o banco de dados diretamente:

wp option get home
wp option get siteurl

Se não tiver WP-CLI, consulte com MySQL:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('home', 'siteurl');

Corrija:

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

Se você usa plugins de cache, segurança ou SSL, eles também podem fazer redirecionamentos HTTPS duplicados. Durante o diagnóstico, você pode desativar os plugins temporariamente:

wp plugin deactivate --all

Depois de confirmar que o problema sumiu, reative um por um.

Painéis como BT, 1Panel e Nginx Proxy Manager geralmente têm um botão de "forçar HTTPS".

O problema é que muita gente ativa em três lugares ao mesmo tempo:

• Cloudflare Always Use HTTPS
• Forçar HTTPS no painel
• Forçar HTTPS no plugin da aplicação

Cada configuração parece razoável isoladamente, mas empilhadas podem causar loop.

Meu conselho: deixe apenas uma camada responsável pelo redirecionamento principal.

Uma abordagem relativamente estável:

• Cloudflare usa Full/Full strict
• O Nginx de origem cuida do HTTP -> HTTPS
• A aplicação só reconhece a URL final do site e não redireciona a mais

Se você quiser que a Cloudflare cuide do redirecionamento, também pode, mas então não escreva um monte de regras duplicadas na origem. O ponto principal não é qual camada redireciona, mas sim que várias camadas não fiquem competindo.

Alguns sites ativaram HSTS e o navegador força a conversão de HTTP em HTTPS.

Nesse momento, não importa como você teste no navegador, parece um redirecionamento HTTPS automático, mas pode ser que o servidor não esteja mais redirecionando de fato.

Durante o diagnóstico, tente usar:

curl -IL http://example.com

Em vez de depender só do navegador.

Você também pode usar janelas anônimas, trocar de navegador ou limpar o cache de HSTS.

No Chrome você pode abrir:

chrome://net-internals/#hsts

Digite o domínio para excluir o registro HSTS local.

Porém, se o seu site já ativou HSTS publicamente, não altere a política em produção de qualquer jeito. Use primeiro o curl para determinar a resposta real do servidor.

Quando encontro um loop de redirecionamento HTTPS, sigo esta ordem:

1. Veja a cadeia de redirecionamentos:

curl -IL http://example.com
curl -IL https://example.com

2. Se usar Cloudflare, verifique primeiro o modo SSL/TLS:

Flexible -> 高风险
Full / Full strict -> 更合理

3. Contorne o CDN para testar a origem:

curl -I --resolve example.com:443:源站IP https://example.com

4. Verifique as regras de redirecionamento do Nginx:

sudo nginx -T | grep -n "return 301\|rewrite"

5. Verifique os cabeçalhos do proxy reverso:

sudo nginx -T | grep -n "X-Forwarded-Proto\|proxy_set_header"

6. Verifique a URL do backend da aplicação, por exemplo WordPress:

wp option get home
wp option get siteurl

7. Desative temporariamente as camadas de redirecionamento duplicadas, por exemplo plugins SSL, forçar HTTPS no painel, Cloudflare Always Use HTTPS.

O mais chato dos loops de redirecionamento HTTPS é que cada camada parece "configurada com segurança".

A Cloudflare quer te ajudar a redirecionar para HTTPS, o Nginx quer te ajudar a redirecionar para HTTPS e o plugin do WordPress também quer te ajudar a redirecionar para HTTPS. O resultado não é mais segurança, é uma briga.

Ao diagnosticar, não reemita o certificado de cara nem fique recarregando o Nginx várias vezes. Primeiro imprima a cadeia de redirecionamentos e veja com clareza qual camada está redirecionando a requisição de onde para onde.

Basta lembrar de uma frase e você basicamente não vai errar:

Em toda a cadeia, deixe apenas uma camada responsável pelo redirecionamento principal de HTTP para HTTPS; as outras camadas devem identificar o protocolo real e não duplicar o trabalho.