No mires solo el mensaje del navegador. Primero usa curl para ver la cadena de redirecciones:

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

Si quieres ver el proceso completo de redirección:

curl -IL http://example.com

Fíjate en el Location de cada salto:

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

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

Si ves que salta a https en un momento y vuelve a http al siguiente, eso es un bucle típico.

Yo normalmente también añado una prueba de omisión de DNS:

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

Esto te ayuda a distinguir: ¿el problema está en la capa de Cloudflare/CDN, o el propio VPS de origen está mal configurado?

Si usas Cloudflare, revisa primero el modo SSL/TLS.

La combinación más peligrosa es:

• Cloudflare configurado en Flexible
• El Nginx de origen también fuerza HTTP a HTTPS

Flexible significa: la conexión del usuario a Cloudflare es HTTPS, pero la de Cloudflare a tu VPS de origen usa HTTP.

Entonces ocurre esto:

1. El usuario visita https://example.com
2. Cloudflare solicita el origen por http://example.com
3. Nginx ve HTTP y redirige a HTTPS
4. Cloudflare vuelve a solicitar el origen por HTTP
5. Nginx vuelve a redirigir a HTTPS
6. Empieza el bucle

En este caso, no te pongas a tocar Nginx durante un buen rato: primero cambia el SSL/TLS de Cloudflare a:

Full

Lo más recomendable es:

Full (strict)

El requisito previo es un certificado de origen válido. Puedes usar Let's Encrypt o un Cloudflare Origin Certificate.

Si tu origen aún no tiene certificado, Flexible puede hacerlo funcionar temporalmente, pero no es adecuado para uso a largo plazo. En cuanto tu origen también haga redirecciones HTTPS, es fácil que se produzcan bucles.

En el propio Nginx también es fácil escribir redirecciones duplicadas.

Una configuración común es:

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

Esto está bien: significa que HTTP redirige uniformemente a HTTPS.

Pero si además escribes redirecciones raras dentro del bloque server de HTTPS, como:

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

O:

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

las cosas pueden salir mal.

Primero imprime la configuración completa:

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

Luego prueba la configuración:

sudo nginx -t

Un sitio HTTPS limpio normalmente se ve así:

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;
}

Si quieres eliminar uniformemente www, mantén solo una dirección; no tengas dos direcciones redirigiéndose entre sí.

Por ejemplo, unifica al dominio sin www:

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

No redirijas también de vuelta a www en el dominio sin www.

Muchas aplicaciones se despliegan detrás de Nginx, como:

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

El exterior ya es HTTPS, pero la aplicación backend recibe HTTP reenviado por Nginx. Si no le dices a la aplicación que "la solicitud original era en realidad HTTPS", puede enviar otra redirección por su cuenta.

Al hacer proxy inverso con Nginx, se recomienda incluir estas cabeceras:

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;
}

Si además hay Cloudflare delante, en algunos escenarios puedes ser más explícito:

proxy_set_header X-Forwarded-Proto https;

Pero no lo cambies a ciegas. Mira primero tu cadena: si Nginx mismo es el punto de entrada HTTPS, $scheme normalmente está bien; si Cloudflare al origen sigue siendo HTTP, entonces vuelve al problema del modo SSL mencionado antes.

La capa de aplicación también debe confiar en las cabeceras del proxy.

Por ejemplo, Laravel necesita los trusted proxies configurados correctamente; Django depende de SECURE_PROXY_SSL_HEADER; Express necesita:

app.set('trust proxy', true)

De lo contrario, la aplicación no ve el protocolo real y puede redirigir de forma errática por su cuenta.

WordPress es un foco de bucles de redirección.

Primero revisa las dos direcciones en los ajustes del panel:

WordPress Address (URL)
Site Address (URL)

Deberían coincidir con la dirección que visitas finalmente, por ejemplo:

https://example.com

Si no puedes entrar al panel, consulta la base de datos directamente:

wp option get home
wp option get siteurl

Si no tienes WP-CLI, consulta con MySQL:

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

Corrige:

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

Si usas plugins de caché, seguridad o SSL, también pueden hacer redirecciones HTTPS duplicadas. Durante el diagnóstico puedes desactivar los plugins temporalmente:

wp plugin deactivate --all

Cuando confirmes que el problema desapareció, vuelve a activarlos uno por uno.

Paneles como BT, 1Panel y Nginx Proxy Manager suelen tener un interruptor de "forzar HTTPS".

El problema es que mucha gente lo activa en tres lugares a la vez:

• Cloudflare Always Use HTTPS
• Forzar HTTPS en el panel
• Forzar HTTPS en el plugin de la aplicación

Cada ajuste parece razonable por separado, pero apilados pueden provocar un bucle.

Mi consejo: deja que solo una capa se encargue de la redirección principal.

Un enfoque relativamente estable:

• Cloudflare usa Full/Full strict
• El Nginx de origen se encarga de HTTP -> HTTPS
• La aplicación solo reconoce la URL final del sitio y no redirige extra

Si quieres que Cloudflare se encargue de la redirección, también vale, pero entonces no escribas un montón de reglas duplicadas en el origen. La clave no es qué capa redirige, sino que varias capas no compitan.

Algunos sitios han activado HSTS y el navegador convierte HTTP en HTTPS a la fuerza.

En ese momento, no importa cómo pruebes en el navegador: parece una redirección HTTPS automática, pero puede que el servidor ya no esté redirigiendo realmente.

Durante el diagnóstico, intenta usar:

curl -IL http://example.com

En lugar de depender solo del navegador.

También puedes usar ventanas de incógnito, cambiar de navegador o borrar la caché de HSTS.

En Chrome puedes abrir:

chrome://net-internals/#hsts

Introduce el dominio para eliminar el registro HSTS local.

Sin embargo, si tu sitio ya ha activado HSTS públicamente, no cambies la política en producción a la ligera. Usa primero curl para determinar la respuesta real del servidor.

Cuando me encuentro con un bucle de redirección HTTPS, sigo este orden:

1. Mira la cadena de redirecciones:

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

2. Si se usa Cloudflare, revisa primero el modo SSL/TLS:

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

3. Omite el CDN para probar el origen:

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

4. Revisa las reglas de redirección de Nginx:

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

5. Revisa las cabeceras del proxy inverso:

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

6. Revisa la URL del backend de la aplicación, por ejemplo WordPress:

wp option get home
wp option get siteurl

7. Desactiva temporalmente las capas de redirección duplicadas, por ejemplo plugins SSL, forzar HTTPS en el panel, Cloudflare Always Use HTTPS.

Lo más molesto de los bucles de redirección HTTPS es que cada capa parece "configurada de forma segura".

Cloudflare quiere ayudarte a redirigir a HTTPS, Nginx quiere ayudarte a redirigir a HTTPS y el plugin de WordPress también quiere ayudarte a redirigir a HTTPS. El resultado no es más seguridad, sino una pelea.

Al diagnosticar, no reemitas el certificado de entrada ni recargues Nginx una y otra vez. Primero imprime la cadena de redirecciones y mira con claridad qué capa está redirigiendo la solicitud de dónde a dónde.

Con que recuerdes una frase, básicamente no te desviarás:

En toda la cadena, deja que solo una capa se encargue de la redirección principal de HTTP a HTTPS; las demás capas deben identificar el protocolo real y no duplicar el trabajo.