WordPress en bucle http https por SSL mal instalado
Soluciona el bucle http https en WordPress con un diagnóstico fiable y evita redirecciones duplicadas sin romper tu acceso web.
El bucle http https en WordPress es una redirección infinita entre versiones HTTP y HTTPS de la misma web. Suele aparecer tras un SSL mal instalado o mal coordinado entre WordPress, servidor, plugin o proxy, y acaba provocando errores como ERR_TOO_MANY_REDIRECTS. La forma correcta de resolverlo no es activar opciones al azar, sino identificar primero qué capa está redirigiendo.
En la práctica, este problema no siempre nace en un único punto. Puede deberse a reglas duplicadas en .htaccess WordPress, ajustes en wp-config.php, un plugin que intenta forzar HTTPS, una configuración de hosting, un proxy inverso o un modo SSL incorrecto en Cloudflare. Si no se diagnostica bien, es fácil empeorar el conflicto y perder acceso al panel.
Mini checklist antes de editar nada
- Confirma si falla toda la web o solo /wp-admin.
- Anota si usas Apache, Nginx, hosting gestionado o Cloudflare.
- Comprueba si el error aparece en incógnito y en varios navegadores.
- Revisa si has instalado recientemente un certificado SSL, un plugin de SSL o una regla de redirección.
- No actives nuevas redirecciones hasta saber cuál ya está funcionando.
Qué es un bucle http https en WordPress y cómo se manifiesta
Un bucle de redirección ocurre cuando una petición a http:// se envía a https://, pero otra capa devuelve la petición a HTTP o vuelve a lanzar una redirección adicional sin llegar nunca a una respuesta final válida. El navegador interpreta esa cadena de redirecciones como un conflicto y muestra un error.
Los síntomas más habituales son estos:
- Error ERR_TOO_MANY_REDIRECTS en Chrome.
- Mensaje de página no redirige correctamente en Firefox.
- Acceso imposible al frontal y al administrador de WordPress.
- La URL cambia entre HTTP y HTTPS repetidamente.
- El problema aparece justo después de instalar un certificado, activar Cloudflare o tocar reglas de redirección.
Conviene no confundirlo con mixed content. El contenido mixto carga una página HTTPS con recursos internos en HTTP; suele generar avisos de seguridad o elementos rotos, pero no necesariamente un bucle. El bucle, en cambio, impide llegar siquiera a la página final.
Por qué aparece cuando el SSL está mal instalado o mal configurado
El problema suele aparecer cuando el entorno no tiene una única fuente clara de verdad sobre si la petición llega por HTTP o por HTTPS. Eso puede pasar aunque exista un certificado SSL instalado, porque el fallo no siempre está en el certificado en sí, sino en cómo se interpreta la conexión en cada capa.
Escenarios comunes:
- Redirección duplicada entre WordPress y el servidor.
- Plugin de SSL activo además de reglas manuales previas, por ejemplo con Really Simple SSL.
- Cloudflare SSL en modo incorrecto, como Flexible cuando el servidor también fuerza HTTPS.
- Proxy inverso que termina SSL, pero no entrega bien las cabeceras como X-Forwarded-Proto.
- Cadena intermedia del certificado mal configurada o instalación incompleta a nivel de hosting.
- HSTS ya activo mientras se siguen probando reglas contradictorias.
Importante: forzar HTTPS no es una solución universal. Si ya existe una redirección en otra capa, añadir una segunda o tercera regla puede convertir un ajuste correcto en un conflicto de redirecciones.
Cómo diagnosticar la cadena de redirecciones sin tocar nada a ciegas
Antes de editar archivos o desactivar plugins, hay que observar la secuencia exacta de respuestas. El objetivo es saber quién redirige primero y quién vuelve a redirigir después.
1. Comprueba la URL final y el patrón del salto
Si ves cambios entre http://dominio y https://dominio, o entre www y sin www, ya tienes una pista. A veces el bucle no es solo HTTP/HTTPS, sino una combinación de protocolo y canonicalización del dominio.
2. Revisa cabeceras y respuesta HTTP
Desde el panel de hosting, consola o herramientas técnicas, revisa las respuestas 301 o 302. Lo relevante no es solo que haya redirección, sino qué servidor o capa la devuelve: WordPress, Apache, Nginx, CDN o proxy.
3. Aísla las capas
Si usas Cloudflare o un proxy, comprueba primero si el comportamiento cambia al pausar temporalmente la capa de proxy o revisar su modo SSL. Si el problema desaparece, el origen no está necesariamente en WordPress, sino en la interacción entre ambas capas.
4. Verifica si WordPress “cree” que la conexión es segura
En ciertos entornos, el servidor termina el SSL antes de llegar a PHP. En ese caso, WordPress puede no detectar correctamente HTTPS si no recibe las cabeceras adecuadas. El resultado típico es que WordPress intenta corregir la URL una y otra vez.
5. Comprueba cambios recientes
Pregunta clave: ¿qué se tocó justo antes del fallo? Certificado nuevo, migración, cambio de hosting, activación de CDN, plugin SSL, modificación del .htaccess o ajuste en el panel del hosting. Ese dato ahorra mucho tiempo de diagnóstico.
Criterio práctico:
- Si la redirección ocurre antes de cargar WordPress, mira servidor, CDN o proxy.
- Si empezó tras cambiar URL del sitio o activar un plugin, revisa WordPress primero.
- Si solo falla tras pasar por Cloudflare, revisa el modo SSL y las cabeceras.
Qué revisar en WordPress, .htaccess y wp-config.php
Una vez identificado el punto probable del conflicto, toca revisar las capas de WordPress con orden. No se trata de añadir reglas, sino de detectar duplicidades o contradicciones.
URL de WordPress y del sitio
Comprueba que Dirección de WordPress (URL) y Dirección del sitio (URL) usan el protocolo correcto y son coherentes con la configuración real del servidor. Si el panel no es accesible, puede revisarse en base de datos o en constantes definidas, siempre con copia previa.
Reglas en .htaccess WordPress
Busca reglas manuales de redirección a HTTPS, saltos de dominio o condiciones heredadas de migraciones antiguas. Si además el hosting ya fuerza HTTPS desde panel, esas reglas pueden sobrar.
Ejemplo orientativo de regla manual en Apache, solo si esa es la capa elegida:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Ese ejemplo no debe añadirse si ya existe una redirección equivalente en Nginx, en el panel del hosting, en Cloudflare o en un plugin.
Constantes y ajustes en wp-config.php
Revisa si hay constantes que fijan URLs o fragmentos para detectar HTTPS tras proxy. En algunos entornos se usa una comprobación basada en cabeceras para que WordPress entienda que la conexión original fue segura.
Ejemplo orientativo, solo cuando existe proxy o balanceador y las cabeceras son fiables:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}No lo apliques como receta universal. Si el servidor no envía esa cabecera o lo hace de otra forma, la solución correcta será distinta.
Plugins relacionados con SSL y caché
Comprueba si hay plugins que modifican HTTPS en WordPress, redirecciones o URL canónicas. Un plugin puede funcionar bien por sí solo, pero entrar en conflicto con reglas ya activas en otras capas. Tras desactivar, limpia caché de aplicación, servidor y CDN antes de volver a probar.
Cloudflare, proxies y servidores: dónde suelen duplicarse las redirecciones
Muchos bucles no nacen en WordPress, sino entre la red pública y el servidor. Este es uno de los escenarios más habituales cuando la web está detrás de Cloudflare, un proxy inverso o una plataforma de hosting gestionado.
Cloudflare
El caso clásico es usar Cloudflare SSL en modo Flexible mientras el servidor de origen fuerza HTTPS. Cloudflare habla HTTP con el origen, el origen intenta devolverlo a HTTPS, y aparece el bucle. Si el certificado del servidor está bien instalado, normalmente conviene revisar modos como Full o Full (strict), según corresponda al entorno real.
Nginx, Apache y paneles del hosting
En hostings de España es frecuente tener varias capas de control: una redirección en cPanel, Plesk o panel propio, otra en Nginx frontal y otra dentro de Apache o WordPress. Si dos de ellas intentan resolver lo mismo con criterios distintos, el conflicto aparece.
Proxy inverso y cabeceras
Cuando un balanceador o proxy termina SSL, la aplicación necesita saber que el usuario original llegó por HTTPS. Si las cabeceras como X-Forwarded-Proto no se reenvían o no se interpretan bien, WordPress puede pensar que sigue en HTTP y tratar de corregirlo en cada petición.
HSTS
La cabecera HSTS obliga al navegador a usar HTTPS durante un periodo. No suele ser la causa primaria del bucle, pero puede dificultar las pruebas y hacer que parezca que una redirección sigue activa aunque ya la hayas quitado de otra capa. Por eso conviene revisar también caché y políticas de navegador.
Cómo corregir el problema sin romper el acceso a la web
La corrección más segura consiste en dejar una sola capa responsable de la redirección principal a HTTPS y verificar que el resto no la contradice.
- Haz copia de seguridad de archivos y base de datos antes de tocar configuración.
- Identifica la capa origen del bucle: WordPress, servidor, panel, Cloudflare o proxy.
- Desactiva solo la regla duplicada, no todas a la vez si no controlas el entorno.
- Verifica el certificado SSL: instalación correcta, nombre de dominio válido y cadena intermedia completa si el hosting lo requiere.
- Confirma las URLs del sitio y el reconocimiento de HTTPS por parte de WordPress.
- Limpia cachés de navegador, plugin, servidor y CDN antes de volver a probar.
- Prueba primero en incógnito y, si puedes, desde otra red o dispositivo.
Si el acceso al panel ya está bloqueado, suele ser más prudente intervenir desde administrador de archivos, SFTP, panel del hosting o asistencia técnica del proveedor. En entornos gestionados, muchas veces el soporte puede confirmar si la redirección se está aplicando en Nginx, balanceador o plataforma, algo que no siempre es visible desde WordPress.
| Síntoma | Posible origen | Primera revisión |
|---|---|---|
| Bucle tras activar Cloudflare | Modo SSL o reglas duplicadas | Modo Flexible/Full y reglas de origen |
| Bucle tras instalar plugin SSL | Plugin + .htaccess + panel | Plugins activos y reglas preexistentes |
| Bucle solo en /wp-admin | URL, cookies o HTTPS detectado mal | wp-config.php y cabeceras del proxy |
| Bucle tras migración de hosting | Servidor frontal o certificado incompleto | Configuración del nuevo proveedor |
Errores frecuentes y cómo evitar que el bucle vuelva a aparecer
- Añadir redirecciones “por si acaso”. Si no sabes qué capa manda, solo aumentas el riesgo.
- Confundir mixed content con bucle. Son problemas distintos y se solucionan de forma diferente.
- Dar por hecho que el certificado basta. El certificado puede ser válido y aun así existir un conflicto de redirecciones.
- No revisar cabeceras del proxy. En arquitecturas con CDN o balanceador, esto es clave.
- Olvidar la caché. Puede hacerte creer que el problema sigue igual cuando ya has corregido la regla real.
- Activar HSTS demasiado pronto. Mejor cuando HTTPS ya está estable y validado.
Para prevenir recaídas, documenta dónde queda la redirección definitiva, evita duplicarla en plugins y paneles, y revisa siempre la arquitectura antes de migrar o cambiar DNS. Si trabajas con terceros, deja claro si la terminación SSL se hace en el servidor, en una CDN o en un proxy intermedio.
FAQ breve
¿ERR_TOO_MANY_REDIRECTS siempre significa que el certificado SSL está mal?
No. Puede haber un certificado correcto y, aun así, una mala coordinación entre WordPress, servidor y proxy que provoque el bucle.
¿Puedo arreglarlo solo cambiando la URL del sitio a HTTPS?
No necesariamente. Si otra capa ya redirige o interpreta mal el protocolo, ese cambio por sí solo no basta y puede incluso complicar el acceso.
¿Really Simple SSL es el problema?
No siempre. Puede ayudar en algunos escenarios, pero también añadir una capa extra si ya existían redirecciones previas en el servidor o CDN.
Diagnóstico correcto antes de tocar redirecciones
La forma fiable de resolver un bucle http https en WordPress es localizar primero la capa que origina la redirección y eliminar duplicidades con cautela. No conviene asumir que todo se arregla forzando HTTPS, porque el problema suele estar en la convivencia entre WordPress, servidor, plugin, proxy o CDN.
Si necesitas recuperar el acceso sin arriesgar más cambios, el siguiente paso razonable es revisar la cadena real de redirecciones con criterio técnico y confirmar dónde se aplica la regla definitiva. Cuando el entorno incluye hosting gestionado, Cloudflare o proxy inverso, una revisión especializada puede ahorrar tiempo y evitar que el fallo vuelva a aparecer.
¿Necesitas orientación personalizada?
Te ayudamos a entender tus opciones y el siguiente paso.