Un bucle aparece cuando dos capas discrepan sobre el protocolo o dominio canónico. El navegador llega por HTTPS a un proxy, el origen cree que recibió HTTP y vuelve a redirigir; o www, WordPress y el servidor envían al visitante en círculo.
Captura toda la cadena antes de borrar cookies o añadir otra regla.
Sigue cada salto
Usa la pestaña Red o un cliente sin seguimiento automático:
curl -I https://example.com/Anota estado, Location, cabeceras de servidor o CDN y host o protocolo que se repite. Oculta cookies y valores privados. Prueba raíz, www, login y una URL de contenido por separado.
Verifica primero el certificado
HTTPS debe presentar un certificado válido para el host y una cadena completa. Un error de certificado es distinto de una redirección.
Instala o renueva Let’s Encrypt cuando DNS apunte correctamente. No desactives la verificación ni elijas un origen HTTP flexible solo para esconder un problema TLS. Comprueba cobertura para raíz y www.
Alinea las URLs de WordPress
Lee home, siteurl, WP_HOME y WP_SITEURL. Deben representar el host HTTPS y la ruta canónicos.
No establezcas valores incompatibles simultáneamente en base de datos y constantes. Haz copia y usa WP-CLI o una modificación precisa. Respeta la arquitectura intencionada de subdirectorios y multisite.
Configura la detección HTTPS del proxy
Si Cloudflare o un balanceador termina TLS, PHP puede recibir HTTP junto a una cabecera de protocolo reenviada. WordPress debe reconocerla únicamente desde el proxy conocido.
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
&& 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
$_SERVER['HTTPS'] = 'on';
}Este patrón simplificado necesita controles de confianza. Aceptar cabeceras reenviadas de cualquier visitante permite falsificaciones.
Revisa el modo SSL de Cloudflare
El modo Flexible usa HTTP hacia el origen y choca con frecuencia con una redirección HTTPS del servidor. Prefiere Full (strict) y un certificado válido en origen.
Revisa Origin Rules y Always Use HTTPS. Elige un responsable claro de la canonicalización o haz que todas las capas coincidan. No acumules Page Rules, Bulk Redirects y plugins contradictorios.
Inspecciona Apache o Nginx
Copia .htaccess o la configuración de Nginx e identifica reglas de HTTP a HTTPS y de www. Una condición basada en la variable equivocada puede redirigir incluso peticiones que ya llegaron seguras al proxy.
Usa condiciones conscientes del proxy y un solo destino canónico. Valida Nginx mediante controles autorizados. No reemplaces directivas de multisite, idioma o seguridad en bloque.
Comprueba plugins, cookies y caché
Plugins SSL, de seguridad o redirección pueden añadir un salto desde PHP. Aísla únicamente el componente implicado, preferentemente en staging o con WP-CLI.
Las cookies antiguas pueden alternar entre hosts, pero bórralas solo en el navegador de prueba después de corregir la configuración. Revisa dominio, ruta y hora del sistema. La caché pública no debe guardar un redirect bajo el protocolo incorrecto.
Distingue HSTS del fallo del servidor
HSTS hace que el navegador cambie HTTP a HTTPS antes de contactar. La precarga sigue activa aunque cambies ajustes locales. Compara un perfil limpio y un cliente de línea de comandos.
No retires HTTPS para esquivar HSTS. Si incluyes subdominios, todos deben soportarlo antes de ampliar la política; sus consecuencias duran mucho tiempo.
Identifica qué capa posee cada redirect
En staging, añade una cabecera identificadora o desactiva una capa cada vez: CDN, servidor, plugin y código. Prepara una matriz de host/protocolo de entrada y salida esperada.
Elimina reglas redundantes cuando encuentres la discrepancia. Un solo propietario resulta más fácil de auditar. Confirma que se conservan las query strings.
Verifica una canonicalización corta
Prueba HTTP raíz, HTTP www, host HTTPS alternativo y URL HTTPS final. Todos deben llegar al destino con pocos saltos predecibles.
Comprueba login, administración, REST, recursos y restablecimiento de contraseña. HTTPS es estable cuando cada capa interpreta igual la petición original.