Cómo configurar reglas de caché de Cloudflare sin exponer páginas privadas

La caché es más segura cuando es aburrida. Las hojas de estilo, las imágenes y los scripts estáticos suelen beneficiarse de la reutilización; las pantallas de inicio de sesión, los carritos, las páginas de cuenta y las vistas previas a menudo no pueden tratarse igual. Una única regla amplia de «almacenar todo en caché» puede producir una página rápida y, al mismo tiempo, entregar a un visitante una respuesta destinada a otra persona. Antes de optimizar la velocidad, traza el límite entre el contenido público y el personalizado.

La documentación de Cloudflare sobre la caché predeterminada indica que el servicio suele almacenar en caché determinadas extensiones de archivo y que no almacena HTML ni JSON de forma predeterminada. También explica cómo influyen en la admisibilidad las cabeceras de caché del servidor de origen y las características de la respuesta HTTP. Una regla personalizada puede cambiar estos supuestos. Por eso es arriesgado copiar una regla agresiva de un tutorial.

Clasifica las rutas por audiencia y estado

Divide las URL en recursos estáticos públicos, HTML público anónimo, páginas que varían según las cookies o el estado de inicio de sesión, administración, API y endpoints impredecibles. Marca de forma explícita los enlaces de vista previa, los pasos del proceso de pago, las acciones de comentarios y el contenido protegido con contraseña. Si una página depende de la identidad del visitante, la decisión inicial más segura es omitir la caché compartida hasta que la aplicación se haya diseñado para ello.

Revisa cómo envía el servidor de origen las cabeceras Cache-Control, Set-Cookie y Vary. Una página anónima puede establecer una cookie inofensiva, mientras que una página personalizada puede no enviar una cabecera de protección. Probar la respuesta real es más fiable que suponer el comportamiento a partir de la ruta de la URL.

Crea reglas específicas antes que reglas amplias

En el panel de Cloudflare, las Cache Rules permiten elegir una expresión de coincidencia y después omitir la caché o hacer que las solicitudes coincidentes puedan almacenarse en caché. La guía de creación de reglas explica paso a paso el orden de las reglas y su despliegue. Empieza con una prueba restrictiva dirigida al contenido público, en lugar de a todas las solicitudes del nombre de host.

Ten en cuenta el orden de las reglas y sus solapamientos. Una regla de omisión que cubre las rutas de inicio de sesión no debe quedar anulada sin querer por una coincidencia amplia posterior. Prueba variantes de parámetros, rutas de idioma, contenido específico de cada dispositivo y estados de cookies. Si modificas las claves de caché, verifica que las variantes de contenido producen realmente claves distintas.

Ten cuidado con la anulación del TTL en el borde

Un Edge Cache TTL puede cambiar el tiempo durante el que Cloudflare conserva una respuesta y, según la configuración, puede anular las instrucciones del servidor de origen. La documentación de los ajustes disponibles explica las opciones y advierte de que el comportamiento interactúa con las cabeceras y con otras configuraciones. No establezcas un TTL compartido largo para HTML que no puedas invalidar de forma segura.

Elige un procedimiento de purga antes del despliegue. Los editores necesitan que las actualizaciones y las correcciones aparezcan rápidamente. Un titular erróneo conservado en el borde puede seguir siendo visible después de corregirse en el CMS, a menos que la invalidación de la caché llegue a las variantes correspondientes.

Haz una prueba anónima frente a una autenticada

Visita un artículo público sin cookies y después con una sesión autenticada normal. Revisa la respuesta de red y las cabeceras de estado de la caché. Repite la prueba con cuentas de prueba distintas en un entorno seguro. Confirma que los nombres privados, los tokens, los carritos y la navegación específica de cada usuario nunca pasan de una cuenta a otra. Prueba también las redirecciones y las páginas de error. Un HIT no demuestra que una regla de caché sea correcta; la corrección es lo primero.

Mantén un breve inventario de reglas con el motivo de cada excepción, la persona que la aprobó y una URL de prueba que se sepa segura. Una regla sin explicación heredada de un despliegue anterior no debe permanecer indefinidamente solo porque nadie sepa qué hace. Revisa los cambios de caché junto con las versiones que afecten a la autenticación y al proceso de pago.

Después del despliegue, supervisa la carga del servidor de origen, las tasas de aciertos de caché, el contenido obsoleto y las tasas de error. Ten preparadas las reglas anteriores al cambio para poder revertirlo. Cuando no esté clara la corrección, omite la caché y arregla el contrato de la aplicación antes de intentar otra optimización.

Una ruta puede parecer pública y, sin embargo, variar de forma invisible según las cabeceras de la solicitud, el país, el dispositivo o una prueba A/B. Si almacenas en caché una única representación para todos, el idioma o la variante equivocados pueden llegar a la persona equivocada. Antes de diseñar una clave de caché personalizada, identifica con precisión qué dato de entrada modifica la respuesta HTML. Cloudflare documenta opciones para cadenas de consulta, cabeceras y cookies, pero añadir todas las cabeceras a una clave puede destruir la eficiencia de la caché y crear combinaciones impredecibles.

Prueba tres estados distintos para cada ruta importante: primera visita sin cookies, visita anónima repetida y visita autenticada. Registra el código de estado de la respuesta, Cache-Control, Set-Cookie, CF-Cache-Status cuando esté disponible y una breve huella del contenido visible. Repite la prueba después de una corrección editorial y de una purga selectiva. Se trata de un método de control de calidad hipotético, no de una afirmación sobre la configuración de un sitio concreto.

Ten especial cuidado con las páginas de error y las redirecciones. Almacenar en caché de forma demasiado amplia una respuesta temporal de mantenimiento, una redirección de autenticación o un destino localizado puede parecer una caída del sitio aunque el servidor de origen funcione correctamente. Despliega las reglas primero en un patrón de rutas reducido y pruébalas en un nombre de host seguro cuando sea posible. Si los síntomas son ambiguos, vuelve al comportamiento predeterminado e investiga antes de ampliar la admisibilidad.

Mantén la velocidad sin perder la confianza

La caché de recursos estáticos suele aportar mejoras útiles sin tocar el HTML personalizado. Haz los cambios de una clase de rutas cada vez, anota las excepciones y vuelve a verificar después de las actualizaciones del CMS o de la autenticación. Nuestra noticia sobre la actualización de seguridad de Cloudflare trata una cuestión de protección distinta; la guía de entornos de prueba para WordPress aborda cómo probar los cambios antes de pasarlos a producción. Las páginas rápidas solo tienen valor si muestran el contenido correcto.