FAQ sur l'accélération CDN pour OSS - CDN - Centre de documentation Alibaba Cloud

Cette rubrique décrit les problèmes courants et leurs solutions lors de l'utilisation du CDN pour accélérer l'accès aux ressources OSS. Elle couvre la vérification de l'accélération, le déploiement HTTPS, la récupération à l'origine pour les buckets privés, les politiques de mise en cache, le traitement d'images et les snapshots vidéo, ainsi que la configuration de la protection contre le hotlinking.

Vérification de l'accélération CDN pour OSS

Étape 1 : Vérifiez l'enregistrement CNAME

Par exemple, si vous utilisez Alibaba Cloud DNS, connectez-vous à la console de gestion DNS, sélectionnez Authoritative DNS, puis cliquez sur DNS Settings à côté du nom de domaine.
Vérifiez qu'un enregistrement CNAME (par exemple, oss.example.com.w.kunlunaq.com) a été ajouté pour le nom de domaine accéléré (par exemple, oss.example.com) et que son statut est Enabled.

Étape 2 : Vérifiez le domaine avec nslookup

Ouvrez l'invite de commandes (Windows) ou le Terminal (macOS/Linux).
Exécutez nslookup -type=CNAME <accelerated_domain_name>. Si la valeur CNAME renvoyée correspond à celle fournie dans la console CDN pour le nom de domaine accéléré, l'accélération CDN est active.

Si vous n'avez pas configuré d'enregistrement CNAME, consultez Configurer un enregistrement CNAME.

Accélération d'un bucket OSS privé avec CDN

Si l'origine de votre nom de domaine accéléré est un bucket privé, vous devez activer Accès aux buckets OSS privés pour le nom de domaine accéléré. Cela permet au CDN d'accélérer l'accès aux ressources du bucket privé.

Une fois cette fonctionnalité activée, vous pouvez accéder à toutes les ressources du bucket privé via le nom de domaine accéléré ; la méthode d'authentification privée basée sur l'URL d'origine ne s'applique plus. Utilisez les fonctionnalités de protection contre le hotlinking et d'authentification par URL du CDN pour protéger vos ressources contre les accès non autorisés. Pour plus d'informations, consultez Configurer une liste blanche ou noire de Referer et Configurer l'authentification par URL.

Déploiement de certificats HTTPS pour l'accélération CDN

Lorsque vous utilisez le CDN pour accélérer l'accès à OSS, il vous suffit de déployer un certificat HTTPS sur le CDN. Pour plus d'informations, consultez Configurer un certificat HTTPS.

Si votre certificat est géré par Alibaba Cloud Digital Certificate Management Service (anciennement SSL Certificate Service), vous pouvez également le déployer depuis la console Digital Certificate Management Service. Pour plus d'informations, consultez Déployer un certificat SSL sur les services Alibaba Cloud.

Erreur 403 Forbidden

Étapes de dépannage :

Vérifiez le message d'erreur affiché sur la page. Si vous voyez des messages tels que You don't have permission to access the URL on this server ou You are forbidden to list buckets, accompagnés de détails comme denied by IP ACL = not in whitelist, ces informations vous permettent d'identifier rapidement la politique de blocage.
Si le seul message affiché est You don't have permission to access the URL on this server sans autres détails, vérifiez vos paramètres d'authentification par URL CDN et d'authentification distante.

Si les images d'un nom de domaine ne se chargent pas en raison d'une erreur d'autorisation refusée :

Vérifiez l'option de récupération à l'origine pour les buckets privés : Connectez-vous à la console CDN, accédez à la page Domain ManagementDomain Management du nom de domaine cible et confirmez que la récupération à l'origine pour le bucket privé Alibaba Cloud OSS est activée. Si elle n'est pas activée, le CDN n'a pas l'autorisation d'accéder aux ressources OSS privées, ce qui entraîne une erreur 403.
Vérifiez la configuration de la liste blanche/noire de Referer : Accédez aux paramètres du domaine et vérifiez que le Referer de la requête figure dans la liste blanche. Si la requête est bloquée par une règle de Referer, ajoutez le Referer cible à la liste blanche.

Si vous avez configuré l'hébergement de site statique sur OSS et que le fichier d'index (par exemple, index.html) ou le bucket lui-même est privé, vous devez activer la fonctionnalité Accès aux buckets OSS privés. Configurez ensuite une règle de réécriture d'URL dans le CDN pour réécrire les URL d'accès vers le fichier d'index configuré (par exemple, index.html). Le nœud de bordure CDN émet une redirection 302, invitant le client à demander le contenu index.html. Ce processus permet l'hébergement de site statique. Pour une configuration détaillée, consultez Réécrire une URL d'accès. Pour configurer la règle, définissez Path to Rewrite sur ^/$, Target Path sur /index.html et Action sur Redirect.

Accès lent après l'activation du CDN

Lorsque vous accédez à une ressource pour la première fois via un nom de domaine accéléré, la requête est envoyée à un nœud de bordure CDN. Comme la ressource n'est pas encore mise en cache sur le nœud, celui-ci effectue une récupération à l'origine depuis OSS, met la ressource en cache, puis la renvoie au client. Les requêtes suivantes pour la même ressource sont servies directement depuis le nœud de bordure CDN. Par conséquent, le premier accès peut être plus lent que sans accélération CDN.

Utilisez la fonctionnalité de préchauffage du CDN pour mettre en cache les ressources OSS sur les nœuds de bordure CDN à l'avance. Cela garantit que la première requête du client est servie directement depuis un nœud de bordure CDN sans récupération à l'origine. Pour obtenir des instructions, consultez Actualiser et préchauffer des ressources.

Politique de cache pour réduire les récupérations à l'origine

Si vous ne configurez pas de durée d'expiration du cache ou si la durée configurée est trop courte, le CDN peut effectuer des récupérations à l'origine fréquentes. Cela augmente le trafic entre l'origine et OSS ainsi que les coûts associés, et peut réduire la vitesse d'accès. Configurez les durées d'expiration du cache en fonction de vos besoins métier :

Pour les fichiers statiques rarement mis à jour, tels que les images et les installateurs d'applications, définissez la durée de vie (TTL) sur un mois ou plus.
Pour les fichiers statiques fréquemment mis à jour, tels que les fichiers JS et CSS, définissez la TTL en fonction de votre fréquence de mise à jour.

Pour plus d'informations, consultez Configurer les règles d'expiration du cache.

Garantir l'accès des utilisateurs aux dernières ressources

Après avoir modifié un fichier dans OSS, pour garantir que les nœuds CDN actualisent automatiquement leur cache et que les clients reçoivent le contenu mis à jour, activez la fonctionnalité d'actualisation automatique du cache CDN dans la console OSS. Pour des instructions spécifiques, consultez la section « Activer l'actualisation automatique du cache CDN » dans Configurer l'actualisation automatique du cache CDN.

Cette fonctionnalité ne garantit pas qu'une tâche d'actualisation sera soumise avec succès ou en temps opportun. Si vous avez besoin de mises à jour en temps réel ou devez suivre le statut de l'actualisation, utilisez la fonctionnalité d'actualisation du CDN. Pour plus d'informations, consultez Actualiser et préchauffer des ressources.

Impossible d'activer l'actualisation automatique du CDN dans la console OSS

Vous ne pouvez pas activer l'actualisation automatique du cache CDN et un message s'affiche : « Please bind this domain name in OSS first ».

Solution : Dans la colonne Map Custom Domain Name, cliquez sur Unbound pour le domaine correspondant et suivez les instructions à l'écran pour lier le domaine. Si vous avez déjà lié le domaine au CDN et que votre DNS est résolu vers le CNAME du CDN, ne modifiez pas l'enregistrement DNS après avoir lié le domaine OSS. Sinon, le service d'accélération CDN ne fonctionnera pas.

Les paramètres de traitement d'image OSS sont inefficaces

Lors de l'utilisation du CDN pour accélérer OSS, les requêtes atteignent d'abord un nœud de bordure CDN. Si la fonctionnalité « Ignorer les paramètres » est activée dans le CDN, le nœud supprime tous les paramètres situés après le ? dans l'URL de la requête. Si la ressource est déjà mise en cache, le CDN n'effectue pas de récupération à l'origine et le traitement d'image OSS ne s'applique pas. Pour plus d'informations, consultez Ignorer les paramètres.

Désactivez la fonctionnalité « Ignorer les paramètres ». Lorsqu'une requête inclut des paramètres, elle déclenche une récupération à l'origine vers OSS et le traitement d'image fonctionne comme prévu.

Après avoir désactivé « Ignorer les paramètres », le taux de succès du cache peut diminuer car chaque requête avec des paramètres déclenche une récupération à l'origine. Vous pouvez également utiliser la fonctionnalité de traitement d'image fournie par le CDN pour effectuer le traitement d'image sur les nœuds de bordure CDN.

Configuration spéciale pour les snapshots vidéo

Lors de l'utilisation de la fonctionnalité de snapshot vidéo OSS (avec des paramètres tels que x-oss-process=video/snapshot,t_1000), si « Ignorer les paramètres » est activé pour le domaine CDN, l'URL vidéo d'origine et l'URL avec les paramètres de snapshot sont mises en cache comme la même ressource. Cela peut entraîner le retour de l'image de snapshot lors de l'accès à la vidéo, ou le retour de la vidéo d'origine lors de la demande du snapshot.

Solution : Dans la console CDN, utilisez la fonctionnalité « Ignorer les paramètres d'URL » et passez au mode qui conserve les paramètres spécifiés. Ajoutez x-oss-process à la liste des paramètres conservés. Cela permet aux URL avec des paramètres de snapshot d'être mises en cache séparément, évitant ainsi les conflits avec le cache vidéo d'origine. Après avoir modifié la configuration, vous devez actualiser le répertoire contenant les fichiers vidéo.

Exclusion de fichiers ou de répertoires du cache CDN

Lors de l'accélération d'OSS avec le CDN, vous devrez peut-être contourner le cache CDN pour certains fichiers ou répertoires afin que chaque requête récupère la dernière version directement depuis OSS. Deux méthodes sont possibles, selon vos pratiques de gestion :

Configuration côté CDN (recommandée) : Gérez les règles de mise en cache dans la console CDN. Cette méthode convient aux scénarios où une équipe opérationnelle effectue une gestion centralisée. Accédez à CacheCache et définissez la durée de mise en cache sur 0. Une fois la règle appliquée, lorsque le CDN reçoit des requêtes pour ces chemins, il effectue une récupération à l'origine depuis OSS et ne met pas la réponse en cache.
Configuration côté OSS : Définissez les en-têtes de réponse pour les fichiers OSS. Cette approche convient aux scénarios où la gestion du stockage et du contenu est séparée. Dans la console CDN, assurez-vous que la politique de mise en cache est priorisée pour respecter les en-têtes d'origine ; sinon, les règles CDN personnalisées peuvent les remplacer. Ensuite, accédez à la console OSS, naviguez vers File Management > Files, sélectionnez le fichier cible et définissez la valeur Cache-Control selon vos besoins :

Valeur Cache-control

Cas d'utilisation

Description

no-cache

Recommandé : Pour le contenu nécessitant la récupération de la dernière version à chaque fois, tel que les fichiers HTML, les fichiers de configuration ou les métadonnées de version.

Le CDN ne met pas le contenu en cache. Le navigateur revalide auprès de l'origine en utilisant un ETag.

no-store

Scénarios haute sensibilité : Pour le contenu qui ne doit être stocké à aucun moment, tel que les données de confidentialité des utilisateurs, les jetons ou les informations financières.

Ni le CDN ni le navigateur ne mettent le contenu en cache. Une requête complète est effectuée à chaque fois.

private

Contenu personnalisé : Pour les pages contenant du contenu spécifique à l'utilisateur qui ne peut pas être partagé dans un cache multi-utilisateurs.

Le CDN ne met pas le contenu en cache, mais le navigateur peut toujours le mettre en cache.

Les deux solutions s'appliquent uniquement aux nouvelles requêtes. Si le fichier est déjà mis en cache, ces nouveaux paramètres n'effaceront pas automatiquement le cache sur les nœuds de bordure, de sorte que les utilisateurs pourraient toujours voir l'ancienne version. Vous devez également actualiser le cache CDN. Saisissez l'URL ou le répertoire cible et actualisez-le. Les requêtes suivantes suivront alors les nouvelles règles et récupéreront le dernier contenu depuis OSS.

Faible taux de succès du cache et récupérations fréquentes à l'origine

Dépannage

Exécutez curl -I plusieurs fois sur la même ressource et vérifiez les en-têtes de réponse Age et X-Cache. Un en-tête Age: 0 ou X-Cache: MISS indique une récupération à l'origine.

Solutions

La TTL de la règle de cache est définie sur une durée trop courte ou sur « Ne pas mettre en cache ». Ajustez les règles de mise en cache pour augmenter la durée d'expiration du cache.
La fonctionnalité « Ignorer les paramètres » est activée, mais l'URL contient des paramètres nécessaires pour le contrôle de version ou le traitement d'image, tels que ?v=1.1 ou x-oss-process. Cela amène le CDN à traiter les URL avec différents paramètres comme la même ressource, entraînant des erreurs de contenu ou des échecs de fonctionnalité. Dans ce cas, vous devez désactiver la fonctionnalité « Ignorer les paramètres ».
L'en-tête de réponse de l'origine, tel que Cache-Control: no-cache, indique au CDN de ne pas mettre le contenu en cache. Dans ce cas, ajustez la politique de mise en cache de l'origine ou configurez le CDN pour ignorer la politique de l'origine.

Faible taux de succès du cache et récupérations fréquentes à l'origine

Dépannage : Exécutez curl -I plusieurs fois sur la même ressource et vérifiez les en-têtes de réponse Age et X-Cache. Un en-tête Age: 0 ou X-Cache: MISS indique une récupération à l'origine.

Solutions :

La TTL de la règle de cache est définie sur une durée trop courte ou sur « Ne pas mettre en cache ». Ajustez les règles de mise en cache pour augmenter la durée d'expiration du cache.
La fonctionnalité « Ignorer les paramètres » est activée, mais l'URL contient des paramètres nécessaires pour le contrôle de version ou le traitement d'image, tels que ?v=1.1 ou x-oss-process. Cela amène le CDN à traiter les URL avec différents paramètres comme la même ressource, entraînant des erreurs de contenu ou des échecs de fonctionnalité. Dans ce cas, vous devez désactiver la fonctionnalité « Ignorer les paramètres ».
L'en-tête de réponse de l'origine, tel que Cache-Control: no-cache, indique au CDN de ne pas mettre le contenu en cache. Dans ce cas, vous devez soit ajuster la politique de mise en cache de l'origine, soit définir une durée d'expiration du cache dans le CDN pour remplacer la politique de l'origine.

La vidéo ne peut pas être lue car le lien est identifié comme une image

Cause : Un navigateur détermine le type de ressource à partir de l'en-tête de réponse Content-Type. Si le Content-Type d'un fichier vidéo dans OSS est incorrectement défini sur un type d'image (tel que image/jpeg), le CDN transmet cet en-tête, ce qui amène le navigateur à traiter la vidéo comme une image. Ce problème ne peut pas être résolu en ajoutant simplement des paramètres à l'URL.

Solution (choisissez-en une) :

Recommandé : Modifier l'en-tête de réponse dans la console CDN : Connectez-vous à la console CDN, accédez aux paramètres du domaine cible et ajoutez une règle pour forcer le Content-Type sur video/mp4. Vous pouvez appliquer cette règle en fonction de l'extension du fichier.
Correction à l'origine : Connectez-vous à la console OSS, recherchez le fichier vidéo correspondant et modifiez manuellement son Content-Type sur video/mp4 dans les détails du fichier.

Prise en charge des domaines accélérés par CDN par OSSBrowser

L'outil client OSSBrowser ne prend pas en charge la connexion avec un nom de domaine accéléré par CDN. Il accepte uniquement les endpoints OSS natifs.