CDN:Guide de dépannage pour l'optimisation des performances

Les problèmes de performance dépendent de nombreux facteurs. Avant de procéder au dépannage, assurez-vous que la requête passe bien par le CDN et établissez des groupes de contrôle afin de cerner la cause racine.

Collecter les données d'accès

Un dépannage reproductible doit au moins enregistrer les informations suivantes :

• Heure UTC, région et FAI du client, adresse IP client masquée <CLIENT_IP>, LocalDNS ;

• URL de la requête, méthode de requête, code d'état, chaîne de redirection ;

• Résultat DNS, adresse IP du nœud réellement connecté ;

• X-Cache, X-Swift-CacheTime, Age (le cas échéant), Via ;

• Cache-Control, Pragma, Expires, ETag, Last-Modified, Vary ;

• Content-Type, Content-Length, Content-Encoding, Accept-Ranges, Content-Range ;

• Durée DNS, TCP, TLS, TTFB, téléchargement et durée totale ;

• Résultats de comparaison de la même requête pour la première GET CDN, la GET répétée, la GET vers un nœud spécifié et la GET directe vers l'origine.

curl -sS -D /tmp/cdn-headers.txt -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ntime_namelookup=%{time_namelookup}\ntime_connect=%{time_connect}\ntime_appconnect=%{time_appconnect}\ntime_starttransfer=%{time_starttransfer}\ntime_total=%{time_total}\nsize_download=%{size_download}\n' \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  --resolve "<CDN_DOMAIN>:443:<CDN_NODE_IP>" \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  --resolve "<CDN_DOMAIN>:443:<ORIGIN_IP>" \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  -H 'Accept-Encoding: gzip, br' \
  "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

curl -sS -D - -o /dev/null \
  -H 'Range: bytes=0-1023' \
  "https://<CDN_DOMAIN>/<LARGE_RESOURCE_PATH>"

curl -sS -D - -o /dev/null "https://<CDN_DOMAIN>/<RESOURCE_PATH>"
curl -sS -D - -o /dev/null "https://<CDN_DOMAIN>/<RESOURCE_PATH>"

Qualité réseau client-nœud médiocre ou anomalie de planification

Symptôme : Le ping vers le domaine accéléré affiche une latence élevée ou une perte de paquets ; les utilisateurs d'une région spécifique ou d'un FAI spécifique rencontrent un accès lent ; les utilisateurs sont dirigés vers des nœuds éloignés.

Causes possibles et dépannage :

• Paramètre de région d'accélération incorrect : Lorsque la région d'accélération est définie sur « Mainland China only », les utilisateurs d'outre-mer sont dirigés vers des nœuds en Chine continentale ; lorsqu'elle est définie sur « Global (excluding Mainland China) », les utilisateurs de Chine continentale sont dirigés vers des nœuds à l'étranger. Définissez la région d'accélération sur la portée correcte en fonction de la répartition des utilisateurs (par exemple, « Global »).

• Le domaine n'a pas terminé l'enregistrement ICP : Les domaines non enregistrés ne peuvent sélectionner que « Global (excluding Mainland China) ». Lorsque les utilisateurs de Chine continentale accèdent via des nœuds situés à l'étranger, le lien est plus long et la vitesse peut être insatisfaisante. Pour fournir une accélération aux utilisateurs de Chine continentale, veuillez d'abord compléter l'enregistrement ICP ; si l'enregistrement n'est pas possible, envisagez d'utiliser Edge Security Acceleration (ESA) pour réduire la latence des utilisateurs de Chine continentale accédant à des sites étrangers.

• Paramètres DNS client incorrects : Par exemple, un utilisateur à Tokyo utilisant un DNS américain peut être dirigé vers un nœud américain au lieu d'un nœud proche. Invitez l'utilisateur à passer à un DNS correspondant à son emplacement et à son FAI.

• Fluctuation du réseau régional du FAI : Lorsque la région d'accélération et le DNS sont corrects, mais que l'accès reste lent, collectez les informations traceroute et MTR pour confirmer le segment de lien spécifique où la latence se produit ; testez en liant l'adresse IP du nœud atteint par la requête utilisateur pour confirmer si le nœud lui-même répond normalement, puis combinez l'état de succès du cache et la taille de la ressource pour une analyse plus approfondie.

Faible taux de succès du cache ou récupérations fréquentes à l'origine provoquant un accès lent

Symptôme : L'en-tête de réponse X-Cache est MISS, X-Swift-CacheTime est 0 ; pression élevée sur l'origine et trafic d'origine important ; le premier accès est plus lent que l'accès direct à l'origine.

Causes courantes et solutions d'optimisation :

• Le premier accès n'a pas de cache : Le nœud doit récupérer les données depuis l'origine lors de la première réponse. Nous vous recommandons d'utiliser la fonctionnalité de préchargement d'URL pour précharger proactivement le contenu d'origine vers les nœuds CDN ; consultez Purger et précharger les ressources.

• Trafic faible et popularité insuffisante des fichiers : Le cache du nœud expulse les éléments les moins populaires en fonction de leur popularité ; les ressources à faible trafic sont expulsées plus tôt. Dans les scénarios à faible trafic, vous pouvez prolonger judicieusement la durée de mise en cache ou utiliser le préchargement pour maintenir la popularité.

• Configuration de cache déraisonnable :

  • Lorsqu'aucune règle de cache n'est configurée et que les fichiers statiques ne renvoient pas les en-têtes de réponse ETag et Last-Modified, le fichier ne peut pas être mis en cache. Veuillez ajouter ces deux en-têtes de réponse à l'origine, ou configurer des règles de cache côté CDN ; consultez Configurer l'expiration du cache CDN.

  • Lorsqu'aucune règle de cache n'est configurée, la politique de cache par défaut est utilisée, avec une durée de mise en cache maximale ne dépassant pas 3600 secondes, ce qui conduit facilement à des expirations fréquentes et à des récupérations à l'origine. Veuillez définir une durée de mise en cache raisonnable en fonction de votre activité.

  • Lorsque l'en-tête de réponse de l'origine contient l'un des éléments suivants : s-maxage=0, max-age=0, no-cache, no-store, private ou Pragma: no-cache, le contenu ne sera pas mis en cache même si des règles de cache sont configurées. Veuillez modifier l'en-tête de réponse de l'origine vers une valeur pouvant être mise en cache (comme public), ou activer Ignore Origin No-Cache Header dans la règle de cache CDN.

• L'URL contient des paramètres variables : Lorsque des URL avec des paramètres différents accèdent au même fichier, le CDN les traite comme des ressources distinctes et les récupère séparément depuis l'origine. Veuillez activer la fonctionnalité d'ignorance des paramètres ; consultez Ignorer les paramètres.

• La récupération des fichiers volumineux depuis l'origine est lente : Pour les scénarios de fichiers volumineux, nous vous recommandons d'activer la récupération à l'origine par plage (Range) afin d'optimiser l'efficacité de la récupération ; consultez Configurer la récupération à l'origine par plage.

• Actualisation fréquente du cache : Des actualisations fréquentes du cache d'URL ou de répertoire entraînent l'invalidation permanente du cache des nœuds et réduisent le taux de succès. Veuillez actualiser uniquement les ressources concernées lors de la mise à jour du contenu.

Méthode de vérification : Liez le domaine utilisateur dans le fichier hosts à l'adresse IP de l'origine et accédez-y directement, puis comparez le temps de chargement avec l'accès via le CDN pour vérifier l'effet d'accélération et confirmer si le goulot d'étranglement se situe dans la récupération à l'origine ou dans le lien de distribution. Pour plus de stratégies d'optimisation du taux de succès, consultez Dépannage du cache.

Requêtes dynamiques lentes

Symptôme : Le contenu dynamique tel que les interfaces API est lent ; les ressources statiques sont rapides, mais la page globale se charge lentement.

Cause : Le CDN ne peut pas mettre en cache le contenu dynamique qui change en temps réel. Les requêtes dynamiques sont transférées au serveur d'origine à chaque fois, de sorte que l'accélération par cache CDN n'a aucun effet sur elles. Si l'origine elle-même est lente, les requêtes dynamiques deviendront synchronement lentes.

Solution :

• Séparez le contenu statique et dynamique à l'origine : utilisez un domaine accéléré par CDN pour les ressources statiques, et un domaine qui se résout directement vers l'origine pour les requêtes dynamiques.

• Utilisez Edge Security Acceleration (ESA) pour accélérer les requêtes dynamiques grâce à l'optimisation des routes, l'optimisation du transport et d'autres technologies afin de raccourcir la chaîne vers l'origine. Notez que l'accélération dynamique est une optimisation de lien ; si le serveur d'origine lui-même est lent, l'origine doit toujours être optimisée.

La récupération à l'origine transnationale ou transfrontalière est lente

Symptôme : Lorsque l'origine et les utilisateurs principaux se trouvent dans des pays ou régions différents, la qualité de la récupération à l'origine fluctue, la récupération est lente et le taux d'échec d'origine est élevé, ce qui affecte le cache et la distribution de contenu.

Cause : La récupération à l'origine transfrontalière est affectée par la capacité des câbles sous-marins et la congestion du réseau public entre les pays.

Solution : Utilisez Global Accelerator (GA) pour fournir une accélération ciblée pour l'origine dans le pays correspondant, et configurez des politiques de récupération à l'origine spécifiques à la région CDN afin d'améliorer la qualité de la récupération en cas d'échec du cache. GA prend en charge des types d'origine tels que ECS, ALB et OSS, et propose des solutions telles que Accélérer le retour à l'origine avec GA et CDN.

La page d'accueil du site web se charge lentement

Symptôme : La requête de la page d'accueil reste longtemps en état Pending dans Network ; après le retour de la page d'accueil, les ressources statiques se chargent rapidement.

Cause : La page d'accueil est généralement une ressource dynamique ou configurée comme non cachable, donc chaque visite retourne à l'origine. Lorsque la réponse de l'origine est lente, la requête de la page d'accueil est bloquée, et les ressources ultérieures telles que les images, JS et CSS référencées par le code HTML de la page d'accueil ne peuvent pas commencer à se charger.

Solution : Confirmez d'abord via les en-têtes de réponse si la page d'accueil atteint le cache ; en cas d'échec, dépannez la configuration du cache selon la section Faible taux de succès du cache ou récupérations fréquentes à l'origine provoquant un accès lent ; si la réponse de l'origine est lente, optimisez les performances de l'origine ou adoptez la séparation statique/dynamique.

Les ressources volumineuses se chargent lentement

Symptôme : Content Download représente une grande proportion de Timing ; les ressources de la page ont une taille totale importante.

Solution : Activez les fonctionnalités d'optimisation des performances (compression intelligente, optimisation des pages, etc.) pour réduire la taille des fichiers et améliorer la vitesse de chargement ; consultez Optimisation des performances. La compression intelligente prend en charge les formats suivants : text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, text/javascript, image/tiff, image/svg+xml, application/json, application/xml.

La compression Gzip ne fonctionne pas après la récupération à l'origine

Symptôme : L'origine (comme Nginx) a activé la compression Gzip, et l'en-tête de réponse renvoie Content-Encoding: gzip lorsque le client accède directement à l'origine ; lors de l'accès via le CDN avec l'en-tête de requête contenant Accept-Encoding: gzip, deflate, l'en-tête de réponse renvoie uniquement Content-Length, et le contenu n'est pas compressé.

Cause : Les requêtes de récupération à l'origine du CDN contiennent l'en-tête de requête Via pour identifier que la requête provient d'un serveur proxy. Le module ngx_http_gzip_module de Nginx utilise la configuration gzip_proxied pour contrôler si la compression est activée pour les requêtes proxy. La valeur par défaut de cette configuration est off, donc les requêtes de récupération à l'origine depuis le CDN ne renvoient pas de contenu compressé.

Solution :

1. Définissez gzip_proxied any dans le fichier de configuration Nginx (bloc http, server ou location, selon le cas) afin que toutes les requêtes provenant de serveurs proxy soient compressées.

2. Exécutez nginx -t pour confirmer que la configuration est correcte, puis exécutez nginx -s reload pour recharger la configuration.

3. Accédez via le CDN et confirmez que l'en-tête de réponse contient Content-Encoding: gzip.

Méthode de vérification : Utilisez curl pour tester directement contre l'origine — lorsqu'aucun en-tête Via n'est envoyé, il renvoie Content-Encoding: gzip ; après avoir ajouté -H 'Via:xxx' pour simuler une requête proxy, il renvoie uniquement Content-Length. Cela confirme que le problème est causé par la configuration gzip_proxied.

Remarque : L'approche de dépannage est identique lorsque la compression Brotli ne fonctionne pas — confirmez si l'origine refuse de renvoyer du contenu compressé pour les requêtes proxy en raison de l'en-tête de requête Via ou d'une configuration similaire à gzip_proxied, et remplacez la configuration liée à Gzip par la configuration Brotli correspondante.

Compromis avec l'optimisation des pages : Si vous activez également l'optimisation des pages, notez que la compression à l'origine et l'optimisation des pages s'excluent mutuellement ; le CDN ne peut pas effectuer d'optimisation des pages après que l'origine a renvoyé du contenu compressé. Choisissez entre la compression à l'origine (économie de bande passante d'origine) et l'optimisation des pages (réduction de la taille HTML) en fonction de la priorité métier.

L'optimisation des pages ne fonctionne pas lorsque l'optimisation des pages et la compression Gzip sont toutes deux activées

Symptôme : L'optimisation des pages est activée. Lorsque curl est envoyé sans l'en-tête de requête Accept-Encoding, le code HTML renvoyé est optimisé ; mais lors de l'accès depuis un navigateur (qui envoie Accept-Encoding: gzip par défaut), le contenu renvoyé n'est pas optimisé au niveau de la page.

Cause :

• L'origine renvoie du contenu compressé Gzip : Les navigateurs portent par défaut l'en-tête de requête Accept-Encoding: gzip, et le CDN transfère cet en-tête lors de la récupération à l'origine. Lorsque l'origine a activé Gzip, elle renvoie du contenu compressé. Les nœuds CDN ne décompressent pas le contenu déjà compressé par l'origine avant d'effectuer l'optimisation des pages, de sorte que l'optimisation des pages ne peut pas prendre effet lorsque l'origine renvoie du contenu compressé.

• La compression intelligente CDN n'empêche pas l'optimisation des pages : La compression intelligente CDN s'exécute après l'optimisation des pages ; les deux ne sont pas en conflit. Ce symptôme n'apparaît que lorsque l'origine a déjà renvoyé du contenu compressé — la pré-compression par l'origine empêche le CDN d'effectuer l'optimisation des pages, et n'est pas liée à la compression intelligente côté CDN.

Solution :

• Option 1 : Assurez-vous que l'origine ne renvoie pas de contenu compressé Gzip pour les requêtes de récupération à l'origine du CDN. Pour les origines Nginx, modifiez le paramètre gzip_proxied afin que les requêtes provenant de serveurs proxy ne renvoient pas de contenu compressé.

• Option 2 : Dans la configuration CDN, supprimez Accept-Encoding de l'en-tête de requête HTTP vers l'origine afin que l'origine renvoie du contenu non compressé et que le CDN effectue l'optimisation des pages.

Remarque : Après que l'origine a cessé de renvoyer du contenu compressé, le CDN peut compresser la réponse client via la fonctionnalité de compression intelligente, réalisant ainsi à la fois l'optimisation des pages et la compression de transmission.

Exceptions métier après l'activation de l'ignorance des paramètres

Symptôme : Après l'activation de l'ignorance des paramètres, l'authentification échoue, les données utilisateur sont mélangées, un contenu mis en cache erroné est renvoyé ou le traitement d'image devient invalide.

Cause : Après l'activation de l'ignorance des paramètres, le CDN traite les requêtes avec des paramètres différents comme la même ressource pour la mise en cache. Les types de paramètres d'URL suivants ne doivent pas être ignorés globalement :

• Identifiants d'identité utilisateur (tels que UID, Token, Session ID) : les ignorer entraîne un échec d'authentification ou un mélange de données utilisateur.

• Différenciation de contenu dynamique (telle que la version ?v=1, le numéro de page ?page=2) : les ignorer renvoie le mauvais contenu mis en cache.

• Directives de traitement à l'origine (telles que le paramètre de traitement d'image OSS x-oss-process) : l'ignorer invalide le paramètre de traitement et renvoie la ressource originale non traitée.

Dépannage et solution :

1. Supprimez ou désactivez la configuration d'ignorance des paramètres.

2. Effectuez une actualisation du cache (actualisation d'URL ou de répertoire) pour effacer le cache obsolète sur les nœuds de bordure.

3. Si certains paramètres doivent être conservés, utilisez le mode de conservation des paramètres spécifiés et définissez les paramètres clés (tels que x-oss-process, token) comme conservés. Pour plus de détails sur la fonctionnalité d'ignorance des paramètres, consultez Ignorer les paramètres.

La configuration des paramètres ignorés n'est pas effective après modification

Symptôme : Après la modification de la configuration des paramètres ignorés, l'accès reste anormal ou le trafic vers l'origine n'a pas diminué.

Cause : Après la modification de la configuration, les fichiers déjà mis en cache sur les nœuds de bordure ne sont pas automatiquement mis à jour ; l'ancien cache répond toujours selon l'ancienne politique.

Étapes de dépannage :

1. Confirmer que la configuration est enregistrée : Connectez-vous à la console CDN, rouvrez la page de configuration d'ignorance des paramètres et confirmez que la configuration actuelle correspond à l'état attendu.

2. Vérifier les conflits avec la clé de cache personnalisée : La clé de cache personnalisée remplace la configuration d'ignorance des paramètres. Si la clé de cache personnalisée est activée, la configuration d'ignorance des paramètres ne prendra pas effet. Veuillez confirmer que les deux ne sont pas activées simultanément.

3. Effectuer une actualisation du cache : Sur la page Purger et précharger les ressources, effectuez une actualisation d'URL ou de répertoire. La nouvelle configuration ne pourra prendre pleinement effet qu'après l'effacement de l'ancien cache.

4. Vérifier l'effet de la configuration : Exécutez curl -I "full URL" et vérifiez l'en-tête de réponse X-Cache pour confirmer que l'état de succès du cache répond aux attentes.

Contenu incorrect du traitement d'image OSS ou de la capture de trames vidéo

Symptôme : Lors de l'utilisation du traitement d'image OSS (tel que x-oss-process=image/resize,w_200) ou de la capture de trames vidéo, l'accès renvoie l'image ou la vidéo originale non traitée, ou des requêtes avec des paramètres de traitement différents renvoient le même contenu.

Cause : Après l'activation de l'ignorance des paramètres pour le domaine CDN, le lien de l'image originale et le lien avec les paramètres de traitement sont mis en cache comme la même ressource, ce qui entraîne un contenu incorrect.

Solution : Dans la configuration d'ignorance des paramètres de la console CDN, définissez le paramètre x-oss-process en mode de conservation des paramètres spécifiés, afin que les URL avec des paramètres de traitement d'image soient mises en cache séparément et n'entrent pas en conflit avec le cache de l'image originale. Après la modification de la configuration, actualisez le cache (consultez La configuration des paramètres ignorés n'est pas effective après modification).

État de succès du cache incohérent après l'activation de l'ignorance des paramètres

Symptôme : L'ignorance des paramètres est activée, mais l'état de succès du cache est incohérent entre les clients ; certaines requêtes affichent X-Cache MISS.

Causes possibles :

1. L'URL contient des paramètres d'authentification dynamique non ignorés : Par exemple, l'URL possède auth_key et d'autres paramètres d'authentification définis comme conservés. Chaque requête ayant une valeur d'authentification différente, le CDN les reconnaît toujours comme des ressources distinctes.

2. Le premier accès n'a pas de cache sur le nœud : La ressource n'a pas encore été mise en cache sur ce nœud de bordure, donc le premier accès affichera inévitablement MISS.

3. Différences d'en-têtes de requête client : Par exemple, différents Accept-Encoding peuvent déclencher une mise en cache multi-copies (versions Gzip et non-Gzip mises en cache séparément). Si l'origine renvoie Vary: User-Agent, les requêtes provenant de différents UA seront également mises en cache séparément.

4. Conflit avec la clé de cache personnalisée : La clé de cache personnalisée remplace la configuration d'ignorance des paramètres ; lorsque les deux sont activées, l'ignorance des paramètres ne prend pas effet.

Méthode de dépannage : Sur le client, exécutez curl -I "full URL" et comparez les en-têtes de réponse X-Cache et X-Swift-CacheTime pour confirmer l'état du cache. Solution : Confirmez que la configuration d'ignorance des paramètres est correcte (activée et les paramètres clés sont conservés), assurez une stratégie cohérente d'en-têtes de requête client et confirmez que la clé de cache personnalisée n'est pas activée simultanément.