CDN:Dépannage du cache

Étapes de dépannage :

1. Confirmez que la configuration est effective : Après avoir ajouté ou modifié une règle de cache, le statut de la règle affiche Configuring, ce qui signifie que la configuration est en cours de diffusion vers les POPs du monde entier. Le statut passe généralement à Success en quelques minutes. Ne vous précipitez pas pour vérifier la règle avant que la configuration ne soit effective.

2. Confirmez que la nouvelle règle s'applique à la ressource cible : Une nouvelle règle ne s'applique qu'aux nouvelles requêtes. Les ressources déjà mises en cache sur les POPs continuent d'être servies selon l'ancienne politique jusqu'à leur expiration. Pour appliquer la règle immédiatement, effacez d'abord le cache précédent en utilisant Actualisation et préchargement.

3. Vérifiez la priorité de correspondance des règles : Lorsqu'une requête correspond à plusieurs règles, une seule règle prend effet. Par défaut, la règle ayant le poids le plus élevé est prioritaire. Lorsque les poids sont égaux, la règle créée en dernier est généralement prioritaire (reportez-vous à la description réelle dans la console). Assurez-vous que la règle correspondant au chemin cible possède le poids le plus élevé. Par exemple, le poids d'un répertoire spécifique (/static/) doit être supérieur à celui du répertoire racine (/).

4. Vérifiez si les en-têtes de réponse de l'origine interdisent la mise en cache : Si le serveur d'origine renvoie Cache-Control: no-cache, no-store, max-age=0 ou Pragma: no-cache, CDN suit par défaut la directive de l'origine. Pour connaître l'impact des différentes directives sur le comportement d'appel à l'origine, consultez le tableau suivant. Vous pouvez activer Ignore no-cache headers from the origin server dans la règle de cache pour forcer la mise en cache basée sur les règles de la console, ou ajuster la configuration du serveur d'origine pour supprimer les directives no-cache pour les ressources statiques.

5. Vérifiez comment les paramètres d'URL sont traités : Si l'URL contient des paramètres et que Ignore parameters est désactivé, les URL avec différents paramètres sont traitées comme des ressources distinctes, ce qui réduit le taux de succès du cache. Vous pouvez activer Ignore parameters ou Retain specified parameters.

6. Vérifiez si le répertoire racine est mal configuré comme non mis en cache : Si la règle pour le répertoire racine / a le poids le plus élevé et un délai d'expiration de 0 seconde, toutes les requêtes déclenchent un appel à l'origine.

À l'étape 4 ci-dessus, les différentes directives no-cache provenant du serveur d'origine ont des impacts significativement différents sur le comportement d'appel à l'origine. Évaluez la charge sur le serveur d'origine en fonction de la directive réelle :

En-tête de réponse de l'origine	Comportement CDN	Impact sur le serveur d'origine
Cache-Control: no-store	La mise en cache est complètement interdite. Chaque requête récupère la ressource complète depuis le serveur d'origine.	Le serveur d'origine supporte toute la pression du trafic.
Cache-Control: no-cache ou max-age=0	Les POPs sont autorisés à stocker des copies en cache, mais ils doivent revalider auprès du serveur d'origine avant chaque utilisation. Lorsque la validation réussit, le serveur d'origine renvoie 304 (sans corps de réponse), et la surcharge est bien inférieure à un appel complet à l'origine.	Le nombre d'appels à l'origine ne diminue pas, mais chaque appel n'est qu'une petite requête conditionnelle, donc la pression sur la bande passante est gérable.
Pragma: no-cache	Directive de compatibilité HTTP/1.0. L'effet est similaire à no-cache.	Identique à ci-dessus.

L'objectif de définir le délai d'expiration sur 0 est de faire en sorte que chaque requête récupère le contenu le plus récent depuis le serveur d'origine. Si un contenu antérieur est toujours renvoyé, procédez au dépannage comme suit :

1. Écartez le cache local du navigateur : Effacez le cache du navigateur ou utilisez le mode navigation privée pour tester à nouveau, et confirmez que c'est le POP et non le navigateur qui renvoie le contenu antérieur.

2. Effacez le cache existant avant la modification de la configuration : Les ressources mises en cache avant que vous ne modifiiez la configuration ne sont pas effacées automatiquement. Soumettez une tâche d'actualisation d'URL en utilisant Actualisation et préchargement.

3. Vérifiez si le serveur d'origine possède son propre cache : Le serveur d'origine (par exemple, un cache Nginx ou un cache au niveau de l'application) peut renvoyer un contenu antérieur, de sorte que CDN récupère des données obsolètes lors de l'appel à l'origine.

4. Confirmez que la configuration est effective dans le monde entier : Le statut de la règle doit être Success. La diffusion de la configuration vers tous les POPs prend quelques minutes.

5. Confirmez que la requête atteint le POP attendu : Les utilisateurs de différents FAI ou dans différentes régions peuvent atteindre différents POPs. Effectuez des tests dans plusieurs régions séparément, ou utilisez les journaux en temps réel de CDN et l'adresse IP du POP dans la réponse pour identifier davantage le problème.

1. Vérifiez l'exhaustivité de la configuration : Une clé de cache personnalisée nécessite généralement de définir des conditions de règle basées sur les caractéristiques de la requête (telles que User-Agent) puis d'ajouter différentes variables de clé de cache à chaque règle. Confirmez que les caractéristiques de requête des clients mobiles et PC sont correctement identifiées, et que les conditions de correspondance des deux règles ne se chevauchent pas.

2. Attendez que la configuration prenne effet : Après avoir soumis la configuration, attendez 5 à 10 minutes pour qu'elle se synchronise dans le monde entier.

3. Actualisez le cache précédent : Les ressources mises en cache sous l'ancienne clé de cache avant la modification de la configuration n'expirent pas automatiquement. Soumettez une tâche d'actualisation (nous vous recommandons d'utiliser l'actualisation de répertoire).

4. Vérifiez côté client : Effacez le cache du navigateur et réessayez, et vérifiez si X-Cache dans les en-têtes de réponse est MISS.

5. Testez avec de vrais appareils : Envoyez des requêtes en utilisant le User-Agent réel de différents appareils au lieu de seulement redimensionner la fenêtre du navigateur (le User-Agent émulé par un navigateur peut différer de celui d'un appareil réel).

Cause : Lorsque la réponse de l'origine contient l'en-tête de réponse Set-Cookie, CDN ne met pas la réponse en cache par défaut, ce qui entraîne un taux de succès du cache de 0.

Solutions recommandées (par ordre de priorité) :

• Corrigez-le côté origine (recommandé) : Faites en sorte que le serveur d'origine arrête de renvoyer Set-Cookie pour les ressources statiques telles que les images, CSS, JavaScript et polices. Il s'agit de la solution fondamentale. Cela n'affecte pas la gestion de session des endpoints dynamiques et améliore le taux de succès du cache.

• Supprimez-le par chemin côté CDN : Si le serveur d'origine ne peut pas être ajusté, supprimez cet en-tête de réponse côté CDN uniquement pour les chemins de ressources statiques tels que /static/, *.css et *.js afin d'éviter d'affecter les endpoints dynamiques.

Étapes pour supprimer l'en-tête par chemin côté CDN :

1. Connectez-vous à la console CDN. Sur la page Domain Names, trouvez le nom de domaine cible et cliquez sur Manage.

2. Dans le volet de navigation de gauche de la page des détails du domaine, cliquez sur Origin Settings et accédez à l'onglet Modify incoming response headers.

3. Cliquez sur Add, restreignez la condition de règle aux chemins de ressources statiques, sélectionnez Delete pour l'opération d'en-tête de réponse, et saisissez Set-Cookie pour le nom de l'en-tête de réponse.

4. Une fois la configuration terminée, utilisez Actualisation et préchargement pour effacer les réponses antérieures mises en cache afin que la nouvelle règle prenne effet.

Si le taux de succès du cache ne s'améliore toujours pas après la configuration, vérifiez les éléments suivants : si Ignore no-cache headers from the origin server est activé dans les règles de cache, et si Ignore parameters est activé pour empêcher que la même ressource ne soit divisée en plusieurs objets de cache en raison de différents paramètres de requête. Pour les règles de cache par défaut de CDN, consultez Configure CDN cache expiration.

Un faible taux de succès du cache signifie que la plupart des requêtes déclenchent un appel à l'origine. Un chemin réseau public instable peut dégrader l'effet d'accélération et exercer une pression de charge sur le serveur d'origine. Procédez au dépannage comme suit :

1. Vérifiez si le serveur d'origine renvoie des directives no-cache : Il s'agit de la cause la plus courante d'un faible taux de succès et d'une saturation de la bande passante de l'origine. Si le serveur d'origine renvoie Cache-Control: no-cache, no-store, max-age=0 ou Pragma: no-cache, CDN suit la directive de l'origine et ne met pas la ressource en cache, de sorte que chaque requête déclenche un appel à l'origine. Vous pouvez activer Ignore no-cache headers from the origin server dans la configuration d'expiration du cache pour forcer la mise en cache basée sur les règles de la console, ou ajuster la configuration du serveur d'origine.

2. Vérifiez si les règles de cache sont mal configurées : Confirmez que le délai d'expiration du cache pour le répertoire racine / n'est pas défini sur 0 seconde avec le poids le plus élevé. Sinon, toutes les requêtes déclenchent un appel à l'origine.

3. Vérifiez si les URL contiennent des paramètres variables : La modification des paramètres après le point d'interrogation dans une URL fait que le même contenu est traité comme des ressources différentes. L'activation de Ignore parameters consolide ces requêtes en un seul objet de cache. Pour plus d'informations, consultez l'élément suivant.

4. Configurez séparément les ressources statiques et dynamiques : Définissez une longue durée de cache (par exemple 30 jours) pour les ressources statiques telles que les images, CSS, JavaScript et polices, et définissez le délai d'expiration sur 0 seconde pour le contenu dynamique tel que PHP, JSP et les endpoints API.

5. Activez la récupération par plage pour les fichiers volumineux : Pour les fichiers volumineux tels que les vidéos et les packages d'installation, assurez-vous que la récupération par plage est activée afin que le POP ne récupère pas le fichier entier depuis le serveur d'origine pour chaque requête. Avant d'activer cette fonctionnalité, confirmez que le serveur d'origine prend en charge les requêtes par plage (c'est-à-dire qu'il peut renvoyer 206 Partial Content). L'activation de cette fonctionnalité lorsque le serveur d'origine ne prend pas en charge les requêtes par plage peut provoquer des échecs de requête ou un contenu anormal.

6. Vérifiez si le QPS métier est trop faible : L'espace disque des POPs est limité, et les ressources auxquelles on accède rarement sont évincées par les ressources populaires, ce qui déclenche un appel à l'origine. Pour les noms de domaine avec seulement une douzaine de QPS, nous vous recommandons de soumettre des tâches de préchargement en utilisant Actualisation et préchargement afin que les ressources restent résidentes sur les POPs.

Symptôme : Le taux de succès global d'une page est faible. Les en-têtes de réponse montrent que X-Cache est MISS pour la requête principale, mais HIT pour les fichiers individuels sur la page.

Cause : L'URL contient des paramètres qui changent à chaque requête, tels qu'un horodatage. Lorsque la fonctionnalité d'ignorance des paramètres est désactivée, CDN traite chaque URL avec différents paramètres comme une ressource indépendante et ne peut pas réutiliser le cache. Par exemple, la valeur après ?_t= dans http://example.com/movie/res/ArrowScene.ccbi?_t=1699999999 diffère pour chaque requête.

Solution : Activez Ignore parameters dans la console CDN. Après avoir activé cette fonctionnalité, les paramètres sont exclus du calcul de l'objet de cache, et les requêtes pour la même ressource avec différents paramètres atteignent le même cache. Si votre métier dépend de certains paramètres, sélectionnez Retain specified parameters pour ignorer uniquement ceux qui ne sont pas pertinents.

Causes courantes de fluctuations à court terme ou d'une diminution continue du taux de succès :

• Une actualisation du cache a été effectuée : Une actualisation manuelle ou automatique efface le cache sur les POPs, donc une diminution du taux de succès sur une courte période est attendue. Au fur et à mesure que les ressources sont remises en cache, le taux de succès récupère généralement automatiquement en quelques heures.

• Une augmentation soudaine de la bande passante s'est produite : Une forte augmentation du trafic sur une courte période apporte de nombreuses premières requêtes, ce qui augmente les appels à l'origine et diminue le taux de succès.

• Une grande quantité de nouveau contenu est consultée : Lorsque les POPs demandent fréquemment des ressources consultées pour la première fois, l'appel à l'origine est inévitable et le taux de succès diminue.

• Les règles de cache ont été ajustées : La modification de la politique de cache, en particulier le raccourcissement du délai d'expiration, affecte le taux de succès.

• Les URL contiennent des paramètres variables : La modification des paramètres divise le même contenu en plusieurs objets de cache.

• Le délai d'expiration du cache n'est pas correctement configuré : Si la configuration ne différencie pas les ressources par fréquence de mise à jour, le cache expire trop tôt.

Si vous avez configuré des en-têtes de réponse CORS sur CDN mais que les clients signalent toujours des erreurs CORS et que les en-têtes de réponse ne contiennent pas le champ configuré, les causes possibles et les solutions sont les suivantes :

• La configuration n'a pas pris effet : Confirmez que la configuration est enregistrée et que le statut de la règle est Success.

• La configuration n'a pas été entièrement diffusée : Les modifications de la configuration des en-têtes de réponse sortants prennent généralement effet dans les 5 minutes. Attendez et réessayez. Cette configuration n'affecte que les réponses reçues par les clients, pas le comportement de mise en cache des POPs, donc aucune actualisation ou préchargement n'est requis (le préchargement ne modifie pas les en-têtes de réponse des ressources déjà mises en cache).

• Les en-têtes de réponse du serveur d'origine entrent en conflit avec la configuration CDN : Si le serveur d'origine renvoie également des en-têtes de réponse CORS, les en-têtes peuvent se remplacer mutuellement. Nous vous recommandons d'utiliser des configurations CORS cohérentes sur le serveur d'origine et CDN, ou de définir Allow Duplicate sur No dans Modify outbound response headers afin que la valeur configurée sur CDN remplace la valeur renvoyée par le serveur d'origine.

• Le navigateur a mis en cache la réponse précédente : Effacez le cache du navigateur ou utilisez le mode navigation privée pour tester.

• La configuration de domaine générique n'est pas prise en charge : Après avoir activé la validation CORS, vous ne pouvez configurer qu'un seul nom de domaine générique, ou plusieurs noms de domaine exacts séparés par des virgules. La séparation de plusieurs noms de domaine génériques par des virgules n'est pas prise en charge.

• La valeur Access-Control-Allow-Origin ne correspond pas à l'origine de la requête : Si le navigateur signale « The 'Access-Control-Allow-Origin' header has a value that is not equal to the supplied origin », l'origine autorisée renvoyée ne correspond pas à l'origine réelle de la requête. Vous pouvez résoudre ce problème de la manière suivante :

  • Dans Modify outbound response headers, reconfigurez Access-Control-Allow-Origin et définissez Allow Duplicate sur No afin que la nouvelle valeur remplace la valeur précédente renvoyée par le serveur d'origine.

  • Si votre métier le permet, configurez cet en-tête de réponse pour renvoyer dynamiquement la valeur Origin de la requête afin que l'origine autorisée corresponde toujours à l'origine de la requête. Une fois la configuration terminée, attendez environ 5 minutes pour qu'elle prenne effet. Aucune actualisation du cache n'est requise.

Pour savoir comment configurer le partage de ressources cross-origin, consultez Configure cross-origin resource sharing.

• Confirmez que les requêtes passent par les POPs CDN : Vérifiez si la résolution DNS conserve uniquement l'enregistrement CNAME fourni par CDN et si les enregistrements de résolution directe pour les origines telles que OSS sont supprimés. Si le trafic va directement au serveur d'origine, les en-têtes de réponse configurés sur CDN ne prennent pas effet.

• Confirmez que vous avez configuré un en-tête de réponse sortant plutôt qu'entrant : Les en-têtes de réponse entrants s'appliquent uniquement à la communication entre le serveur d'origine et les POPs CDN, et les utilisateurs finaux n'en ont pas connaissance. Pour affecter les réponses que les utilisateurs finaux reçoivent, configurez Modify outbound response headers.

• Confirmez si le serveur d'origine renvoie l'en-tête de réponse : CDN transmet les en-têtes de réponse de l'origine par défaut. Si le serveur d'origine ne renvoie pas l'en-tête, CDN ne le renvoie pas non plus. Pour forcer l'inclusion de l'en-tête de réponse indépendamment du fait que le serveur d'origine le renvoie, sélectionnez l'opération Add dans Modify outbound response headers.

• Si Content-Type ne prend pas effet, vérifiez les métadonnées sur le serveur d'origine : Si le serveur d'origine (tel que OSS) ne spécifie pas le bon Content-Type lorsqu'un fichier est téléchargé, les métadonnées obtenues lors de l'appel à l'origine ne correspondent pas à vos attentes. Vérifiez le paramètre Content-Type utilisé lors du téléchargement du fichier.

• Confirmez que vous avez attendu que la configuration prenne effet : Les modifications de la configuration des en-têtes de réponse sortants prennent généralement effet dans les 5 minutes, et n'affectent que les réponses reçues par les clients, pas le comportement de mise en cache des POPs, donc aucune actualisation ou préchargement n'est requis (le préchargement ne modifie pas les en-têtes de réponse des ressources déjà mises en cache).

Pour savoir comment configurer les en-têtes de réponse sortants et les descriptions des paramètres, consultez Modify outbound response headers.

Cause : L'en-tête de réponse Content-Type renvoyé par le serveur d'origine ne spécifie pas correctement l'encodage des caractères, et le client analyse le contenu avec le mauvais encodage, ce qui rend la page illisible.

Solution 1 (recommandée, correction à la source) : Modifiez la configuration du serveur d'origine pour vous assurer que Content-Type contient la déclaration d'encodage des caractères correcte lorsque HTML est renvoyé.

Solution 2 (réécriture côté CDN) :

1. Connectez-vous à la console CDN. Sur la page Domain Names, trouvez le nom de domaine cible et cliquez sur Manage.

2. Dans Modify incoming response headers, ajoutez une règle pour réécrire le Content-Type du chemin correspondant en text/html; charset=utf-8.

3. Une fois la configuration terminée, utilisez Actualisation et préchargement pour actualiser les ressources mises en cache sous ce chemin afin que les POPs les remettent en cache avec le type correct.

Vous pouvez configurer l'en-tête de réponse Content-Disposition en utilisant la fonctionnalité Modify outbound response headers pour contrôler le comportement de téléchargement ou d'aperçu des vidéos : s'il est défini sur attachment; filename='video.mp4', un téléchargement est déclenché lorsqu'un utilisateur accède à la ressource ; s'il est défini sur inline, la ressource est affichée directement dans le navigateur.

Si la configuration ne prend pas effet, vérifiez les éléments suivants :

1. La condition de correspondance du moteur de règles : Assurez-vous que la condition de correspondance de la règle cible le chemin URI (par exemple, contient /video-origin/20260414) au lieu de seulement correspondre à la chaîne de requête. Le moteur de règles détermine si la configuration prend effet en identifiant les informations de chemin dans la requête utilisateur.

2. Le POP a mis en cache l'en-tête de réponse précédent : Content-Disposition affecte directement le comportement du navigateur. Si la configuration ne prend pas effet 5 minutes après son enregistrement, écartez d'abord le cache local du navigateur (réessayez en mode navigation privée) et confirmez que le statut de la règle est Success.

Cause : Lorsque le serveur d'origine renvoie initialement le fichier JavaScript, l'en-tête de réponse Content-Type est incorrectement défini sur text/html. Après que CDN a mis en cache le mauvais type, le navigateur analyse le fichier JavaScript comme text/html, ce qui provoque un affichage illisible ou des erreurs d'exécution. Lors de la deuxième visite, la page revient à la normale car le serveur d'origine a corrigé le Content-Type ou CDN a récupéré le type correct depuis le serveur d'origine à nouveau.

Solution :

1. Dans Modify incoming response headers dans la console CDN, ajoutez une règle pour correspondre au chemin du fichier JavaScript (tel que *.js) et remplacez forcement le Content-Type par application/javascript.

2. Une fois la configuration terminée, utilisez Actualisation et préchargement pour actualiser le cache du fichier JavaScript afin que la nouvelle règle prenne effet immédiatement.

Cause : La longueur du fichier mis en cache sur le POP ne correspond pas au contenu réel sur le serveur d'origine, ou le serveur d'origine a renvoyé un en-tête de réponse Content-Length anormal. Cela se produit le plus souvent lorsque le serveur d'origine a mis à jour un fichier vidéo mais que CDN renvoie toujours la version précédemment mise en cache.

Solution :

• Sur la page Actualisation et préchargement, soumettez une tâche d'actualisation pour l'URL vidéo afin d'effacer le cache précédent sur les POPs.

• Si le serveur d'origine est OSS, vous pouvez activer la fonctionnalité Automatic CDN cache refresh dans la console OSS afin qu'une actualisation du cache CDN soit déclenchée automatiquement lorsqu'un fichier sur le serveur d'origine est mis à jour.

• Vérifiez la stabilité du serveur d'origine pour vous assurer qu'il ne renvoie pas de manière intermittente une valeur Content-Length anormale. Vous pouvez exécuter curl -I plusieurs fois directement contre le serveur d'origine pour comparer et vérifier.

Oui. Les lecteurs vidéo et les outils de téléchargement utilisent généralement des requêtes par plage pour charger les ressources par segments. Chaque requête récupère uniquement une partie du contenu, et le serveur renvoie 206 Partial Content. Même lorsqu'une requête atteint le cache CDN, le code d'état renvoyé est 206, ce qui n'est pas une erreur.

Note de facturation : Tant qu'un client envoie une requête à CDN et reçoit des données, le trafic est compté comme trafic sortant CDN indépendamment du fait que la requête atteigne le cache ou non.

Suggestions d'optimisation : Assurez-vous que la récupération par plage est activée afin que les POPs puissent récupérer et mettre en cache les segments depuis le serveur d'origine à la demande, ce qui améliore le taux de succès pour les requêtes de segments ultérieures. De plus, configurez un en-tête Cache-Control approprié sur le serveur d'origine (tel que max-age=86400) pour utiliser le cache local du navigateur et réduire les requêtes dupliquées.

Cause : Les ressources statiques telles que les images, les fichiers CSS et les fichiers JavaScript atteignent le cache et sont accélérées normalement, mais la page d'accueil (le chemin racine /) n'a généralement pas de règle de cache. Chaque requête récupère la page d'accueil depuis le serveur d'origine, donc la vitesse de chargement dépend entièrement du temps de traitement du serveur d'origine.

Solution : Ajoutez une règle d'expiration du cache pour le répertoire racine du nom de domaine accéléré afin que le contenu de la page d'accueil soit également mis en cache sur les POPs :

1. Dans l'onglet Cache Expiration, ajoutez une règle, définissez le type sur Directory et définissez l'adresse sur /.

2. Définissez le délai d'expiration en fonction de la fréquence de mise à jour du contenu de la page d'accueil, par exemple de 30 secondes à plusieurs minutes.

3. Ajustez le poids de la règle afin que le poids de la règle du répertoire racine soit inférieur à celui des règles pour les chemins spécifiques (tels que /static/) pour éviter de remplacer les règles de cache pour les ressources statiques.

Une fois la configuration effective, les POPs renvoient le contenu de la page d'accueil directement au lieu de le récupérer depuis le serveur d'origine pour chaque requête. Pour des instructions de configuration détaillées, consultez Configure CDN cache expiration.

Cause : Lorsqu'un POP rate le cache, il transfère la requête du client et ajoute des paramètres spécifiques aux en-têtes de requête, tels que Via et X-Forwarded-For. Certains serveurs d'origine renvoient des réponses différentes en fonction de ces paramètres. Par exemple, un serveur d'origine peut vérifier si la requête contient l'en-tête Via pour identifier les requêtes proxy et les traiter différemment.

Étapes de dépannage :

1. Localisez l'en-tête qui cause la différence : Accédez d'abord au serveur d'origine directement et enregistrez la réponse. Ensuite, utilisez curl pour accéder au serveur d'origine avec les en-têtes ajoutés par CDN, en les remplaçant et testant un par un jusqu'à reproduire le résultat incohérent.

2. Ajustez la configuration du serveur d'origine : Vérifiez comment le serveur web d'origine traite l'en-tête et modifiez la logique en fonction de vos besoins métier.

3. Ou supprimez l'en-tête côté CDN : Si l'en-tête n'est pas requis par votre métier, vous pouvez le supprimer dans la console CDN.

Cause : Le serveur d'origine a effectué une mise à jour avec le même nom sur le fichier (le contenu du fichier a été modifié mais le nom du fichier n'a pas changé). Avant l'expiration du cache, le POP CDN renvoie toujours directement le cache précédent, de sorte que le fichier téléchargé est incohérent avec celui sur le serveur d'origine.

Solution :

1. Solution 1 : Actualiser manuellement le cache. Après que le serveur d'origine effectue une mise à jour avec le même nom, soumettez une actualisation d'URL sur la page Actualisation et préchargement (adaptée à une ressource unique et prend effet rapidement) ou une actualisation de répertoire (adaptée à un répertoire entier et couvre une large gamme, mais augmente temporairement la pression d'appel à l'origine sur le serveur d'origine).

2. Solution 2 : Forcer une actualisation pour contourner 304. Si le contenu du fichier sur le serveur d'origine a changé mais que l'horodatage Last-Modified n'a pas été mis à jour, le POP CDN reçoit 304 Not Modified après la validation de la requête conditionnelle (If-Modified-Since), détermine que le fichier n'a pas changé et ne met pas à jour le cache. Dans ce cas, une actualisation d'URL normale peut ne pas prendre effet. Vous devez appeler l'API RefreshObjectCaches et définir le paramètre Force sur true pour forcer la récupération du fichier complet depuis le serveur d'origine.

3. Solution 3 : Utiliser le nommage versionné (recommandé comme solution à long terme). Nous recommandons que le serveur d'origine évite les mises à jour avec le même nom. Ajoutez plutôt un numéro de version ou un hachage au nom du fichier (tel que style.v2.css ou app.abc123.js), ou incluez un identifiant de version dans un paramètre d'URL (tel que ?v=20260828).

4. Solution 4 : Activer l'actualisation automatique pour une origine OSS. Si le serveur d'origine est OSS, vous pouvez activer Automatic CDN cache refresh dans la console OSS. Lorsqu'un objet sur l'origine OSS est mis à jour avec le même nom, l'URL CDN correspondante est actualisée automatiquement.

Lorsqu'un serveur web renvoie le code d'état HTTP 404, il redirige automatiquement vers la page 404, ce qui indique que la ressource demandée n'existe pas sur le serveur d'origine. Les causes courantes incluent : la règle de génération d'URL a changé, le fichier a été renommé ou déplacé, le lien contient une faute de frappe, le site web n'est pas accessible sur le port demandé, ou une politique de verrouillage d'extension de service web ou une politique de mappage MIME a bloqué la requête.

Si la page à laquelle vous accédez contient plusieurs ressources et que seules certaines d'entre elles sont inaccessibles, la page ne redirige pas vers la page 404 dans son ensemble. Pour savoir comment configurer des pages d'erreur personnalisées, consultez Configure custom error pages.

Lorsque vous configurez une page d'erreur personnalisée pour le code d'état 403, la configuration directe du lien de redirection dans les paramètres de la page d'erreur peut provoquer une redirection de domaine ou une boucle de redirection. Utilisez plutôt la méthode suivante :

1. Configurez la redirection en utilisant la fonctionnalité Access URL Rewrite au lieu de définir un lien de redirection dans la page d'erreur personnalisée.

2. Définissez le chemin à réécrire sur / et pointez le chemin cible vers la page 403 statique correcte, par exemple /error/403.html.