Para omitir la caché de Edge Security Acceleration (ESA) en los recursos que coinciden con default cache rule, cree una regla para filtrar las solicitudes y establezca Cache Eligibility en Bypass Cache.
Si no se configuran reglas ni configuraciones de caché, el almacenamiento en caché en los puntos de presencia (POP) de ESA sigue default cache rule.
Escenarios
Si su servidor de origen tiene recursos que no desea almacenar en la caché de los POP de ESA, como los recursos dinámicos donde cada solicitud debe obtener el contenido más reciente del origen, configure una regla para omitir la caché en dichos recursos. Omitir la caché para los recursos dinámicos mejora el rendimiento de acceso.
Las reglas de elegibilidad de caché determinan si los nodos perimetrales de ESA almacenan una solicitud en caché. Algunos casos de uso comunes incluyen:
Almacenamiento de recursos estáticos en caché: mejore el rendimiento al almacenar imágenes, archivos CSS y JavaScript en los nodos perimetrales.
Omisión de contenido dinámico: asegúrese de que las páginas de inicio de sesión, las API y el contenido personalizado no se almacenen en caché.
Separación de contenido dinámico y estático: almacene los recursos estáticos en caché y envíe las solicitudes dinámicas directamente al servidor de origen.
Exclusión selectiva de caché: evite que archivos o rutas específicas se almacenen en caché.
Procedimiento
En la consola de ESA, elija Websites. En la columna Website, haga clic en el sitio de destino.
En el panel de navegación izquierdo, elija .
Haga clic en Create Rule e introduzca un valor en Rule Name.
En la sección If requests match..., establezca los atributos de solicitud que deben coincidir. Para obtener más información sobre cómo configurar reglas, consulte Composition of a rule expression.
-
En el área Cache Eligibility , seleccione una política de caché y haga clic en OK.
Bypass Cache: todas las solicitudes omiten la caché del POP y obtienen el contenido directamente del origen. Esto le permite consultar los recursos más recientes del servidor de origen en tiempo real. When enabled, only the Browser Cache TTL setting applies.
Eligible for Cache: todas las solicitudes elegibles se atienden desde los nodos de caché del POP en lugar del origen. Así se evitan rutas largas hacia el origen, se reduce la latencia y mejora el rendimiento de acceso.
Opciones y limitaciones de elegibilidad de caché
Bypass Cache
Cuando se selecciona Bypass Cache:
Las solicitudes coincidentes se reenvían directamente al servidor de origen sin almacenarse en los nodos perimetrales de ESA.
Solo entra en vigor la configuración de Browser Cache TTL. Las demás funciones relacionadas con la caché (como Cache Deception Defense y Serve Stale Content) se deshabilitan para esta regla.
ESA no admite configurar el comportamiento de omisión de caché mediante encabezados de respuesta HTTP (como
X-Fallback) ni marcadores de comentarios HTML. Utilice condiciones de coincidencia basadas en encabezados de solicitud o en URL.
Comportamiento predeterminado de la caché
Cuando no hay reglas de caché configuradas o ninguna regla coincide con una solicitud, ESA aplica el siguiente comportamiento predeterminado:
Las solicitudes siguen la política de caché predeterminada de ESA.
Las solicitudes dinámicas con URL que terminan en
/se reenvían al servidor de origen de forma predeterminada.Cuando el servidor de origen devuelve un encabezado de respuesta
no-cache, la respuesta no se almacena en caché.
Funciones avanzadas de caché
Las siguientes funciones están deshabilitadas de forma predeterminada y deben habilitarse manualmente en una regla de caché:
Cache Deception Defense: protege contra ataques de engaño de caché.
Serve Stale Content: permite que ESA entregue contenido obsoleto almacenado en caché cuando el origen no está disponible temporalmente.
Ejemplos comunes de configuración
A continuación se presentan escenarios frecuentes para configurar la elegibilidad de caché.
Ejemplo 1: omitir la caché para API dinámicas
Escenario: evitar que los endpoints de API dinámicos se almacenen en caché en los nodos perimetrales.
Configuración:
Condición de coincidencia: la ruta de la URL contiene
/api, O la ruta de la URL contiene/prod-api/, O la extensión del archivo es igual aphpElegibilidad de caché: Bypass Cache
Al especificar extensiones de archivo, no incluya el punto. Introduzca php, no .php.
Ejemplo 2: omitir la caché para páginas de administración e inicio de sesión
Escenario: evitar que se almacenen en caché las páginas de administración de WordPress, las interfaces de gestión de CMS o los endpoints de inicio de sesión.
Configuración:
Condición de coincidencia: la ruta de la URL contiene
/wp-admin, O la ruta de la URL contiene/admin, O la ruta de la URL contiene/loginElegibilidad de caché: Bypass Cache
Coloque esta regla al principio de la lista para garantizar que tenga prioridad sobre las reglas generales de almacenamiento de recursos estáticos.
Ejemplo 3: almacenar en caché la ruta raíz de una SPA
Escenario: de forma predeterminada, ESA no almacena en caché las URL sin extensión (como /). Para almacenar contenido text/html en aplicaciones de una sola página (SPA):
Configuración:
Condición de coincidencia: el encabezado de solicitud
Acceptcontienetext/htmlElegibilidad de caché: Eligible for Cache
TTL de caché: establézcalo según la frecuencia de actualización de su SPA.
Ejemplo 4: omitir la caché para archivos específicos
Escenario: evitar que archivos específicos, como sitemap.xml, se almacenen en caché.
Configuración:
Condición de coincidencia: la ruta de la URL contiene
sitemap(sin la extensión del archivo), O la extensión del archivo es igual axml(introduzcaxml, no.xml)Elegibilidad de caché: Bypass Cache
Ejemplo 5: separación de contenido dinámico y estático
Escenario: almacenar los recursos estáticos en caché y asegurar que las solicitudes dinámicas se reenvíen al origen.
Enfoque recomendado:
Elimine cualquier regla de caché existente para todo el sitio.
Cree una regla para almacenar recursos estáticos. Por ejemplo, configure la condición donde la extensión del archivo es igual a
jpg,png,cssojs.Cree una regla independiente para omitir la caché en los endpoints de API dinámicos. Por ejemplo, configure la condición donde la ruta de la URL contiene
/api.
Este enfoque evita que las solicitudes dinámicas se almacenen en caché por accidente.
Notas de configuración
Un TTL de caché por regla: una sola regla de caché solo define un TTL de caché. Si distintas extensiones de archivo o directorios requieren duraciones diferentes, cree una regla independiente para cada caso.
Independencia de las reglas: deshabilitar o eliminar una regla de caché específica no afecta el comportamiento de caché de otros recursos. ESA continúa evaluando las reglas restantes en orden.
Reducción de la carga del origen: configure reglas para omitir la caché en el contenido dinámico y habilite reglas de caché para los recursos estáticos. Así minimizará las solicitudes que se reenvían al servidor de origen.
Prioridad de aplicación de submódulos: en la función @xref node="4727152" Cache Rules @/xref, la prioridad de aplicación de los submódulos, de mayor a menor, es: POST Cache > Bypass Cache > Otros submódulos. Cuando POST Cache está habilitado, las solicitudes se procesan mediante el flujo de trabajo de almacenamiento de recursos estáticos en caché, por lo que la función Bypass Cache deja de tener efecto.
Preguntas frecuentes
¿Por qué mi regla para omitir la caché no surte efecto?
Compruebe lo siguiente:
-
Condición de coincidencia incorrecta: compruebe la expresión de la regla. Los errores más comunes incluyen:
Una condición OR que hace coincidir solicitudes de otros dominios de forma involuntaria.
Valores de extensión de archivo o de ruta con formato incorrecto. Por ejemplo, usar
.phpen lugar dephp.
Características de solicitud faltantes: si la regla depende de un encabezado de solicitud específico (como
sec-fetch-site), confirme que las solicitudes reales del cliente incluyan este encabezado.Prioridad de regla insuficiente: ESA evalúa las reglas de arriba hacia abajo. Si la regla para omitir la caché está ubicada debajo de una regla de caché con un TTL largo, es posible que la regla anterior coincida primero. Mueva la regla de omisión de caché a una posición superior en la lista.
La caché no se vació después de modificar la regla: tras modificar las reglas, vacíe las URL o directorios afectados en la consola de ESA. Actualizar el navegador no invalida el contenido almacenado en los nodos perimetrales.
Limitaciones del plan: es posible que Free Edition no garantice una aplicación consistente de las reglas. Considere actualizar a un plan de pago.
Método de comprobación: revise el encabezado de respuesta
Serverpara confirmar si los nodos perimetrales de ESA están procesando las solicitudes. Use una ventana de incógnito del navegador para descartar interferencias de la caché local.
¿Por qué no puedo iniciar sesión o por qué las páginas redirigen de forma incorrecta después de habilitar ESA?
Causa: esto suele ocurrir cuando una regla de caché para todo el sitio, o una regla mal configurada, provoca que las cookies de inicio de sesión, los datos de sesión o las respuestas de API dinámicas se almacenen en caché en los nodos perimetrales de ESA.
Solución:
Suspenda o elimine cualquier regla de caché sospechosa para todo el sitio.
Cree reglas Bypass Cache específicamente para las páginas de inicio de sesión, los endpoints de CAPTCHA y las rutas de administración. Coloque estas reglas al principio de la lista para darles la máxima prioridad.
En la consola de ESA, vacíe la caché de las URL afectadas.
Compruebe la solución mediante una ventana de incógnito del navegador.
Si el problema persiste después de configurar correctamente las reglas: revise la lógica de negocio de su servidor de origen. Por ejemplo, compruebe que la lógica de redirección 302 identifique correctamente el estado de inicio de sesión. Si el servidor de origen no gestiona bien dicho estado, el problema queda fuera del alcance de ESA.
¿Cuál es la diferencia entre "equals" y "contains" en las condiciones de coincidencia?
|
Tipo de coincidencia |
Comportamiento |
|
Equals |
Coincidencia exacta de la ruta de URL especificada. También coincide automáticamente con todas las subrutas. Por ejemplo, si configura |
|
Contains |
Coincidencia parcial. Coincide con cualquier URL que incluya la cadena especificada en cualquier parte. |
Para la coincidencia de nombres de host, tanto Equals como Contains producen resultados equivalentes y pueden usarse indistintamente.
¿Por qué las pruebas funcionan al habilitar las reglas de caché, pero generan tiempos de espera al deshabilitarlas?
Cuando las reglas de caché están activas, los nodos perimetrales de ESA atienden las solicitudes directamente desde la caché, lo que reduce la carga del servidor de origen.
Cuando las reglas de caché están deshabilitadas, todas las solicitudes —incluidas las dinámicas de alto volumen— llegan directamente al servidor de origen en tiempo real. Durante pruebas de carga con alta concurrencia, esto puede saturar el servidor de origen y provocar tiempos de espera en las solicitudes.
Este comportamiento refleja un cuello de botella en el rendimiento del servidor de origen, no un problema de ESA. Para solucionarlo:
Configure reglas de caché para reducir el volumen de solicitudes que se reenvían al origen.
Habilite JS Challenge o Intelligent Rate Limiting para proteger el servidor de origen frente a un exceso de solicitudes concurrentes.
Documentación relacionada
Las funciones relacionadas con reglas varían en cuanto a prioridad efectiva, reentrancia y granularidad. Para obtener más detalles, consulte Characteristics of rule-based features.