¿Te frustra que el sitio funcione en HTTP en producción, que aparezca "Too Many Redirects" o que el admin sea inaccesible tras tocar SSL y Cloudflare? Estas fallas suelen venir del cruce entre el modo SSL de Cloudflare y la lógica de plugins de caché que fuerzan o cachean redirecciones.
Solución inmediata: revisar el modo SSL/TLS de Cloudflare, validar el certificado del origen y purgar o desactivar temporalmente el plugin de caché, ejecutar comprobaciones con curl para detectar bucles y aplicar ajustes seguros (usar Full (strict) con certificado válido, configurar bypass de caché para /wp-admin y deshabilitar "Always Use HTTPS" si el servidor ya redirige). Esta publicación detalla diagnóstico reproducible, configuraciones por plugin y ejemplos de .htaccess/Nginx para resolver errores al configurar SSL con Cloudflare y plugins de caché.
Errores al configurar SSL con Cloudflare y plugins de caché en 60 segundos
- No usar Flexible en producción: el modo Flexible delega HTTPS entre navegador y Cloudflare pero deja HTTP entre Cloudflare y el origen; provoca bucles con plugins que redirigen a HTTPS.
- Mejor opción: Full (strict) si el servidor tiene certificado válido (Let's Encrypt o Origin CA); es la configuración más segura.
- Purgar caché puede romper HTTPS cuando el plugin cachea redirecciones o headers HSTS; borrar de forma controlada y hacer rollback si hay problemas.
- Diagnóstico rápido con curl: comprobar headers y redirecciones con curl -I -L --max-redirs 10 para identificar bucles y origen de redirecciones.
- Plugins críticos: WP Rocket, W3 Total Cache, LiteSpeed Cache y WP Super Cache requieren ajustes específicos para evitar errores SSL; configurar bypass para /wp-admin y desactivar forzar HTTPS en plugins.
¿Me conviene usar modo Flexible de Cloudflare con caché?
Qué hace modo Flexible: Cloudflare termina la conexión HTTPS con el visitante y se conecta por HTTP al servidor origen. Esto evita tener un certificado en el servidor, pero produce discrepancias en la detección del esquema (HTTP vs HTTPS) por parte de WordPress y plugins.
Por qué genera errores con plugins de caché: muchos plugins detectan que el sitio debería servir HTTPS y aplican redirecciones 301 desde HTTP. Con Flexible, Cloudflare pide HTTP al origen, el origen responde con una redirección a HTTPS, Cloudflare reintenta y puede crear un bucle o devolver "Too Many Redirects". Además, caches intermedias pueden almacenar redirecciones y headers HSTS, propagando el fallo.
Casos en los que sí puede convenir (excepciones):
- Sitios temporales sin control del servidor donde no es posible instalar certificado de origen.
- Migraciones rápidas con Cloudflare en modo Development o cuando el objetivo es reducir complejidad mientras se obtiene un certificado.
Recomendación general: evitar Flexible en entornos productivos con plugins de caché activos. Si no se puede evitar, aplicar medidas adicionales: desactivar forzar HTTPS en WordPress y plugins, añadir header "CF-Visitor: {/"scheme/":/"https/"}" en comprobaciones internas y usar Page Rule para desactivar la cacheo de redirecciones.
SSL completo vs Flexible con plugins de caché: comparativa y casos prácticos
| Modo Cloudflare |
Comportamiento con plugins de caché |
Recomendación |
| Flexible |
Puede causar bucles si el origen fuerza HTTPS o plugins redirigen; cachea páginas HTTP y puede almacenar redirecciones erróneas. |
Solo para entornos temporales. Si se usa, desactivar forzar HTTPS en WP y plugins y añadir reglas para no cachear redirecciones. |
| Full |
Funciona con certificados válidos o autofirmados; requiere que el servidor acepte HTTPS, pero no valida CA. |
Útil si no se puede instalar Origin CA o Let's Encrypt. Mejor que Flexible, pero menos seguro que Full (strict). |
| Full (strict) |
Requiere certificado de confianza o Origin CA; evita bucles y valida la conexión origen-Cloudflare. |
Modo recomendado en producción. Instalar Origin CA o Let's Encrypt en el servidor. |
Consejos prácticos por escenario:
- Si se usa WP Rocket: deshabilitar "Force HTTPS" dentro del plugin si Cloudflare ya redirige. Activar "Never cache URL(s)" para endpoints de login y checkout.
- Si se usa LiteSpeed Cache: usar el ajuste "Preserve Login" y excluir cookies de sesión; evitar cachear redirecciones.
- Si se usa WP Super Cache o W3 Total Cache: purgar y desactivar la opción de cacheo de redirecciones; configurar bypass para administradores.
Enlaces de referencia técnica: documentación oficial de Cloudflare sobre SSL/TLS Cloudflare SSL/TLS y la guía de HTTPS de WordPress WordPress.org: HTTPS.
Errores al purgar caché que rompen HTTPS
Por qué purgar puede romper HTTPS: algunos plugins borran objetos estáticos y redirecciones simultáneamente; si el sistema reinicia con reglas antiguas o el CDN (Cloudflare) tiene reglas en cache, pueden persistir respuestas 301/302 erróneas. Además, purgas masivas sin invalidar cookies o sin limpiar el trafico hacia /wp-admin pueden dejar el sitio en un estado mixto.
Diagnóstico reproducible (herramientas y comandos):
- curl básico para ver redirecciones y headers:
- curl -I -L -s -o /dev/null -w "%{http_code} %{url_effective}/n" https://ejemplo.com
- curl -I -s https://ejemplo.com | sed -n '1,20p'
- comprobar cabeceras Cloudflare: revisar CF-Cache-Status, CF-Ray y Server.
- analizar bucles: curl -I -L --max-redirs 10 https://ejemplo.com y revisar si el resultado final es 200 o error.
Errores comunes al purgar y soluciones rápidas:
- Plugin cachea redirecciones 301: solución: desactivar cacheo de redirecciones en el plugin, purgar al mismo tiempo la cache de Cloudflare y mantener Page Rule para no cachear redirecciones.
- HSTS propagado por error: solución: eliminar header Strict-Transport-Security en el origen y esperar a que expire (si se activó HSTS con long max-age, puede tardar en resolverse). No activar HSTS hasta estar completamente seguro.
- Purga en el momento de deploy: ejecutar purge por paths concretos en lugar de purga global.
Recomendaciones de flujo seguro:
- Poner Cloudflare en modo Development o pausar la cache en Page Rules antes de purgar masivamente.
- Desactivar temporalmente plugin de caché en producción si se cambian reglas SSL.
- Probar con un usuario en modo incógnito para evitar cookies cacheadas.
Conflictos entre certificado origen y Cloudflare: ¿qué hacer?
Origen CA vs Let's Encrypt (comparativa rápida):
- Origin CA (Cloudflare) genera certificados sólo válidos entre Cloudflare y el origen. Ventaja: instalación rápida, no expira públicamente. Desventaja: no válido fuera de Cloudflare.
- Let's Encrypt genera certificados válidos públicamente. Ventaja: interoperabilidad. Desventaja: renovación cada 90 días (automatizable).
Cómo elegir:
- Si todo el tráfico pasa por Cloudflare y se busca simplicidad, Origin CA + Full (strict) es la mejor opción.
- Si se necesita acceso directo al servidor desde fuera de Cloudflare o usar servicios que requieren certificado público, usar Let's Encrypt + Full (strict).
Instalación rápida de Origin CA (pasos):
- En panel Cloudflare → SSL/TLS → Origin Server → Create Certificate.
- Seleccionar un nombre común (ej: *.ejemplo.com) y generar clave privada y certificado.
- Instalar archivos en el servidor (Nginx: ssl_certificate y ssl_certificate_key) y configurar virtual host para escuchar en 443.
- En Cloudflare, seleccionar Full (strict).
Comprobaciones servidor y ejemplos de bloques de configuración:
server {
listen 443 ssl;
server_name ejemplo.com www.ejemplo.com;
ssl_certificate /etc/ssl/certs/cloudflare-origin.pem;
ssl_certificate_key /etc/ssl/private/cloudflare-origin.key;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}
- .htaccess (ejemplo mínimo para Apache):
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Puntos críticos: asegurarse de que la condición de redirección comprueba la cabecera X-Forwarded-Proto o CF-Visitor cuando Cloudflare termina la conexión.
Ejemplo para Nginx verificando X-Forwarded-Proto:
if ($http_x_forwarded_proto = 'http') {
return 301 https://$host$request_uri;
}
Si se usa Flexible, no habrá X-Forwarded-Proto = https y la lógica puede entrar en conflicto.
¿Qué plugins de caché evitan errores SSL frecuentes?
Lista y recomendaciones por plugin (ajustes concretos):
- WP Rocket: desactivar "Forzar HTTPS" y habilitar "Recrear reglas de caché" solo tras verificar SSL. Excluir URLs: /wp-admin/, /wp-login.php, /carrito/.
- W3 Total Cache: en Browser Cache desmarcar "Set HTTP Strict Transport Security" si no se está seguro; en Page Cache activar "Cache URIs with query string" con cuidado. Desactivar gzip duplicado si Cloudflare ya comprime.
- WP Super Cache: marcar "Expert" y excluir redirecciones; añadir a 'Rejected files' patrones de redirección.
- LiteSpeed Cache: habilitar "ESI" para sesiones y excluir cookies de login; activar "Private Cache" para usuarios autenticados.
Tabla comparativa simplificada:
| Plugin |
Riesgo SSL común |
Ajuste recomendado |
| WP Rocket |
Forzar HTTPS y cachear redirecciones |
Desactivar forzar HTTPS; excluir admin y checkout |
| W3 Total Cache |
Cachea encabezados HSTS y redirecciones |
No cachear redirecciones; purgar objetos tras cambios SSL |
| LiteSpeed Cache |
Cookies de sesión cacheadas |
Exclusión de cookies y ESI para sesiones |
Buenas prácticas comunes: excluir /wp-admin, /wp-login.php, endpoints de API REST (/wp-json/*) y páginas de checkout; purgar Cloudflare y plugin de caché en el orden correcto: primero plugin, luego Cloudflare.
Flujo seguro para cambiar SSL y cache en producción
🔁 Proceso mínimo recomendado
✅ Paso 1 → Validar certificado de origen (Let's Encrypt / Origin CA)
🔁 Paso 2 → En Cloudflare seleccionar Full (strict)
⚙️ Paso 3 → Excluir /wp-admin y endpoints sensibles en el plugin de caché
🧪 Paso 4 → Comprobar con curl; si OK, purgar plugin y luego Cloudflare
✅ Resultado → HTTPS estable y sin bucles
Costes ocultos de redirecciones HTTP→HTTPS mal configuradas
Impactos directos medibles:
- Latencia y Core Web Vitals: cada redirección adicional añade RTT; redirecciones mal configuradas pueden aumentar First Contentful Paint y afectar LCP.
- Crawl budget: para sitios grandes, Googlebot puede desperdiciar recursos en 301s y retrasar indexación de páginas nuevas.
- Conversión y pérdida de tráfico: redirecciones erróneas en checkout o endpoints de tracking pueden romper eventos de analytics o sesiones, generando pérdidas económicas.
- Coste técnico: tiempo de ingeniería para revertir cambios, restaurar backups y revisar logs; en entornos medianos esto puede suponer horas facturables (indicative: 2–8 horas de trabajo técnico) y costes de oportunidad.
Ejemplo estimado (indicative): en una tienda con 10.000 visitas diarias, una caída del 5% por errores de HTTPS durante 24 horas puede suponer pérdida de ventas que fácilmente supere varios cientos de euros, dependiendo del ticket medio.
Medidas para minimizar costes: pruebas en staging, activar modo Development en Cloudflare durante cambios, y comunicar ventanas de mantenimiento a stakeholders.
Análisis estratégico: la realidad de errores al configurar SSL con Cloudflare y plugins de caché: ventajas vs. desafíos
Cuándo es tu mejor opción (beneficios de alto impacto)
- Cuando se busca rendimiento y seguridad simultánea: usar Cloudflare + Full (strict) con Origin CA reduce superficie de ataque y mejora TTFB.
- Automatización y certificados gestionados facilitan operaciones en escala.
- Page Rules y Workers permiten bypass de caché en endpoints críticos sin tocar servidor.
Puntos críticos de fracaso (lo que debes vigilar antes de empezar)
- No validar certificados de origen: provoca errores 525/526 o 521.
- No excluir rutas sensibles en el plugin de caché: puede cachear páginas autenticadas o redirecciones.
- Activar HSTS sin pruebas previas: puede dejar un sitio inaccesible durante el período definido en max-age.
Lo que otros usuarios preguntan sobre errores al configurar SSL con Cloudflare y plugins de caché
Cómo evitar el error "Too Many Redirects" cuando uso Cloudflare y WP Rocket
El error aparece por un bucle entre Cloudflare (Flexible) y reglas de redirección en WP Rocket o WordPress. Solución: cambiar Cloudflare a Full (strict) con certificado en origen o desactivar la redirección dentro del plugin y usar una única fuente de redirección (preferible: servidor/Nginx).
Por qué aparece error 521 tras configurar SSL
Error 521 indica que Cloudflare no puede conectar con el servidor de origen. Causa común: firewall del host bloquea las IPs de Cloudflare o el servicio web no está escuchando en el puerto 443 con certificado válido. Revisar reglas de firewall y escuchar en 443.
Qué pasa si activo HSTS y luego hay problemas con el certificado
HSTS obliga al navegador a exigir HTTPS por el periodo indicado; si el certificado falla, los usuarios quedarán bloqueados hasta que expire el header. Precaución: activar HSTS solo después de comprobar Full (strict) y durante un periodo corto inicialmente.
Cómo comprobar si Cloudflare está terminando SSL o el origen
Usar curl y revisar cabeceras: si aparece header CF-Visitor o X-Forwarded-Proto = "https", Cloudflare está terminando la conexión. También revisar CF-Ray y el tipo de certificado presentado.
Cuál es la diferencia práctica entre Origin CA y Let's Encrypt
Origin CA solo garantiza la conexión entre Cloudflare y el servidor; Let's Encrypt es un certificado público válido para cualquier cliente. Decisión: usar Origin CA si todo pasa por Cloudflare y se busca simplicidad; usar Let's Encrypt si se necesita acceso directo al servidor.
Cómo depurar redirecciones con curl
Ejecutar: curl -I -L --max-redirs 10 -s -D - https://ejemplo.com y seguir el flujo de Location headers. Buscar patrones repetidos para identificar el origen del loop.
Siguiente pasos recomendados
- Cambiar Cloudflare a Full (strict) solo después de instalar Origin CA o Let's Encrypt en el servidor.
- Excluir /wp-admin, /wp-login.php y endpoints de API del plugin de caché y purgar primero el plugin, luego Cloudflare.
- Probar con curl y en ventana privada; si hay redirecciones, revisar .htaccess/Nginx y buscar referencias a X-Forwarded-Proto o CF-Visitor.
Acciones rápidas (3 pasos en menos de 10 minutos)
- En Cloudflare, poner sitio en modo Development o pausar cache (rápido).
- Desactivar temporalmente el plugin de caché desde WP (Plugins → desactivar).
- Ejecutar curl -I -L https://tu-dominio.com y anotar el comportamiento.
Fuentes y lecturas recomendadas: documentación oficial de Cloudflare sobre SSL/TLS (developers.cloudflare.com/ssl), guía HTTPS de WordPress (wordpress.org) y Let's Encrypt (letsencrypt.org).
