CDN:Origin fetch troubleshooting

Un nœud CDN, agissant comme une passerelle, renvoie une erreur 502 (Bad Gateway) lorsqu'il ne parvient pas à obtenir une réponse valide du serveur d'origine. Un échec à l'une des étapes suivantes du chemin de requête vers l'origine peut provoquer cette erreur :

• Le serveur d'origine ne prend pas en charge HTTPS (il écoute uniquement sur le port 80), mais la configuration CDN impose une requête vers l'origine via HTTPS.

• Le port d'origine configuré ne correspond pas au port sur lequel le serveur d'origine écoute réellement.

• Le serveur d'origine s'appuie sur le SNI pour sélectionner le certificat, mais la requête CDN ne transmet aucune valeur SNI ou en transmet une incorrecte.

• Le certificat SSL du serveur d'origine a expiré, est invalide ou ne correspond pas au nom de domaine.

• Le serveur d'origine utilise un certificat auto-signé ou émis par une autorité de certification interne, ce qui entraîne l'échec de la validation TLS lors de la requête vers l'origine.

Étapes de dépannage :

• Vérifiez si le serveur d'origine prend en charge le protocole de requête actuel : Exécutez curl -Iv https://origin-domain pour tester directement le serveur d'origine. Si la connexion est refusée ou expire, le serveur ne prend pas en charge HTTPS. Modifiez le protocole d'origine pour utiliser HTTP. Si le serveur prend en charge HTTPS et que le certificat est valide, vous pouvez choisir la requête HTTPS ou suivre le protocole du client.

• Vérifiez la concordance entre le port d'origine et le port d'écoute du serveur : Le port par défaut est 443 pour HTTPS et 80 pour HTTP. Si le serveur utilise un port personnalisé (de 1 à 65535), spécifiez-le dans la configuration du protocole d'origine.

• Vérifiez la configuration SNI d'origine : Lorsque plusieurs sites HTTPS sont hébergés sur la même adresse IP, le serveur d'origine utilise le champ SNI (Server Name Indication) lors de la négociation TLS pour sélectionner le certificat SSL approprié. Si la requête CDN omet la valeur SNI ou en fournit une erronée, le serveur ne peut pas associer le bon certificat, la négociation TLS échoue et une erreur 502 est renvoyée.

  Solution : Connectez-vous à la console CDN, accédez à Domain Management, sélectionnez le domaine concerné, puis allez dans Origin Settings. Activez l'option SNI d'origine. Saisissez le nom de domaine effectivement utilisé par le serveur d'origine (généralement identique au Common Name du certificat). Définissez également l'hôte d'origine sur ce même nom de domaine.

  Lors de la requête, le CDN compare la valeur SNI au Common Name du certificat du serveur d'origine. Si une correspondance exacte est impossible (par exemple, si le serveur utilise un certificat sur une couche d'accès unifiée), ajoutez le Common Name du certificat à la liste blanche des Common Names.

  Remarque

  Le SNI d'origine sert à sélectionner le certificat lors de la négociation TLS, tandis que l'hôte d'origine gère le routage des hôtes virtuels au niveau HTTP. Bien que leurs rôles diffèrent, ils sont généralement configurés avec le même nom de domaine d'origine.

• Vérifiez la validité du certificat SSL du serveur d'origine : Assurez-vous que le certificat n'a ni expiré ni été révoqué, et qu'il couvre le nom de domaine d'origine. Exécutez curl -Iv https://origin-domain 2>&1 | grep -E "expire|subject|issuer" pour consulter la période de validité, l'émetteur et les domaines associés. Si le certificat est expiré ou inadéquat, mettez-le à jour. Pour les certificats auto-signés ou internes, remplacez-les par un certificat émis par une autorité publique reconnue ou basculez le protocole d'origine sur HTTP.

Solution : Adaptez le protocole d'origine à la configuration réelle du serveur : si le serveur ne supporte que HTTP, sélectionnez HTTP (port 80 par défaut) ; s'il supporte HTTPS avec un certificat valide, sélectionnez HTTPS (port 443 ou personnalisé) ; s'il supporte les deux protocoles avec une maintenance correcte des certificats, choisissez l'option « Follow ». Pour plus de détails, consultez la rubrique Configuration de la politique de protocole d'origine.

Comment résoudre une erreur 502 lorsque le protocole d'origine est défini sur « Follow » ?

Avec le paramètre « Follow », le CDN utilise le même protocole que la requête cliente pour contacter l'origine : HTTP reste HTTP, HTTPS reste HTTPS. Si un client accède au CDN via HTTPS alors que le serveur d'origine ne le supporte pas, la négociation TLS échoue, provoquant l'échec de la requête. La cause racine et les étapes de diagnostic sont identiques à celles décrites pour l'erreur 502 générale.

Solutions :

• Méthode 1 : Remplacez le protocole d'origine « Follow » par HTTP afin que le CDN utilise systématiquement HTTP pour ses requêtes vers l'origine.

• Méthode 2 : Configurez un certificat SSL sur le serveur d'origine pour qu'il prenne en charge HTTPS. Pour plus d'informations, voir Configuration de la politique de protocole d'origine.

Une erreur 504 (Gateway Timeout) signifie qu'un nœud CDN n'a pas reçu de réponse du serveur d'origine dans le délai imparti.

Les causes fréquentes incluent :

• Le serveur d'origine répond lentement ou le service est indisponible.

• Les requêtes sont bloquées par un équipement réseau intermédiaire ou un pare-feu (le rejet silencieux des paquets SYN se manifeste par un délai d'attente de connexion).

• Une mauvaise configuration du protocole ou du port empêche l'établissement de la connexion (cela provoque souvent une erreur 502, mais peut aussi mener à une 504 si le pare-feu ignore silencieusement les paquets).

• Le délai d'attente de lecture depuis l'origine est trop court par rapport au temps de réponse réel du serveur.

Les délais d'attente se divisent en deux phases, orientant le dépannement :

• Délai lors de la phase de connexion : Le CDN dispose de 10 secondes pour établir une connexion TCP avec l'origine. Un échec ici indique généralement que le serveur n'écoute pas sur le port configuré, qu'un pare-feu ou un groupe de sécurité bloque les paquets SYN provenant des adresses IP des nœuds CDN, ou qu'il existe une perte de paquets importante sur le trajet réseau.

• Délai lors de la phase de lecture : La connexion est établie, mais le serveur ne renvoie pas de réponse complète dans le délai de lecture (30 secondes par défaut). Cela suggère un traitement lent côté serveur, dû par exemple à des requêtes de base de données lourdes, des applications backend bloquées ou une charge élevée.

Étapes de dépannage :

1. Vérifiez l'accessibilité du serveur d'origine : Exécutez curl -I http(s)://origin-domain ou accédez-y via un navigateur pour observer le temps de réponse et le code d'état. Si le serveur est lent ou inaccessible, corrigez d'abord ses problèmes de performance ou de disponibilité.

2. Identifiez la phase consommatrice de temps : Exécutez la commande suivante :

   curl -o /dev/null -s -w "time_connect:%{time_connect} time_starttransfer:%{time_starttransfer} time_total:%{time_total}\n" http(s)://origin-domain/resource-path

   time_connect représente le temps d'établissement de la connexion TCP, time_starttransfer celui jusqu'à la réception du premier octet, et time_total la durée totale.

   • Si time_connect est déjà élevé, investiguez le réseau et le pare-feu (problème de phase de connexion).

   • Si time_starttransfer est bien supérieur à time_connect, le traitement métier sur le serveur d'origine est lent. Optimisez le serveur.

   • Si time_total dépasse largement time_starttransfer, le corps de la réponse est trop volumineux ou la bande passante sortante du serveur est insuffisante.

3. Vérifiez les configurations de protocole et de port d'origine : Assurez-vous que les paramètres CDN correspondent à ceux du serveur d'origine. Un port incorrect ou non écouté entraîne une erreur 504 après expiration du délai.

4. Examinez le pare-feu ou le groupe de sécurité du serveur d'origine : Si le serveur limite ou bloque les plages d'IP des nœuds CDN, certaines requêtes expireront. Les politiques rejetant silencieusement les paquets SYN causent spécifiquement des délais lors de la phase de connexion. Ajoutez les plages d'IP des nœuds CDN à la liste blanche du serveur (voir Quelles sont les adresses IP des nœudes de requête vers l'origine du CDN ?).

5. Contrôlez la qualité du trajet réseau entre les nœuds CDN et l'origine : Des fluctuations, pertes de paquets ou problèmes de routage opérateur peuvent survenir. Utilisez des outils comme MTR ou traceroute pour analyser le trajet (contactez le support technique Alibaba Cloud pour lancer un diagnostic depuis le nœud CDN).

6. Augmentez le délai d'attente de lecture depuis l'origine : Si le temps de réponse du serveur approche les 30 secondes par défaut, augmentez le délai d'attente des requêtes HTTP vers l'origine dans la console CDN pour réduire les erreurs 504. La valeur maximale est de 150 secondes, mais il est recommandé de ne pas dépasser 60 secondes. Cette mesure est temporaire ; l'optimisation des performances du serveur d'origine reste la solution fondamentale.

Une erreur 503 (Service Temporarily Unavailable) indique que le serveur d'origine ne peut pas traiter les requêtes momentanément. Lors d'une requête CDN, cette erreur provient généralement du côté du serveur d'origine :

• Le service web du serveur d'origine est défaillant, arrêté ou en cours de redémarrage.

• La charge du serveur est excessive (CPU, mémoire ou nombre de connexions saturés).

• Des limites de taux de requêtes ou de connexions simultanées par IP sont configurées sur le serveur.

• Des politiques de sécurité (logiciels tels que Yunsuo ou SafeDog, WAF, pare-feu) bloquent les adresses IP des nœuds CDN.

• Le serveur est en mode maintenance ou en cours de déploiement.

Étapes de dépannage :

1. Modifiez le fichier hosts local pour reproduire le problème en accédant directement au serveur d'origine : Pointez le nom de domaine accéléré vers l'adresse IP du serveur d'origine dans votre fichier hosts, puis accédez au domaine. Si l'accès direct renvoie aussi une erreur 503, le problème vient du serveur d'origine et non du nœud CDN.

2. Vérifiez le bon fonctionnement du service web sur le serveur d'origine : Confirmez que les processus NGINX, Apache ou IIS sont actifs et écoutent sur le port approprié (80/443 ou personnalisé). En cas d'anomalie, redémarrez le service et examinez les journaux pour identifier la cause.

3. Contrôlez la charge et les limites de débit du serveur d'origine : Une saturation des ressources (CPU, mémoire, connexions) ou des limites par IP (comme les modules limit_req ou limit_conn de NGINX) peuvent générer des erreurs 503. Évaluez la nécessité d'augmenter les ressources ou d'ajuster les seuils de limitation selon votre trafic.

   Remarque

   Les requêtes CDN proviennent d'un ensemble restreint d'adresses IP de nœuds, ce qui peut être interprété à tort comme un accès intensif depuis une seule IP par les mécanismes de limitation du serveur. Il est recommandé d'augmenter les seuils de limitation pour les plages d'IP CDN ou de les exempter.

4. Vérifiez si des politiques de sécurité bloquent les adresses IP des nœuds CDN : Les groupes de sécurité, pare-feux, WAF ou logiciels de sécurité peuvent identifier le trafic CDN comme anormal et le bloquer. Recherchez les entrées correspondant aux IPs des nœuds dans les journaux de blocage et ajoutez les plages d'IP CDN à la liste blanche (voir Quelles sont les adresses IP des nœudes de requête vers l'origine du CDN ?).

5. Actualisez le cache CDN : Si l'erreur 503 persiste après le rétablissement du serveur, effectuez une actualisation d'URL. Pour les codes 500, 502, 503 et 504, la priorité de mise en cache du CDN est la suivante : pas de cache si le serveur renvoie Set-Cookie → application du délai d'expiration configuré dans la console le cas échéant → sinon, respect des en-têtes Pragma, Cache-Control et Expires du serveur → cache par défaut d'une seconde si aucune condition précédente n'est remplie. Par défaut, une erreur 503 n'a donc pas d'impact durable. Toutefois, si un long délai d'expiration a été configuré pour les codes 5xx dans la console, les réponses erronées restent en cache jusqu'à expiration. Dans ce cas, actualisez manuellement le cache ou définissez la durée de cache des codes 5xx à 0 (voir Configuration de l'expiration pour les codes d'état HTTP).

Symptôme

Les serveurs d'origine distinguent généralement les sites virtuels via l'en-tête de requête Host. Si l'hôte d'origine configuré dans le CDN ne correspond pas au nom de domaine attendu par le serveur, celui-ci peut renvoyer des erreurs telles que 404, 403 ou 500.

Étapes de dépannage

1. Vérifiez la concordance entre l'hôte d'origine et la configuration de l'hôte virtuel du serveur

   • NGINX : Vérifiez si server_name contient le nom de domaine configuré comme hôte d'origine.

   • Apache : Vérifiez ServerName / ServerAlias dans la directive <VirtualHost>.

   • IIS : Dans le gestionnaire IIS, sélectionnez le site cible > Bindings, et vérifiez si le champ « Host name » correspond à l'hôte d'origine.

2. Actualisez le cache CDN

Après avoir modifié la configuration de l'hôte d'origine, effectuez une actualisation d'URL pour supprimer les réponses d'erreur potentiellement mises en cache.

Symptôme : Le site web renvoie une erreur « Too many redirects » ou « ERR_TOO_MANY_REDIRECTS », ou bien les ressources telles que les images, les fichiers CSS et les fichiers JavaScript ne se chargent pas.

Cause : Le serveur d'origine répond activement par une redirection forcée de HTTP vers HTTPS (une règle courante dans des services tels qu'aaPanel, WAF et NGINX), mais le protocole d'origine du CDN est défini sur HTTP. Par conséquent, le chemin de la requête forme une boucle :

Client → CDN → Le CDN effectue la récupération d'origine via HTTP (port 80) → le serveur d'origine renvoie une redirection 301 vers HTTPS → si le suivi des redirections 301/302 d'origine n'est pas configuré, le CDN renvoie la redirection 301 au client → le navigateur suit la redirection vers HTTPS → la récupération d'origine via le CDN sur HTTP se produit à nouveau → le serveur d'origine renvoie une autre redirection 301 → ... le navigateur effectue des redirections répétées et finit par signaler ERR_TOO_MANY_REDIRECTS. Si le suivi des redirections 301/302 d'origine est activé, les nœuds CDN suivent les redirections de manière répétée sur le chemin de récupération d'origine et renvoient la redirection 301 à l'utilisateur une fois la limite de suivi atteinte, ce qui forme également une boucle. Pour plus d'informations sur la fonctionnalité de suivi des redirections, consultez Configurer la redirection 301/302.

Solutions (choisissez-en une) :

• Solution A : Configurer le CDN pour utiliser HTTPS pour la récupération d'origine. Prérequis : le serveur d'origine dispose d'un certificat SSL valide et écoute normalement sur le port 443. Modifiez le port d'origine pour le définir sur 443 et configurez le protocole d'origine sur HTTPS. Si le serveur d'origine écoute plusieurs noms de domaine, définissez également le SNI d'origine et l'hôte d'origine sur le nom de domaine accéléré ou le nom de domaine d'origine.

• Solution B : Désactiver la redirection forcée sur le serveur d'origine et conserver la communication HTTP. Connectez-vous au serveur d'origine et désactivez la règle qui force la redirection de HTTP vers HTTPS. Conservez le protocole d'origine du CDN sur HTTP et le port d'origine sur 80. La connexion entre les clients et le CDN peut toujours utiliser HTTPS, tant que le CDN et le serveur d'origine s'accordent sur le même protocole.

Opération supplémentaire (recommandée quelle que soit la solution choisie) : Exécutez une tâche d'actualisation d'URL pour effacer les réponses de redirection mises en cache afin que la nouvelle configuration prenne effet immédiatement. Après la modification de la configuration, celle-ci doit être distribuée à tous les nœuds du réseau, ce qui prend généralement quelques minutes. Pendant cette période, certains nœuds peuvent encore renvoyer l'ancienne réponse de redirection. Pour connaître les politiques de mise en cache par défaut du CDN pour les différents codes d'état, consultez Configurer l'expiration pour les codes d'état HTTP.

Cette rubrique s'applique uniquement aux scénarios où la boucle de redirection apparaît uniquement après avoir configuré l'hôte d'origine ou le SNI d'origine. Si la boucle de redirection existait avant cette configuration, reportez-vous à la section précédente « Que faire si une boucle de redirection (ERR_TOO_MANY_REDIRECTS) se produit lors de la récupération d'origine CDN après avoir configuré le serveur d'origine pour rediriger HTTP vers HTTPS ? ». La cause profonde reste la même : le serveur d'origine a activé une redirection forcée de HTTP vers HTTPS tandis que le CDN effectue la récupération d'origine via HTTP. Après avoir modifié l'hôte d'origine ou le SNI d'origine, le serveur d'origine fait correspondre le site attendu et la règle de redirection forcée commence à s'appliquer, ce qui provoque la boucle. Procédez au dépannage comme suit :

• Désactivez la redirection HTTPS forcée sur le serveur d'origine : Connectez-vous à la console de gestion du serveur d'origine (par exemple, aaPanel), accédez aux paramètres HTTPS et désactivez l'option « Force HTTPS » ou « Redirection HTTP vers HTTPS ».

• Assurez-vous que l'hôte d'origine et le SNI d'origine sont cohérents et corrects : Sur la page des paramètres d'origine, définissez l'hôte d'origine et le SNI d'origine sur le nom de domaine correct (généralement le nom de domaine d'origine) et maintenez ces deux valeurs cohérentes afin que les requêtes de récupération d'origine répondent aux attentes du serveur d'origine.

• Actualisez le cache CDN : Après avoir ajusté la configuration, actualisez le cache CDN pour effacer les réponses de redirection mises en cache.

Cette erreur indique que les autorisations d'accès du bucket OSS sont privées et que les requêtes sans signature ne peuvent pas lire les objets du bucket. Un bucket privé fournit une authentification d'accès et empêche les requêtes non autorisées de consommer du trafic. Par conséquent, il n'est pas recommandé de passer le bucket en lecture publique simplement pour supprimer cette erreur.

Solution : Activez la fonctionnalité Configurer la récupération d'origine depuis un bucket OSS privé pour le nom de domaine accéléré. Une fois la fonctionnalité activée, le CDN utilise automatiquement le rôle de service AliyunCDNAccessingPrivateOSSRole pour inclure une signature lors de l'accès au bucket privé, et les utilisateurs finaux n'ont pas besoin de signatures supplémentaires lorsqu'ils accèdent aux ressources via le CDN. Chemin d'accès : Console CDN > Gestion des domaines > nom de domaine cible > Paramètres d'origine > Récupération d'origine depuis des buckets OSS privés.

Si votre bucket OSS est chiffré avec Key Management Service (KMS), vous devez accorder au rôle de récupération d'origine du CDN des autorisations supplémentaires pour utiliser la clé KMS. Sinon, le CDN ne peut pas déchiffrer ni accéder à ces fichiers, et l'erreur This request is forbidden by kms. est renvoyée.

Solution :

1. Connectez-vous à la console RAM. Dans le volet de navigation de gauche, choisissez Identities > Roles.

2. Dans la liste des rôles, recherchez le rôle AliyunCDNAccessingPrivateOSSRole et cliquez sur Grant Permission.

   Remarque

   Si vous ne trouvez pas le rôle, cela signifie que la fonctionnalité de récupération d'origine depuis des buckets OSS privés n'a jamais été activée. Activez d'abord la fonctionnalité comme décrit dans Configurer la récupération d'origine depuis un bucket OSS privé. Le rôle est créé automatiquement. Revenez ensuite effectuer cette étape.

3. Dans la liste des stratégies d'autorisation, sélectionnez System Policy, recherchez et ajoutez AliyunKMSCryptoUserAccess, puis cliquez sur Grant permissions.

4. Utilisez la fonctionnalité Actualisation et préchargement. Une fois la tâche d'actualisation terminée, accédez à nouveau à la ressource.

Ce problème survient lorsque les trois conditions suivantes sont réunies : les autorisations du bucket OSS sont privées, l'hébergement de site web statique OSS est activé et la fonctionnalité Configurer la récupération d'origine depuis un bucket OSS privé est activée dans le CDN. Lorsque vous accédez au chemin racine du nom de domaine accéléré (par exemple, https://example.com/), une erreur 403 Forbidden est renvoyée et l'en-tête de réponse contient x-tengine-error: You are forbidden to list buckets.

Cause : La fonctionnalité de récupération d'origine depuis des buckets OSS privés du CDN entre en conflit avec la configuration de la page d'accueil par défaut de l'hébergement de site web statique OSS.

Solutions :

• Solution 1 : Si vous n'avez pas besoin de l'hébergement de site web statique OSS, désactivez la configuration d'hébergement de site web statique pour le bucket. Pour obtenir des instructions, consultez Hébergement de site web statique.

• Solution 2 : Si vous devez conserver l'hébergement de site web statique, configurez une règle de réécriture d'URI dans le CDN pour empêcher les requêtes de récupération d'origine ciblant le répertoire racine : définissez Path to Be Rewritten sur ^/$, définissez Target Path sur /index.html et définissez Flag sur Redirect. Une fois la règle configurée, lorsqu'un client demande le chemin racine, le nœud CDN renvoie une redirection 302 indiquant au client de demander /index.html. Pour les étapes détaillées, consultez Réécrire les URL d'accès.

Symptôme : Le serveur d'origine utilise des redirections 302 pour servir l'interface appropriée en fonction du type d'appareil client. Après l'activation du CDN, la réponse 302 est mise en cache lorsque le premier utilisateur accède à la ressource. Les utilisateurs d'autres types d'appareils qui accèdent à la même URL obtiennent alors la page 302 mise en cache du premier utilisateur, ce qui entraîne l'arrêt du fonctionnement de la fonctionnalité d'adaptation aux appareils.

Solution A (recommandée) : Ne pas mettre en cache la réponse 302. Configurez le CDN de manière à ne pas mettre en cache l'URL initialement demandée, mais plutôt la page après la redirection 302. Vous pouvez configurer le serveur d'origine pour qu'il ne mette pas en cache la page initiale (la politique no-cache du serveur d'origine a une priorité élevée pour le CDN). Tant que la réponse de cette page contient l'un des en-têtes de réponse suivants, la page n'est pas mise en cache :

• Cache-control:no-cache, no-store

• Cache-control:max-age=0

• pragma:no-cache

• Cache-control:private

Solution B : Configurez le CDN pour qu'il ne mette pas en cache l'URL initiale. Si vous ne pouvez pas modifier les en-têtes de réponse du serveur d'origine, combinez les configurations de cache du CDN pour les répertoires et les extensions de nom de fichier avec leurs priorités afin de définir la durée de mise en cache de l'URL de redirection initiale à 0, tandis que les autres URL continuent d'être mises en cache normalement.

Solution C : Utilisez une clé de cache personnalisée pour distinguer les types d'appareils. Si vous souhaitez conserver la capacité de mise en cache au lieu de récupérer les données depuis l'origine à chaque fois, configurez une clé de cache personnalisée incluant la dimension du type d'appareil, afin que les ordinateurs et les appareils mobiles disposent chacun d'une copie de cache indépendante. Pour la méthode de configuration, consultez Clé de cache personnalisée.

Une cause possible est que le serveur d'origine s'appuie sur des paramètres URL ou un en-tête Host spécifique pour sa logique, tandis que le comportement par défaut du CDN peut entraîner la perte de paramètres ou une inadéquation de l'en-tête Host. Procédez au dépannage comme suit :

1. Vérifiez la configuration des paramètres URL dans les règles de cache : Si le serveur d'origine s'appuie sur des paramètres URL pour les redirections ou la logique, prêtez attention à la fonctionnalité « Ignorer les paramètres » du CDN. L'option Ignorer les paramètres affecte uniquement la clé de cache. Les requêtes de récupération d'origine transportent toujours tous les paramètres URL. Par conséquent, le problème ne réside pas dans le fait que « le serveur d'origine ne peut pas traiter la requête car les paramètres sont perdus », mais dans le fait que « les requêtes avec différents paramètres atteignent le même cache et reçoivent du contenu qui n'appartient pas aux paramètres actuels ». Nous vous recommandons de désactiver l'option Ignorer les paramètres, ou de conserver les paramètres qui affectent la logique métier, afin que les requêtes avec différents paramètres soient mises en cache indépendamment (voir Ignorer les paramètres).

2. Définissez l'hôte d'origine sur le nom de domaine attendu par le serveur d'origine : Cela garantit que le serveur d'origine identifie correctement l'en-tête host de la requête et traite la logique de redirection.

3. Exécutez une tâche d'actualisation de répertoire ou d'URL : Après avoir modifié la configuration, exécutez une tâche d'actualisation de répertoire ou d'URL pour appliquer la nouvelle configuration.

Symptôme : Les téléchargements de fichiers volumineux sont interrompus, les téléchargements repris échouent, ou la recherche vidéo renvoie une erreur ou lit la vidéo depuis le début.

Cause : Après l'activation de la récupération d'origine Range, les nœuds CDN envoient des requêtes de tranche avec un en-tête Range au serveur d'origine. Si le serveur d'origine ne prend pas en charge les requêtes Range (il ignore l'en-tête Range et renvoie 200 avec le contenu complet), ou si le Content-Range renvoyé ne correspond pas à la plage demandée, des exceptions de cache ou des échecs de requête client peuvent se produire.

Étapes de dépannage :

1. Vérifiez si le serveur d'origine prend en charge les requêtes Range : Exécutez curl -I -H "Range: bytes=0-1023" http(s)://origin-domain/resource-path. Si 206 Partial Content est renvoyé avec un en-tête Content-Range correct, le serveur d'origine prend en charge Range. Si 200 OK est renvoyé avec le fichier complet, le serveur d'origine ignore les requêtes Range.

2. Ajustez la configuration de la récupération d'origine Range en fonction des capacités du serveur d'origine : Si le serveur d'origine ne prend pas en charge Range, modifiez d'abord le serveur d'origine afin qu'il réponde correctement avec des tranches 206, ou désactivez d'abord la fonctionnalité de récupération d'origine Range du CDN, pour éviter que le CDN n'envoie des requêtes de tranche que le serveur d'origine ne peut pas gérer. Chemin de configuration : console CDN > Domain Management > nom de domaine cible > Video Settings > Range Origin Fetch. Ce commutateur est désactivé par défaut. Pour plus d'informations, consultez Configurer la récupération d'origine range.

3. Vérifiez si les en-têtes de réponse du serveur d'origine sont stables : La récupération d'origine Range nécessite que le serveur d'origine renvoie un Content-Length, un ETag et un Last-Modified stables pour la même ressource, afin que le CDN puisse déterminer que les tranches appartiennent à la même version du fichier. Si le serveur d'origine génère du contenu dynamiquement et ne peut pas fournir ces en-têtes de réponse, la récupération d'origine Range n'est pas fiable.

4. Vérifiez si les tranches mises en cache ont été effacées : Lors de l'utilisation de la récupération d'origine Range, si un nœud CDN reçoit un code d'état autre que 206 du serveur d'origine, il supprime les fichiers de tranche mis en cache (les délais d'attente de récupération d'origine ne provoquent pas de suppression). Par conséquent, si le serveur d'origine renvoie intermittemment des réponses 5xx, les tranches mises en cache sont effacées à plusieurs reprises. Cela se manifeste par des interruptions répétées des téléchargements et un trafic de récupération d'origine anormalement élevé. Pour plus d'informations, consultez Configurer l'expiration pour les codes d'état HTTP.

Symptôme

Lorsqu'on y accède via le CDN, la page est illisible ou le navigateur signale un échec de décodage (ERR_CONTENT_DECODING_FAILED).

Cause

• Le serveur d'origine a renvoyé du contenu compressé (gzip/br) sans définir l'en-tête de réponse Content-Encoding . Le CDN compresse à nouveau le contenu déjà compressé avant de le renvoyer, ce qui provoque une exception de décodage sur le client.

• Le Content-Encoding déclaré par le serveur d'origine ne correspond pas à l'encodage réel.

Étapes de dépannage

1. Comparez les en-têtes de réponse du serveur d'origine et du CDN

# Direct access to the origin server
curl -I -H "Accept-Encoding: gzip" https://<origin-domain>/<resource-path>

# Access through CDN
curl -I -H "Accept-Encoding: gzip" https://<accelerated-domain>/<resource-path>

Vérifiez si Content-Encoding, Content-Length et Content-Type sont cohérents des deux côtés.

2. Vérifiez la configuration de compression intelligente du CDN

Si le serveur d'origine renvoie déjà du contenu compressé (les en-têtes de réponse contiennent Content-Encoding: gzip), le CDN ne doit pas le compresser à nouveau. En cas de double compression, vérifiez si « Intelligent Compression » est activé dans la console CDN, ou désactivez la compression côté CDN et laissez le serveur d'origine gérer entièrement la compression.

3. Corrigez les en-têtes de réponse du serveur d'origine

Assurez-vous que chaque fois que le serveur d'origine renvoie du contenu compressé, il définit également l'en-tête Content-Encoding correct. Sinon, le CDN ne peut pas identifier que le contenu est déjà compressé.

Symptôme

Lorsque différents utilisateurs accèdent à la même page, un utilisateur reçoit les informations de session d'un autre utilisateur (par exemple, un état de connexion mélangé), ou l'état de connexion expire immédiatement après la connexion.

Cause

Le serveur d'origine renvoie un en-tête Set-Cookie dans la réponse d'une page dynamique. Si cette réponse est mise en cache par le CDN, les autres utilisateurs qui atteignent le cache reçoivent un Cookie qui ne leur appartient pas, ce qui mélange les informations de session.

Solution

1. Configurez le serveur d'origine pour qu'il ne mette pas en cache les réponses contenant Set-Cookie

Ajoutez Cache-Control: no-store ou Cache-Control: private aux pages dynamiques sur le serveur d'origine pour empêcher le CDN de mettre en cache les réponses contenant des informations spécifiques à l'utilisateur.

2. Configurez les règles de cache côté CDN

Dans la console CDN, configurez une règle « Do Not Cache » pour les pages dynamiques (telles que .php, .jsp ou le chemin /api/) afin de garantir que ces requêtes retournent toujours vers le serveur d'origine.

3. Utilisez la fonctionnalité Modify Inbound Response Headers du CDN pour supprimer l'en-tête de réponse

Si vous confirmez que Set-Cookie est inutile pour les scénarios de mise en cache du CDN (tels que les cookies de suivi), vous pouvez configurer la fonctionnalité Modify Inbound Response Headers côté CDN pour supprimer l'en-tête de réponse Set-Cookie avant la mise en cache. Assurez-vous que cela n'affecte pas la logique métier.