Cuando un nodo de CDN DCDN obtiene un recurso del servidor de origen, este devuelve un código de estado de respuesta. En Alibaba Cloud CDN DCDN, puede configurar una duración de caché para los códigos de estado. Si un cliente vuelve a solicitar el mismo recurso, CDN DCDN devuelve el código de estado directamente sin activar una recuperación desde el origen. Esto reduce la carga del servidor de origen. Al expirar la duración de caché configurada, se activa nuevamente una recuperación desde el origen.
Nota: Cuando esta función utiliza condiciones de regla del Rules Engine, el orden de ejecución sigue la prioridad del Rules Engine y no la prioridad propia de esta función.
Casos de uso
Utilice esta función para controlar cómo los nodos de DCDN almacenan las respuestas en caché cuando el servidor de origen devuelve códigos de estado distintos de 2xx.
De forma predeterminada, DCDN procesa las respuestas 2xx según la default cache rules and priorities of Alibaba Cloud CDN and DCDN. Si su origen devuelve con frecuencia códigos de estado distintos de 2xx, establezca un TTL para estos códigos. De este modo, los nodos de DCDN devuelven las respuestas almacenadas en caché de forma directa y reducen la carga del origen.
Ejemplo
Suponga que se elimina un archivo del servidor de origen, pero los clientes continúan solicitándolo. Cada solicitud activa una recuperación desde el origen que devuelve un código 4xx, lo cual aumenta la carga del servidor. Si configura la caché para los códigos de estado 4xx, el nodo de DCDN almacena la respuesta 4xx después de la primera recuperación. Las solicitudes posteriores dentro de la duración de caché reciben directamente la respuesta 4xx almacenada.
Reglas de caché para códigos de estado anómalos
-
Para los códigos de estado 204, 301, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503 y 504, las reglas de caché son las siguientes:
Si el servidor de origen devuelve el encabezado de respuesta
set-cookie, CDN DCDN no almacena la respuesta en caché.Si el servidor de origen no devuelve el encabezado de respuesta Set-Cookie, la respuesta se almacena en caché según el TTL de código de estado configurado en la consola de CDN DCDN. Si hay varias reglas configuradas, consulte Prioridad de múltiples reglas para conocer cómo se determina la regla efectiva.
Si el servidor de origen no devuelve el encabezado de respuesta Set-Cookie y no se configuró ningún TTL de código de estado en la consola de CDN DCDN, la respuesta se almacena en caché según el encabezado de respuesta Pragma, Cache-Control o Expires establecido por el servidor de origen.
Si el servidor de origen no devuelve los encabezados de respuesta Set-Cookie, Pragma, Cache-Control ni Expires, y no se configuró ningún TTL de código de estado en la consola de CDN DCDN, la respuesta se almacena en caché durante 1 segundo de forma predeterminada.
-
Para los códigos de estado 302, 307 y 403, las reglas de caché son las siguientes:
Si el servidor de origen devuelve el encabezado de respuesta
set-cookie, CDN DCDN no almacena la respuesta en caché.Si el servidor de origen no devuelve el encabezado de respuesta Set-Cookie, la respuesta se almacena en caché según el TTL de código de estado configurado en la consola de CDN DCDN. Si hay varias reglas configuradas, consulte Prioridad de múltiples reglas para conocer cómo se determina la regla efectiva.
Si el servidor de origen no devuelve el encabezado de respuesta Set-Cookie y no se configuró ningún TTL de código de estado en la consola de CDN DCDN, la respuesta se almacena en caché según el encabezado de respuesta Pragma, Cache-Control o Expires establecido por el servidor de origen.
Si el servidor de origen no devuelve los encabezados de respuesta Set-Cookie, Pragma, Cache-Control ni Expires, y no se configuró ningún TTL de código de estado en la consola de CDN DCDN, la respuesta no se almacena en caché.
Para el código de estado 304, CDN DCDN no almacena la respuesta en caché. La duración de caché no se puede configurar de ninguna manera.
-
Para otros códigos de estado anómalos, como el 400, las reglas de caché son las siguientes:
Si el servidor de origen devuelve el encabezado de respuesta
set-cookie, CDN DCDN no almacena la respuesta en caché.Si el servidor de origen no devuelve el encabezado de respuesta Set-Cookie, la respuesta se almacena en caché según el TTL de código de estado configurado en la consola de CDN DCDN. Si hay varias reglas configuradas, consulte Prioridad de múltiples reglas para conocer cómo se determina la regla efectiva.
En otros escenarios, la respuesta no se almacena en caché.
-
En las solicitudes que utilizan recuperación de origen por rangos, si un nodo de CDN DCDN recibe un código de estado distinto de 206 del servidor de origen, el nodo de CDN DCDN elimina los fragmentos almacenados en caché. Un tiempo de espera en la recuperación de origen no provoca la eliminación de los archivos en caché.
En una recuperación de origen por rangos, el servidor de origen divide un archivo grande en varios fragmentos más pequeños y los devuelve a los nodos de CDN DCDN. Por ejemplo, un archivo se divide en 10 fragmentos y un nodo de CDN DCDN ya tiene cinco fragmentos en caché. Cuando el nodo solicita el sexto fragmento, el servidor de origen devuelve un código de estado 5xx. En este caso, se eliminan los cinco fragmentos almacenados previamente.
Prioridad de reglas
Cuando una solicitud coincide con varias reglas de caché, solo una entra en vigor:
-
Orden de evaluación:
Las reglas se evalúan primero por tipo (File Extension > Directory) y luego por fecha de creación (más antigua > más reciente).
-
Prioridad para reglas de distintos tipos: File Extension > Directory.
Por ejemplo, si una solicitud de usuario coincide con dos reglas (ambas configuradas para el código de estado 404) de los tipos File Extension y Directory, el tiempo de caducidad para el código de estado 404 lo determina la regla File Extension. Para ver un ejemplo detallado, consulte Configuration examples.
-
Prioridad para reglas del mismo tipo: más antigua > más reciente (de arriba hacia abajo en la lista de reglas).
Por ejemplo, si una solicitud de usuario coincide con dos reglas del mismo tipo (ambas File Extension o ambas Directory) configuradas para el código de estado 404, el tiempo de caducidad para dicho código lo determina la regla creada primero. Para ver un ejemplo detallado, consulte Configuration examples.
Procedimiento
Inicie sesión en la consola de DCDN.
En el panel de navegación izquierdo, haga clic en Domain Names.
En la página Domain Names, busque el nombre de dominio que desea gestionar y haga clic en Configure en la columna Actions.
En el árbol de navegación izquierdo del nombre de dominio, haga clic en Caching.
Haga clic en la pestaña Status Codes and Expiration Time.
-
Haga clic en Add para crear una regla de caché para códigos de estado.

Tipo
Notas
Type
Seleccione un tipo: Directory o File Extension.
NotaPrioridad para reglas de distintos tipos: File Extension > Directory. Para obtener más información, consulte Rule priority.
Object
Si selecciona Directory:
Solo puede agregar un directorio a la vez.
Introduzca la ruta completa del directorio que comienza con
/; por ejemplo,/directory/aaa.
Si selecciona File Extension:
Introduzca las extensiones de archivo separadas por comas; por ejemplo,
jpg,txt.NotaLas extensiones de archivo distinguen entre mayúsculas y minúsculas. Si crea reglas para las mismas extensiones con diferente uso de mayúsculas (por ejemplo,
jpg,txtyjpg,txt), la regla posterior sobrescribe la reglajpg,txt. Cree reglas independientes paratxtyjpgpara evitar esto.No puede usar un asterisco (
*) para coincidir con todos los tipos de archivo.
HTTP Status Codes and Expiration Time
Especifique los códigos de estado que se almacenarán en caché y su TTL en segundos (máximo: 3 años):
Separe varios códigos de estado con comas (
,).Códigos 2xx y 3xx: solo códigos individuales. Por ejemplo, 201=10 es válido, pero 2xx=12 no lo es.
Códigos 4xx y 5xx: son compatibles tanto los códigos individuales como los comodines. Por ejemplo, 401=10 y 4xx=12 son válidos.
Honor Origin TTL
Cuando está habilitada, los encabezados de caché del servidor de origen (
Cache-Control,Pragma) tienen prioridad sobre el TTL configurado.Ignore Origin No-Cache Header
Cuando está habilitada, los nodos de DCDN ignoran estos encabezados de no almacenamiento en caché del origen:
Cache-Control: no-storeCache-Control: no-cacheCache-Control: max-age=0Pragma: no-cache
Follow POP TTL
Cuando está habilitada, el nodo de DCDN envía la política de caché efectiva final al cliente.
Force Revalidation
Solo entra en vigor cuando el TTL de caché se establece en 0:
Deshabilitada (predeterminada): cuando el TTL de DCDN es 0, los archivos no se almacenan en caché en los nodos de DCDN. Cada solicitud activa una recuperación desde el origen.
Habilitada: cuando el TTL de DCDN es 0, los archivos se almacenan en caché en los nodos de DCDN, pero cada solicitud activa una recuperación desde el origen para revalidarlos.
-
Haga clic en OK.
La nueva regla aparece en la lista Status Codes and Expiration Time, donde puede Modify o Delete la regla.
Ejemplos de configuración
-
Ejemplo 1: regla de tipo Directory
Cree una regla de tipo Directory como se muestra a continuación:

Para el directorio
/directory/aaa, todos los códigos 4xx se almacenan en caché durante 10 segundos y el código 201 durante 15 segundos. Dentro del TTL, DCDN responde directamente. Después de la caducidad, las solicitudes se reenvían al origen. -
Ejemplo 2: regla de tipo File Extension
Cree una regla de tipo File Extension como se muestra a continuación:

Para los archivos
.jpgy.txt, el código 403 se almacena en caché durante 10 segundos y el código 404 durante 15 segundos. Dentro del TTL, DCDN responde directamente. Después de la caducidad, las solicitudes se reenvían al origen. -
Ejemplo 3: prioridad para reglas de distintos tipos
Se crean una regla
Directoryy una reglaFile Extensioncon valores de TTL diferentes, como se muestra a continuación:
Un cliente solicita
http://example.com/directory/aaa/test.jpg. El nodo de DCDN recupera el recurso del origen, que devuelve 404. Esta solicitud coincide tanto con la reglaDirectorycomo con la reglaFile Extension. Dado que File Extension > Directory, se aplica la reglaFile Extensiony el código 404 se almacena en caché durante 20 segundos. -
Ejemplo 4: prioridad para múltiples reglas del mismo tipo
Primero se crea
Directory rule 1para/directoryy luegoDirectory rule 2para/directory/aaa, con valores de TTL diferentes, como se muestra a continuación:
Un cliente solicita
http://example.com/directory/aaa/test.jpg. El origen devuelve 404, lo cual coincide con ambasDirectory rules. Dado que más antigua > más reciente, se aplicaDirectory rule 1y el código 404 se almacena en caché durante 15 segundos.