Por qué dos ajustes lo deciden todo
Cloudflare se conecta en unos clics, y por eso mismo se deja tal cual. Sin embargo, dos fallos cuestan un cliente. El primero afecta al cifrado: en modo Flexible, Cloudflare habla en HTTP sin cifrar con el origen; si el origen ya redirige todo a HTTPS, la petición entra en bucle y el navegador muestra ERR_TOO_MANY_REDIRECTS. El segundo afecta a la caché: en cuanto una regla demasiado amplia hace elegible el HTML, una página personalizada puede servirse a otro visitante. La respuesta no es desactivar Cloudflare, sino repartir los papeles. La agencia lleva la relación con el cliente y los ajustes de la zona; el alojamiento lleva el origen, es decir, un certificado válido, las redirecciones y las cabeceras de caché.
Lo que esta configuración estándar le evita
- Bucle de redirección — el modo Flexible combinado con una redirección de HTTP a HTTPS en el origen, que el navegador señala como ERR_TOO_MANY_REDIRECTS.
- Página con sesión servida a otro visitante — una regla de «cachear todo» sin excepción para el carrito, la cuenta o la administración.
- Administración congelada — el panel muestra una versión antigua porque se conservó una respuesta dinámica.
- Errores 525 y 526 — el handshake TLS falla o el certificado de origen no supera la validación en cuanto pasa a Full o Full (strict).
- Cifrado de fachada — en Flexible, el visitante ve el candado mientras el tramo entre Cloudflare y el origen circula sin cifrar.
- Ajustes distintos en cada sitio — una única lista de pasos sustituye las decisiones caso por caso y, por tanto, los olvidos.
Requisitos que comprobar antes de tocar la zona
Cuatro puntos, ninguno se adivina. Un certificado válido en el origen: no caducado, no revocado, emitido para el nombre del sitio, con la cadena completa (certificado final e intermedios). La documentación de Cloudflare acepta un certificado de una autoridad pública como Let's Encrypt, o un certificado Cloudflare Origin CA, que solo vale mientras el registro siga con proxy. El puerto 443 abierto hacia el origen, con SNI compatible. Acceso a la zona DNS del cliente. Y por último, la lista de URL dinámicas del sitio: administración, carrito, pago, cuenta.
En un alojamiento ServOrbit, el certificado SSL Let's Encrypt está incluido, con renovación automática: el origen cumple así el primer punto, y el modo Full (strict) pasa a ser posible. La comprobación de la renovación tras el proxy figura en el último paso.
Los modos SSL/TLS de Cloudflare, de Off a Full (strict)
Desplace la tabla
| Modo | Entre Cloudflare y el origen | Veredicto para el sitio de un cliente |
|---|---|---|
| Off | Todo circula en HTTP sin cifrar, en ambos tramos. | Descartarlo. |
| Flexible | El visitante puede usar HTTPS; el tramo de Cloudflare al origen no está cifrado. | Solución temporal. Bucle asegurado si el origen redirige a HTTPS. |
| Full | HTTPS hacia el origen, sin validar el certificado: se acepta uno autofirmado o no válido. | Paso de transición mientras corrige el certificado. |
| Full (strict) | HTTPS con validación del certificado de origen (autoridad pública u Origin CA). | Objetivo estándar de todos sus sitios. |
| Automatic SSL/TLS | El recomendador elige el modo más seguro que admite el origen y nunca uno menos seguro. | Ajuste por defecto: fije igualmente el modo de forma explícita para saber qué se aplica. |
Orden de operaciones sin cortes
Compruebe el certificado del origen
Desde su equipo, consulte el origen directamente con su dirección (IP_ORIGINE es una plantilla que debe sustituir):
openssl s_client -connect IP_ORIGINE:443 -servername example.com </dev/null | openssl x509 -noout -subject -datesEl sujeto debe llevar el nombre del sitio y las fechas deben abarcar hoy. Complételo con
curl -sI --resolve example.com:443:IP_ORIGINE https://example.com/: una respuesta HTTP válida demuestra que el certificado se acepta.Anote las redirecciones del origen
Pruebe el puerto 80 del origen:
curl -sI --resolve example.com:80:IP_ORIGINE http://example.com/. Si la respuesta contiene una cabecera Location hacia https://, el origen redirige todo a HTTPS. Es la causa del bucle en modo Flexible, y no es un defecto: es un buen ajuste de origen.Mantenga el registro en solo DNS
Mientras las dos comprobaciones anteriores no estén en verde, el proxy sigue desactivado en el registro. El tráfico va directo al origen, como antes.
Pase el modo SSL/TLS a Full (strict)
En el panel de la zona, abra SSL/TLS, Overview y elija el modo personalizado Full (strict). Mientras el registro no tenga proxy, nada cambia para el visitante.
Active el proxy en último lugar
Pase el registro A, AAAA o CNAME del sitio a modo con proxy. El gesto, registro por registro, se describe en Activar o desactivar el proxy de Cloudflare en un registro DNS.
Imponga HTTPS en el borde
Una vez en Full (strict), active «Always Use HTTPS» o una regla de redirección del lado de Cloudflare, y retire si es posible la redirección del origen: la documentación de Cloudflare cita esta opción entre los remedios del bucle.
Compruebe el resultado
Ejecute
curl -sI https://example.com/: espera una respuesta 200 o la redirección prevista, y la cabecera server: cloudflare. Compruebe también que la renovación del certificado de origen sigue funcionando tras el proxy: el alojamiento documenta la renovación automática, no su comportamiento detrás de Cloudflare. Vuelva a leer la fecha de fin del certificado con el paso 1 tras la próxima renovación, y vuelva a Full si el certificado caduca. Pase después a la sección de caché antes de dar el sitio por entregado.
Qué guarda Cloudflare en caché por defecto y dónde aparece el riesgo
Cloudflare decide la caché según la extensión del archivo, no según su tipo MIME: archivos comprimidos, imágenes, vídeo, fuentes, documentos, hojas CSS y scripts JS son elegibles. La documentación precisa que el CDN no cachea HTML ni JSON por defecto. Añade que no conserva una respuesta acompañada de una cabecera Set-Cookie, ni una respuesta cuyo Cache-Control sea private, no-store, no-cache o max-age=0, ni una petición que no sea GET. El riesgo aparece, por tanto, el día en que alguien añade una regla de caché sobre todo el sitio. Esa regla hace elegible el HTML y, si el origen no indica nada, una página de carrito o de cuenta puede acabar en la caché.
Rutas que nunca deben quedar en caché en un sitio dinámico
- Administración e inicio de sesión —
/wp-adminy/wp-login.phpen WordPress, o el equivalente de su CMS. - Carrito y pago —
/cart,/checkouty sus variantes traducidas en una tienda WooCommerce. - Cuenta de cliente —
/my-accounty toda página que muestre datos propios del visitante. - Cookies de sesión — por ejemplo
wordpress_logged_in_owoocommerce_items_in_cart: una petición que las lleve debe llegar siempre al origen. - Vistas previas — las URL con
?preview=true, que solo debe ver el autor con sesión iniciada. - API autenticadas —
/wp-jsoncuando la respuesta depende del usuario conectado.
Crear la regla de omisión con Cache Rules
Abra Cache Rules
En la zona, abra Caching y después Cache Rules, y cree una regla. Las Cache Rules exigen que el registro del dominio o subdominio tenga proxy.
Escriba el filtro
Elija Edit expression e introduzca, adaptándola a su CMS:
(http.request.uri.path contains "/wp-admin") or (http.request.uri.path contains "/wp-login.php") or (http.request.uri.path contains "/cart") or (http.cookie contains "wordpress_logged_in_")Elija Bypass cache
En «Then», dentro de Cache eligibility, seleccione Bypass cache: las peticiones que coincidan dejan de ser elegibles para la caché.
Coloque y pruebe la regla
Elija su posición con «Place at», guarde y use el Rules simulator de Cloudflare para comprobar que la regla se activa en una URL de administración o de carrito.
Verificar la caché realmente aplicada
Una regla bien escrita no prueba nada mientras no se haya leído la respuesta. La cabecera cf-cache-status indica lo que Cloudflare hizo con cada petición. Para la administración: curl -sI https://example.com/wp-admin/ | grep -i cf-cache-status. Para una página con una cookie de sesión simulada: curl -sI -H "Cookie: wordpress_logged_in_test=1" https://example.com/ | grep -i cf-cache-status. En estas dos URL el valor nunca debe ser HIT. Pruebe también una página pública dos veces seguidas, para ver pasar un MISS y luego un HIT si decidió cachearla.
Leer los valores de cf-cache-status
- HIT — el recurso se encontró en la caché de Cloudflare y se sirvió desde ella.
- MISS — la respuesta era elegible, pero no estaba en la caché en ese momento: la sirvió el origen.
- EXPIRED — existía una copia, pero estaba caducada; el origen sirvió una respuesta nueva.
- BYPASS — la petición podía cachearse, pero la respuesta del origen resultó no serlo.
- DYNAMIC — Cloudflare juzgó al recibir la petición que el recurso no es elegible y consultó el origen directamente.
- REVALIDATED — el origen confirmó mediante una petición condicional que la copia en caché seguía siendo válida.
- STALE — se sirvió una copia caducada porque no se pudo contactar con el origen.
Solución de problemas: los errores que reaparecen
Cinco síntomas cubren la mayoría de las llamadas de clientes tras poner un sitio detrás de Cloudflare. Para cada uno, la documentación de Cloudflare describe la causa; la corrección casi siempre está en el origen, es decir, en el alojamiento, o en el modo SSL/TLS de la zona.
- ERR_TOO_MANY_REDIRECTS (Chrome), «La página no redirige correctamente» (Firefox) — causa: modo Flexible y origen que redirige de HTTP a HTTPS. Remedio: pasar a Full o Full (strict), lo que exige un certificado de origen, o retirar la redirección del origen e imponer HTTPS en el borde. Revise también «Always Use HTTPS», HSTS y las reglas de redirección que se contradicen.
- Error 525, SSL handshake failed — el handshake TLS falla con la zona en Full o Full (strict). Causas citadas: ningún certificado válido instalado, puerto 443 cerrado, SNI no compatible, suites de cifrado incompatibles. Remedio: repetir el paso 1 y consultar el registro de errores de nginx o Apache del origen.
- Error 526, invalid SSL certificate — en Full (strict), Cloudflare no puede validar el certificado de origen: caducado, revocado, nombre incorrecto o cadena incompleta, ya que el origen debe servir el certificado final y los intermedios. Solución provisional: Full, mientras lo corrige.
- Errores 521 y 522, web server is down y connection timed out — no son errores de certificado: el origen está caído o no responde a tiempo. Revise el cortafuegos del origen y facilite al alojamiento el código, la hora con su zona horaria y la URL afectada.
- Carrito o cuenta de un visitante visto por otro — una regla de caché demasiado amplia. Desactívela, añada la regla de omisión, purgue la caché y vuelva a leer cf-cache-status en las rutas sensibles.
La vuelta atrás, antes de que se la pidan
Anote el estado inicial: modo SSL/TLS, registros con proxy, reglas existentes. Si el sitio se degrada tras el cambio, devuelva el registro a solo DNS: el tráfico vuelve directo al origen. Una trampa: un certificado Cloudflare Origin CA solo lo reconoce Cloudflare, y la documentación advierte de que al cortar el proxy el visitante ve un error de certificado no confiable. Conserve, por tanto, un certificado de una autoridad pública en el origen.
Quién lleva qué y por dónde seguir
Una vez rodada, la lista cabe en una página por sitio: certificado comprobado, Full (strict), proxy activado, regla de omisión probada, cf-cache-status releído. El reparto sigue siendo simple: a la agencia, la zona del cliente y sus ajustes; al alojamiento, el origen. Para las tareas vecinas, consulte Activar el DNS gestionado de Cloudflare en un dominio y Migrar el WordPress de un cliente sin cortes si el sitio cambia de origen antes de ponerse detrás de Cloudflare.
