CDN:Cache troubleshooting

Pasos para la solución de problemas:

1. Confirme que la configuración haya surtido efecto: Después de agregar o modificar una regla de caché, el estado de la regla muestra Configuring, lo que significa que la configuración se está entregando a los POPs de todo el mundo. El estado generalmente cambia a Success en unos pocos minutos. No se apresure a verificar la regla antes de que la configuración surta efecto.

2. Confirme que la nueva regla aplique al recurso objetivo: Una nueva regla solo se aplica a solicitudes nuevas. Los recursos ya almacenados en caché en los POPs continúan sirviéndose bajo la política anterior hasta que expiren. Para aplicar la regla inmediatamente, primero borre la caché anterior mediante Refresh and prefetch.

3. Verifique la prioridad de coincidencia de reglas: Cuando una solicitud coincide con varias reglas, solo una surte efecto. De forma predeterminada, la regla con mayor peso tiene prioridad. Cuando los pesos son iguales, la regla creada posteriormente suele tener prioridad (consulte la descripción real en la consola). Asegúrese de que la regla coincidente con la ruta objetivo tenga el peso más alto. Por ejemplo, el peso de un directorio específico (/static/) debe ser mayor que el del directorio raíz (/).

4. Compruebe si los encabezados de respuesta del origen prohíben el almacenamiento en caché: Si el servidor de origen devuelve Cache-Control: no-cache, no-store, max-age=0 o Pragma: no-cache, CDN sigue la directiva del origen de forma predeterminada. Para conocer el impacto de las diferentes directivas en el comportamiento de solicitud al origen, consulte la siguiente tabla. Puede habilitar Ignore no-cache headers from the origin server en la regla de caché para forzar el almacenamiento en caché según las reglas de la consola, o ajustar la configuración del servidor de origen para eliminar las directivas no-cache para recursos estáticos.

5. Verifique cómo se procesan los parámetros de URL: Si la URL contiene parámetros y Ignore parameters está deshabilitado, las URLs con diferentes parámetros se tratan como recursos distintos, lo que reduce la proporción de aciertos de caché. Puede habilitar Ignore parameters o Retain specified parameters.

6. Compruebe si el directorio raíz está mal configurado como no almacenable en caché: Si la regla para el directorio raíz / tiene el peso más alto y un tiempo de expiración de 0 segundos, todas las solicitudes desencadenarán peticiones al origen.

En el paso 4 anterior, las diferentes directivas no-cache del servidor de origen tienen impactos significativamente distintos en el comportamiento de solicitud al origen. Evalúe la carga en el servidor de origen según la directiva real:

Encabezado de respuesta del origen	Comportamiento de CDN	Impacto en el servidor de origen
Cache-Control: no-store	El almacenamiento en caché está completamente prohibido. Cada solicitud obtiene el recurso completo del servidor de origen.	El servidor de origen soporta toda la presión del tráfico.
Cache-Control: no-cache o max-age=0	Los POPs pueden almacenar copias en caché, pero deben revalidarlas con el servidor de origen antes de cada uso. Cuando la validación es exitosa, el servidor de origen devuelve 304 (sin cuerpo de respuesta), y la sobrecarga es mucho menor que una solicitud completa al origen.	El número de solicitudes al origen no disminuye, pero cada solicitud es solo una pequeña petición condicional, por lo que la presión sobre el ancho de banda es manejable.
Pragma: no-cache	Una directiva de compatibilidad HTTP/1.0. El efecto es similar a no-cache.	Igual que el anterior.

El propósito de establecer el tiempo de expiración en 0 es hacer que cada solicitud obtenga el contenido más reciente del servidor de origen. Si todavía se devuelve contenido anterior, solucione el problema de la siguiente manera:

1. Descarte la caché local del navegador: Borre la caché del navegador o use el modo de navegación privada para probar nuevamente, y confirme que es el POP y no el navegador quien devuelve el contenido anterior.

2. Borre la caché que existía antes del cambio de configuración: Los recursos almacenados en caché antes de modificar la configuración no se borran automáticamente. Envíe una tarea de actualización de URL mediante Refresh and prefetch.

3. Compruebe si el servidor de origen tiene su propia caché: El servidor de origen (por ejemplo, una caché de Nginx o una caché de capa de aplicación) puede devolver contenido anterior, por lo que CDN obtiene datos obsoletos durante la solicitud al origen.

4. Confirme que la configuración haya surtido efecto a nivel mundial: El estado de la regla debe ser Success. La entrega de la configuración a todos los POPs tarda unos minutos.

5. Confirme que la solicitud llega al POP esperado: Los usuarios de diferentes ISP o en diferentes regiones pueden llegar a distintos POPs. Realice pruebas en varias regiones por separado, o utilice los registros en tiempo real de CDN y la IP del POP en la respuesta para identificar mejor el problema.

1. Verifique la integridad de la configuración: Una clave de caché personalizada generalmente requiere establecer condiciones de regla basadas en características de la solicitud (como User-Agent) y luego agregar diferentes variables de clave de caché a cada regla. Confirme que las características de solicitud de los clientes de celular y PC se identifiquen correctamente, y que las condiciones de coincidencia de las dos reglas no se superpongan entre sí.

2. Espere a que la configuración surta efecto: Después de enviar la configuración, espere de 5 a 10 minutos para que se sincronice a nivel mundial.

3. Actualice la caché anterior: Los recursos almacenados en caché bajo la clave de caché anterior antes del cambio de configuración no expiran automáticamente. Envíe una tarea de actualización (se recomienda utilizar la actualización de directorio).

4. Verifique en el cliente: Borre la caché del navegador y vuelva a intentar, y compruebe si X-Cache en los encabezados de respuesta es MISS.

5. Pruebe con dispositivos reales: Envíe solicitudes utilizando el User-Agent real de diferentes dispositivos en lugar de solo cambiar el tamaño de la ventana del navegador (el User-Agent emulado por un navegador puede diferir del de un dispositivo real).

Causa: Cuando la respuesta del origen contiene el encabezado de respuesta Set-Cookie, CDN no almacena la respuesta en caché de forma predeterminada, lo que resulta en una proporción de aciertos de caché de 0.

Soluciones recomendadas (en orden de prioridad):

• Corrija en el lado del origen (recomendado): Haga que el servidor de origen deje de devolver Set-Cookie para recursos estáticos como imágenes, CSS, JavaScript y fuentes. Esta es la solución fundamental. No afecta la gestión de sesiones de los endpoints dinámicos y mejora la proporción de aciertos de caché.

• Elimínelo por ruta en el lado de CDN: Si no se puede ajustar el servidor de origen, elimine este encabezado de respuesta en el lado de CDN solo para rutas de recursos estáticos como /static/, *.css y *.js para evitar afectar los endpoints dinámicos.

Pasos para eliminar el encabezado por ruta en el lado de CDN:

1. Inicie sesión en la consola de CDN. En la página Domain Names, busque el nombre de dominio objetivo y haga clic en Manage.

2. En el panel de navegación izquierdo de la página de detalles del dominio, haga clic en Origin Settings y vaya a la pestaña Modify incoming response headers.

3. Haga clic en Add, restrinja la condición de la regla a las rutas de recursos estáticos, seleccione Delete para la operación del encabezado de respuesta e introduzca Set-Cookie para el nombre del encabezado de respuesta.

4. Una vez completada la configuración, utilice Refresh and prefetch para borrar las respuestas anteriores almacenadas en caché de modo que la nueva regla surta efecto.

Si la proporción de aciertos de caché sigue sin mejorar después de la configuración, compruebe lo siguiente: si Ignore no-cache headers from the origin server está habilitado en las reglas de caché, y si Ignore parameters está habilitado para evitar que el mismo recurso se divida en múltiples objetos de caché debido a diferentes parámetros de consulta. Para conocer las reglas de caché predeterminadas de CDN, consulte Configure CDN cache expiration.

Una proporción baja de aciertos de caché significa que la mayoría de las solicitudes desencadenan peticiones al origen. Una ruta de red pública inestable puede degradar el efecto de aceleración y ejercer presión de carga sobre el servidor de origen. Solucione el problema de la siguiente manera:

1. Compruebe si el servidor de origen devuelve directivas no-cache: Esta es la causa más común de una proporción baja de aciertos y ancho de banda del origen saturado. Si el servidor de origen devuelve Cache-Control: no-cache, no-store, max-age=0 o Pragma: no-cache, CDN sigue la directiva del origen y no almacena el recurso en caché, por lo que cada solicitud desencadena una petición al origen. Puede habilitar Ignore no-cache headers from the origin server en la configuración de expiración de caché para forzar el almacenamiento en caché según las reglas de la consola, o ajustar la configuración del servidor de origen.

2. Compruebe si las reglas de caché están mal configuradas: Confirme que el tiempo de expiración de caché para el directorio raíz / no esté establecido en 0 segundos con el peso más alto. De lo contrario, todas las solicitudes desencadenarán peticiones al origen.

3. Verifique si las URLs contienen parámetros variables: Los parámetros cambiantes después del signo de interrogación en una URL provocan que el mismo contenido se trate como recursos diferentes. Habilitar Ignore parameters consolida dichas solicitudes en un único objeto de caché. Para obtener más información, consulte el siguiente punto.

4. Configure recursos estáticos y dinámicos por separado: Establezca una duración de caché larga (como 30 días) para recursos estáticos como imágenes, CSS, JavaScript y fuentes, y establezca el tiempo de expiración en 0 segundos para contenido dinámico como PHP, JSP y endpoints de API.

5. Habilite la solicitud al origen por rangos para archivos grandes: Para archivos grandes como videos y paquetes de instalación, asegúrese de que la solicitud al origen por rangos esté habilitada para que el POP no obtenga el archivo completo del servidor de origen en cada solicitud. Antes de habilitar esta función, confirme que el servidor de origen admite solicitudes por rangos (es decir, puede devolver 206 Partial Content). Habilitar esta función cuando el servidor de origen no admite solicitudes por rangos puede causar fallos en las solicitudes o contenido anómalo.

6. Compruebe si el QPS del negocio es demasiado bajo: El espacio en disco del POP es limitado, y los recursos a los que se accede con poca frecuencia son desalojados por los recursos populares, lo que desencadena peticiones al origen. Para nombres de dominio con solo una docena de QPS, se recomienda enviar tareas de precarga mediante Refresh and prefetch para que los recursos permanezcan residentes en los POPs.

Síntoma: La proporción general de aciertos de una página es baja. Los encabezados de respuesta muestran que X-Cache es MISS para la solicitud principal, pero HIT para archivos individuales en la página.

Causa: La URL contiene parámetros que cambian con cada solicitud, como una marca de tiempo. Cuando la función de ignorar parámetros está deshabilitada, CDN trata cada URL con diferentes parámetros como un recurso independiente y no puede reutilizar la caché. Por ejemplo, el valor después de ?_t= en http://example.com/movie/res/ArrowScene.ccbi?_t=1699999999 difiere en cada solicitud.

Solución: Habilite Ignore parameters en la consola de CDN. Después de habilitar esta función, los parámetros se excluyen del cálculo del objeto de caché, y las solicitudes para el mismo recurso con diferentes parámetros coinciden con la misma caché. Si su negocio depende de algunos parámetros, seleccione Retain specified parameters para ignorar solo los irrelevantes.

Causas comunes de fluctuaciones a corto plazo o una disminución continua en la proporción de aciertos:

• Se realizó una actualización de caché: Una actualización manual o automática borra la caché en los POPs, por lo que se espera una disminución en la proporción de aciertos dentro de un período corto. A medida que los recursos se almacenan nuevamente en caché, la proporción de aciertos generalmente se recupera automáticamente en unas pocas horas.

• Ocurrió un aumento repentino de ancho de banda: Un aumento brusco del tráfico en un período corto trae muchas solicitudes por primera vez, lo que incrementa las peticiones al origen y disminuye la proporción de aciertos.

• Se accede a una gran cantidad de contenido nuevo: Cuando los POPs solicitan frecuentemente recursos a los que se accede por primera vez, la petición al origen es inevitable y la proporción de aciertos disminuye.

• Se ajustaron las reglas de caché: Modificar la política de caché, especialmente acortar el tiempo de expiración, afecta la proporción de aciertos.

• Las URLs contienen parámetros variables: Los parámetros cambiantes dividen el mismo contenido en múltiples objetos de caché.

• El tiempo de expiración de la caché no está configurado adecuadamente: Si la configuración no diferencia los recursos por frecuencia de actualización, la caché expira demasiado pronto.

Si ha configurado encabezados de respuesta CORS en CDN pero los clientes siguen reportando errores CORS y los encabezados de respuesta no contienen el campo configurado, las posibles causas y soluciones son las siguientes:

• La configuración no ha surtido efecto: Confirme que la configuración está guardada y que el estado de la regla es Success.

• La configuración no se ha entregado completamente: Los cambios en la configuración de encabezados de respuesta salientes suelen surtir efecto en 5 minutos. Espere y vuelva a intentarlo. Esta configuración solo afecta las respuestas recibidas por los clientes, no el comportamiento de caché de los POPs, por lo que no se requiere actualización ni precarga (la precarga no cambia los encabezados de respuesta de los recursos ya almacenados en caché).

• Los encabezados de respuesta del servidor de origen entran en conflicto con la configuración de CDN: Si el servidor de origen también devuelve encabezados de respuesta CORS, los encabezados pueden anularse mutuamente. Se recomienda utilizar configuraciones CORS consistentes en el servidor de origen y CDN, o establecer Allow Duplicate en No en Modify outbound response headers para que el valor configurado en CDN anule el valor devuelto por el servidor de origen.

• El navegador almacenó en caché la respuesta anterior: Borre la caché del navegador o use el modo de navegación privada para realizar pruebas.

• No se admite la configuración de dominios comodín: Después de habilitar la validación CORS, solo puede configurar un único nombre de dominio comodín o varios nombres de dominio exactos separados por comas. No se admite separar varios nombres de dominio comodín con comas.

• El valor de Access-Control-Allow-Origin no coincide con el Origin de la solicitud: Si el navegador reporta "The 'Access-Control-Allow-Origin' header has a value that is not equal to the supplied origin", el origen permitido devuelto no coincide con el origen real de la solicitud. Puede resolver esto de las siguientes maneras:

  • En Modify outbound response headers, vuelva a configurar Access-Control-Allow-Origin y establezca Allow Duplicate en No para que el nuevo valor anule el valor anterior devuelto por el servidor de origen.

  • Si su negocio lo permite, configure este encabezado de respuesta para devolver dinámicamente el valor Origin en la solicitud, de modo que el origen permitido siempre coincida con el origen de la solicitud. Una vez completada la configuración, espere unos 5 minutos para que surta efecto. No se requiere actualización de caché.

Para saber cómo configurar el uso compartido de recursos de origen cruzado, consulte Configure cross-origin resource sharing.

• Confirme que las solicitudes pasan por los POPs de CDN: Compruebe si la resolución DNS conserva únicamente el registro CNAME proporcionado por CDN y si se han eliminado los registros de resolución directa para orígenes como OSS. Si el tráfico va directamente al servidor de origen, los encabezados de respuesta configurados en CDN no surtirán efecto.

• Confirme que configuró un encabezado de respuesta saliente en lugar de uno entrante: Los encabezados de respuesta entrantes solo aplican a la comunicación entre el servidor de origen y los POPs de CDN, y los usuarios finales no los perciben. Para afectar las respuestas que reciben los usuarios finales, configure Modify outbound response headers.

• Confirme si el servidor de origen devuelve el encabezado de respuesta: CDN transmite los encabezados de respuesta del origen de forma predeterminada. Si el servidor de origen no devuelve el encabezado, CDN tampoco lo hará. Para forzar que el encabezado de respuesta se incluya independientemente de si el servidor de origen lo devuelve, seleccione la operación Add en Modify outbound response headers.

• Si Content-Type no surte efecto, revise los metadatos en el servidor de origen: Si el servidor de origen (como OSS) no especifica el Content-Type correcto cuando se carga un archivo, los metadatos obtenidos durante la solicitud al origen no coincidirán con sus expectativas. Revise la configuración de Content-Type utilizada cuando se cargó el archivo.

• Confirme que ha esperado a que la configuración surta efecto: Los cambios en la configuración de encabezados de respuesta salientes suelen surtir efecto en 5 minutos, y solo afectan las respuestas recibidas por los clientes, no el comportamiento de caché de los POPs, por lo que no se requiere actualización ni precarga (la precarga no cambia los encabezados de respuesta de los recursos ya almacenados en caché).

Para saber cómo configurar encabezados de respuesta salientes y las descripciones de los parámetros, consulte Modify outbound response headers.

Causa: El encabezado de respuesta Content-Type devuelto por el servidor de origen no especifica correctamente la codificación de caracteres, y el cliente analiza sintácticamente el contenido con la codificación incorrecta, lo que provoca que la página muestre caracteres ilegibles.

Solución 1 (recomendada, corregir en el origen): Modifique la configuración del servidor de origen para asegurarse de que Content-Type contenga la declaración de codificación de caracteres correcta cuando se devuelve HTML.

Solución 2 (reescribir en el lado de CDN):

1. Inicie sesión en la consola de CDN. En la página Domain Names, busque el nombre de dominio objetivo y haga clic en Manage.

2. En Modify incoming response headers, agregue una regla para reescribir el Content-Type de la ruta coincidente a text/html; charset=utf-8.

3. Una vez completada la configuración, utilice Refresh and prefetch para actualizar los recursos almacenados en caché bajo esa ruta, de modo que los POPs los almacenen nuevamente con el tipo correcto.

Puede configurar el encabezado de respuesta Content-Disposition mediante la función Modify outbound response headers para controlar el comportamiento de descarga o vista previa de videos: si se establece en attachment; filename='video.mp4', se desencadena una descarga cuando un usuario accede al recurso; si se establece en inline, el recurso se previsualiza directamente en el navegador.

Si la configuración no surte efecto, compruebe los siguientes elementos:

1. La condición de coincidencia del motor de reglas: Asegúrese de que la condición de coincidencia de la regla apunte a la ruta URI (por ejemplo, que contenga /video-origin/20260414) en lugar de coincidir solo con la cadena de consulta. El motor de reglas determina si la configuración surte efecto identificando la información de ruta en la solicitud del usuario.

2. El POP almacenó en caché el encabezado de respuesta anterior: Content-Disposition afecta directamente el comportamiento del navegador. Si la configuración no surte efecto 5 minutos después de guardarla, primero descarte la caché local del navegador (vuelva a intentar en modo de navegación privada) y confirme que el estado de la regla es Success.

Causa: Cuando el servidor de origen devuelve el archivo JavaScript por primera vez, el encabezado de respuesta Content-Type se establece incorrectamente en text/html. Después de que CDN almacena en caché el tipo incorrecto, el navegador analiza sintácticamente el archivo JavaScript como text/html, lo que causa visualización con caracteres ilegibles o errores de ejecución. En la segunda visita, la página vuelve a la normalidad porque el servidor de origen corrigió el Content-Type o CDN obtuvo el tipo correcto del servidor de origen nuevamente.

Solución:

1. En Modify incoming response headers en la consola de CDN, agregue una regla para coincidir con la ruta del archivo JavaScript (como *.js) y reemplace forzosamente el Content-Type con application/javascript.

2. Una vez completada la configuración, utilice Refresh and prefetch para actualizar la caché del archivo JavaScript de modo que la nueva regla surta efecto inmediatamente.

Causa: La longitud del archivo almacenado en caché en el POP no coincide con el contenido real en el servidor de origen, o el servidor de origen devolvió un encabezado de respuesta Content-Length anómalo. Esto ocurre más comúnmente cuando el servidor de origen actualizó un archivo de video pero CDN todavía devuelve la versión previamente almacenada en caché.

Solución:

• En la página Refresh and prefetch, envíe una tarea de actualización para la URL del video para borrar la caché anterior en los POPs.

• Si el servidor de origen es OSS, puede habilitar la función Automatic CDN cache refresh en la consola de OSS para que se desencadene automáticamente una actualización de caché de CDN cuando se actualice un archivo en el servidor de origen.

• Compruebe la estabilidad del servidor de origen para asegurarse de que no devuelva intermitentemente un valor Content-Length anómalo. Puede ejecutar curl -I varias veces directamente contra el servidor de origen para comparar y verificar.

Sí. Los reproductores de video y las herramientas de descarga suelen utilizar solicitudes por rangos para cargar recursos en segmentos. Cada solicitud recupera solo parte del contenido, y el servidor devuelve 206 Partial Content. Incluso cuando una solicitud coincide con la caché de CDN, el código de estado devuelto es 206, lo cual no es un error.

Nota de facturación: Siempre que un cliente envíe una solicitud a CDN y reciba datos, el tráfico se cuenta como tráfico saliente de CDN, independientemente de si la solicitud coincide con la caché.

Sugerencias de optimización: Asegúrese de que la solicitud al origen por rangos esté habilitada para que los POPs puedan obtener y almacenar en caché segmentos del servidor de origen bajo demanda, lo que mejora la proporción de aciertos para solicitudes de segmentos posteriores. Además, configure un encabezado Cache-Control adecuado en el servidor de origen (como max-age=86400) para utilizar la caché local del navegador y reducir solicitudes duplicadas.

Causa: Los recursos estáticos como imágenes, archivos CSS y archivos JavaScript coinciden con la caché y se aceleran normalmente, pero la página principal (la ruta raíz /) generalmente no tiene una regla de caché. Cada solicitud obtiene la página principal del servidor de origen, por lo que la velocidad de carga depende totalmente del tiempo de procesamiento del servidor de origen.

Solución: Agregue una regla de expiración de caché para el directorio raíz del nombre de dominio acelerado para que el contenido de la página principal también se almacene en caché en los POPs:

1. En la pestaña Cache Expiration, agregue una regla, establezca el tipo en Directory y establezca la dirección en /.

2. Establezca el tiempo de expiración según la frecuencia de actualización del contenido de la página principal, por ejemplo, de 30 segundos a varios minutos.

3. Ajuste el peso de la regla para que el peso de la regla del directorio raíz sea menor que el de las reglas para rutas específicas (como /static/) para evitar anular las reglas de caché para recursos estáticos.

Después de que la configuración surta efecto, los POPs devolverán el contenido de la página principal directamente en lugar de obtenerlo del servidor de origen para cada solicitud. Para obtener instrucciones detalladas de configuración, consulte Configure CDN cache expiration.

Causa: Cuando un POP falla la caché, reenvía la solicitud del cliente y agrega parámetros específicos a los encabezados de la solicitud, como Via y X-Forwarded-For. Algunos servidores de origen devuelven respuestas diferentes basándose en estos parámetros. Por ejemplo, un servidor de origen puede comprobar si la solicitud contiene el encabezado Via para identificar solicitudes de proxy y manejarlas de manera diferente.

Pasos para la solución de problemas:

1. Localice el encabezado que causa la diferencia: Primero acceda al servidor de origen directamente y registre la respuesta. Luego use curl para acceder al servidor de origen con los encabezados que agrega CDN, reemplazándolos y probándolos uno por uno hasta que reproduzca el resultado inconsistente.

2. Ajuste la configuración del servidor de origen: Compruebe cómo procesa el encabezado el servidor web de origen y modifique la lógica según los requisitos de su negocio.

3. O elimine el encabezado en el lado de CDN: Si su negocio no requiere el encabezado, puede eliminarlo en la consola de CDN.

Causa: El servidor de origen realizó una actualización con mismo nombre en el archivo (el contenido del archivo se modificó pero el nombre del archivo no cambió). Antes de que la caché expire, el POP de CDN todavía devuelve la caché anterior directamente, por lo que el archivo descargado no coincide con el del servidor de origen.

Solución:

1. Solución 1: Actualizar la caché manualmente. Después de que el servidor de origen realice una actualización con mismo nombre, envíe una actualización de URL en la página Refresh and prefetch (adecuada para un solo recurso y surte efecto rápidamente) o una actualización de directorio (adecuada para un directorio completo y cubre un amplio rango, pero aumenta temporalmente la presión de solicitudes al origen en el servidor de origen).

2. Solución 2: Forzar una actualización para omitir 304. Si el contenido del archivo en el servidor de origen cambió pero la marca de tiempo Last-Modified no se actualizó, el POP de CDN recibe 304 Not Modified después de la validación de la solicitud condicional (If-Modified-Since), determina que el archivo no ha cambiado y no actualiza la caché. En este caso, una actualización de URL normal puede no surtir efecto. Debe llamar a la API RefreshObjectCaches y establecer el parámetro Force en true para forzar la obtención del archivo completo del servidor de origen.

3. Solución 3: Usar nombrado versionado (recomendado como solución a largo plazo). Se recomienda que el servidor de origen evite actualizaciones con mismo nombre. En su lugar, agregue un número de versión o un hash al nombre del archivo (como style.v2.css o app.abc123.js), o lleve un identificador de versión en un parámetro de URL (como ?v=20260828).

4. Solución 4: Habilitar actualización automática para un origen OSS. Si el servidor de origen es OSS, puede habilitar Automatic CDN cache refresh en la consola de OSS. Cuando un objeto en el origen OSS se actualiza con el mismo nombre, la URL correspondiente de CDN se actualiza automáticamente.

Cuando un servidor web devuelve el código de estado HTTP 404, redirige automáticamente a la página 404, lo que indica que el recurso solicitado no existe en el servidor de origen. Las causas comunes incluyen: la regla de generación de URL cambió, el archivo fue renombrado o movido, el enlace contiene un error tipográfico, no se puede acceder al sitio web en el puerto solicitado, o una política de bloqueo de extensiones de servicio web o una política de asignación MIME bloqueó la solicitud.

Si la página a la que accede contiene múltiples recursos y solo algunos de ellos son inaccesibles, la página no redirige a la página 404 en su totalidad. Para saber cómo configurar páginas de error personalizadas, consulte Configure custom error pages.

Cuando configura una página de error personalizada para el código de estado 403, configurar el enlace de redireccionamiento directamente en la configuración de la página de error puede causar una redirección de dominio o un bucle de redireccionamiento. Utilice el siguiente método en su lugar:

1. Configure la redirección mediante la función Access URL Rewrite en lugar de establecer un enlace de redireccionamiento en la página de error personalizada.

2. Establezca la ruta a reescribir en / y apunte la ruta objetivo a la página 403 estática correcta, por ejemplo, /error/403.html.