CDN:Origin fetch troubleshooting

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

• Le serveur d'origine ne prend pas en charge HTTPS (il écoute uniquement sur le port 80), mais CDN est configuré pour effectuer la récupération d'origine via HTTPS.

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

• Le serveur d'origine s'appuie sur SNI pour sélectionner le certificat, mais CDN ne transmet pas de valeur SNI ou en transmet une incorrecte.

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

• Le serveur d'origine utilise un certificat auto-signé ou un certificat émis par une autorité de certification interne, et la validation TLS lors de la récupération d'origine échoue.

Étapes de dépannage :

• Vérifiez si le serveur d'origine prend en charge le protocole de récupération d'origine actuel : Exécutez curl -Iv https://origin-domain pour vérifier directement le serveur d'origine. Si la connexion est refusée ou expire, le serveur d'origine ne prend pas en charge HTTPS. Modifiez le protocole d'origine pour HTTP. Si le serveur d'origine prend en charge HTTPS et que le certificat est valide, vous pouvez choisir la récupération d'origine HTTPS ou le protocole Follow.

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

• Vérifiez la configuration du SNI d'origine : Lorsque le serveur d'origine héberge plusieurs sites HTTPS sur la même adresse IP, il s'appuie sur le champ SNI (Server Name Indication) dans la négociation TLS pour sélectionner le certificat SSL correspondant. Si la récupération d'origine CDN ne transmet pas de valeur SNI ou si la valeur SNI est incorrecte, le serveur d'origine ne peut pas faire correspondre le certificat correct, la négociation TLS échoue et une erreur 502 est renvoyée.

  Étapes de solution : Connectez-vous à la console CDN, choisissez Domain Management, sélectionnez le nom de domaine cible, accédez à Origin Settings et activez le SNI d'origine. Saisissez le nom de domaine que le serveur d'origine utilise réellement pour fournir des services (généralement identique au Common Name du certificat d'origine). Définissez également l'hôte d'origine sur le nom de domaine d'origine.

  Lors de la récupération d'origine, CDN valide la valeur SNI par rapport au Common Name dans le certificat du serveur d'origine. Si les deux valeurs ne peuvent vraiment pas correspondre (par exemple, le serveur d'origine utilise un certificat sur une couche d'accès unifiée), ajoutez le Common Name du certificat à la liste blanche Common Name.

  Remarque

  Le SNI d'origine est utilisé pour sélectionner le certificat lors de la négociation TLS, tandis que l'hôte d'origine est utilisé pour le routage de l'hôte virtuel au niveau HTTP. Les deux ont des objectifs différents, mais ils sont généralement définis sur le même nom de domaine d'origine.

• Vérifiez la validité du certificat SSL sur le serveur d'origine : Confirmez que le certificat n'a pas expiré et n'a pas été révoqué, et que les noms de domaine dans le certificat incluent le nom de domaine d'origine. Exécutez curl -Iv https://origin-domain 2>&1 | grep -E "expire|subject|issuer" pour afficher la période de validité, l'émetteur et les noms de domaine liés du certificat. Si le certificat a expiré ou ne correspond pas au nom de domaine, mettez à jour le certificat sur le serveur d'origine. Si le serveur d'origine utilise un certificat auto-signé ou un certificat émis par une autorité de certification interne, remplacez-le par un certificat émis par une autorité de certification publiquement fiable, ou modifiez le protocole d'origine pour HTTP.

Solution : Modifiez le protocole d'origine en fonction de la configuration réelle du serveur d'origine : le serveur d'origine prend uniquement en charge HTTP → sélectionnez HTTP (port 80 par défaut) ; le serveur d'origine prend en charge HTTPS et le certificat est valide → sélectionnez HTTPS (port 443 ou un port personnalisé) ; le serveur d'origine prend en charge les deux protocoles et le certificat est bien maintenu → vous pouvez sélectionner le protocole Follow. Pour les étapes détaillées, consultez Configurer la politique de protocole d'origine.

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

Lorsque le protocole d'origine est défini sur Follow, CDN utilise le même protocole que la requête du client pour la récupération d'origine : si un client utilise HTTP, CDN utilise HTTP pour la récupération d'origine ; si un client utilise HTTPS, CDN utilise HTTPS pour la récupération d'origine. Si un client accède à CDN via HTTPS mais que le serveur d'origine ne prend pas en charge HTTPS, la négociation TLS échoue et la requête de récupération d'origine échoue. Ce problème a la même cause que « Comment résoudre une erreur 502 renvoyée lors de la récupération d'origine ? » et peut être diagnostiqué avec les mêmes étapes de dépannage.

Solutions :

• Méthode 1 : Modifiez le protocole d'origine de Follow à HTTP afin que CDN utilise toujours HTTP pour la récupération d'origine.

• Méthode 2 : Configurez un certificat SSL sur le serveur d'origine afin que le serveur d'origine prenne en charge l'accès HTTPS. Pour plus d'informations, consultez Configurer la politique de protocole d'origine.

Une erreur 504 (Gateway Timeout) indique qu'un nœud CDN ne peut pas obtenir de réponse du serveur d'origine dans le délai spécifié lors de la récupération d'origine.

Les causes courantes incluent :

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

• Les requêtes de récupération d'origine sont supprimées par un dispositif réseau intermédiaire ou un pare-feu (lorsque les paquets SYN sont supprimés, cela se manifeste par un délai d'attente de connexion).

• Le protocole ou le port d'origine est mal configuré, de sorte que la connexion ne peut pas être établie (cela se manifeste généralement par une erreur 502, mais si le pare-feu supprime silencieusement les paquets au lieu de les refuser activement, cela peut également se manifester par une erreur 504).

• Le délai d'attente de lecture d'origine est trop court pour couvrir le temps de réponse réel du serveur d'origine.

Les délais d'attente de récupération d'origine se divisent en deux phases, qui pointent vers différentes directions de dépannage :

• Délai d'attente de la phase de connexion : Le délai d'attente pour qu'un nœud CDN établisse une connexion TCP avec le serveur d'origine est de 10 secondes. Un délai d'attente dans cette phase indique généralement que le serveur d'origine n'écoute pas sur le port d'origine, qu'un pare-feu ou un groupe de sécurité supprime les paquets SYN provenant des adresses IP de récupération d'origine CDN, ou qu'il existe une perte de paquets importante sur le chemin réseau.

• Délai d'attente de la phase de lecture : La connexion a été établie, mais le serveur d'origine ne renvoie pas de réponse complète dans le délai de lecture d'origine (30 secondes par défaut). Un délai d'attente dans cette phase indique généralement que le serveur d'origine traite les requêtes lentement, par exemple en raison de requêtes de base de données lentes, d'applications backend bloquées ou d'une charge élevée sur le serveur d'origine.

Étapes de dépannage :

1. Vérifiez si le serveur d'origine est accessible : Exécutez curl -I http(s)://origin-domain ou accédez au serveur d'origine dans un navigateur pour vérifier son temps de réponse et son code d'état. Si le serveur d'origine lui-même répond lentement ou est inaccessible, corrigez d'abord le problème de performance ou de disponibilité sur le serveur d'origine.

2. Identifiez la phase dans laquelle le temps est consommé : 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 est le temps pris pour établir la connexion TCP, time_starttransfer est le temps pris pour recevoir le premier octet, et time_total est le temps total.

   • Si time_connect est déjà significativement élevé, dépannez le réseau et le pare-feu comme un problème de phase de connexion.

   • Si time_starttransfer est beaucoup plus grand que time_connect, le traitement métier sur le serveur d'origine est lent. Optimisez le serveur d'origine.

   • Si time_total est beaucoup plus grand que time_starttransfer, le corps de la réponse est trop volumineux ou la bande passante sortante du serveur d'origine est insuffisante.

3. Vérifiez les configurations du protocole et du port d'origine : Assurez-vous que le protocole et le port d'origine configurés dans CDN correspondent à la configuration sur laquelle le serveur d'origine écoute réellement. Si le port d'origine est incorrect ou si le serveur d'origine n'écoute pas sur ce port, CDN renvoie une erreur 504 après l'expiration de la requête.

4. Vérifiez le pare-feu ou le groupe de sécurité du serveur d'origine : Si le serveur d'origine limite le débit ou bloque les plages d'adresses IP de récupération d'origine CDN, certaines requêtes peuvent expirer. Les politiques qui suppriment silencieusement les paquets SYN se manifestent directement comme des délais d'attente de phase de connexion en particulier. Ajoutez les plages d'adresses IP de récupération d'origine CDN à la liste blanche du serveur d'origine (voir Quelles sont les adresses IP des nœuds de récupération d'origine CDN).

5. Vérifiez la qualité du chemin réseau entre les nœuds CDN et le serveur d'origine : Des fluctuations réseau, une perte de paquets ou des problèmes de routage opérateur peuvent exister entre les nœuds CDN et le serveur d'origine. Utilisez des outils tels que MTR ou traceroute pour analyser le chemin (contactez le support technique Alibaba Cloud pour lancer des diagnostics depuis le côté nœud CDN).

6. Augmentez le délai d'attente de lecture d'origine : Si le temps de réponse du serveur d'origine est proche de la valeur par défaut de 30 secondes, vous pouvez augmenter le délai d'attente de la requête HTTP d'origine dans la console CDN pour réduire les erreurs 504. La valeur peut être configurée jusqu'à 150 secondes au maximum, mais nous recommandons qu'elle ne dépasse pas 60 secondes. Utilisez ceci uniquement comme atténuation temporaire. La solution fondamentale reste l'optimisation des performances de réponse du serveur d'origine.

Une erreur 503 (Service Temporarily Unavailable) indique que le serveur d'origine est temporairement incapable de traiter les requêtes. Une erreur 503 reçue lors de la récupération d'origine CDN est généralement causée par le côté serveur d'origine :

• Le programme de service web sur le serveur d'origine est anormal, n'est pas démarré ou est en cours de redémarrage.

• La charge sur le serveur d'origine est trop élevée (CPU, mémoire ou nombre de connexions sont saturés).

• Une limite de taux de requêtes par IP ou une limite de connexions simultanées est configurée sur le serveur d'origine.

• Des politiques de sécurité telles que des logiciels de sécurité de serveur (Yunsuo ou SafeDog), un WAF ou un pare-feu sur le serveur d'origine bloquent les adresses IP de récupération d'origine CDN.

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

Étapes de dépannage :

1. LieZ le fichier hosts pour reproduire le problème en accédant directement au serveur d'origine : Modifiez le fichier hosts local pour pointer le nom de domaine accéléré vers l'adresse IP du serveur d'origine, puis accédez au nom de domaine. Si l'accès direct au serveur d'origine renvoie également une erreur 503, le problème se situe côté serveur d'origine et le nœud CDN lui-même peut être exclu.

2. Vérifiez si le service web sur le serveur d'origine est normal : Confirmez que les processus de service web tels que NGINX, Apache ou IIS sont en cours d'exécution et écoutent sur le port correspondant (80/443 ou un port personnalisé). Si un processus de service est anormal ou n'est pas démarré, redémarrez le service et vérifiez les journaux de service pour localiser la cause.

3. Vérifiez la charge et la configuration de limitation de débit du serveur d'origine : Une charge CPU, mémoire ou de connexion élevée sur le serveur d'origine, ou une limite de requêtes par IP (telle que le module limit_req ou limit_conn de NGINX), peut entraîner le renvoi d'une erreur 503 pour les requêtes de récupération d'origine CDN. Évaluez si vous devez mettre à l'échelle les ressources ou ajuster les seuils de limitation de débit en fonction de votre volume de trafic.

   Remarque

   Les requêtes de récupération d'origine CDN arrivent de manière concentrée depuis un ensemble limité d'adresses IP de nœuds de récupération d'origine et sont facilement confondues avec un accès haute fréquence depuis une seule IP lorsque le serveur d'origine limite le débit par IP. Nous vous recommandons de définir un seuil de limitation de débit plus élevé pour les plages d'adresses IP de récupération d'origine CDN, ou de les exempter directement.

4. Vérifiez si des politiques de sécurité bloquent les adresses IP de récupération d'origine CDN : Des politiques de sécurité telles que le groupe de sécurité, le pare-feu, le WAF ou le logiciel de sécurité de serveur sur le serveur d'origine peuvent identifier les adresses IP de récupération d'origine CDN comme un trafic anormal et les bloquer. Recherchez les enregistrements provenant des adresses IP des nœuds CDN dans les journaux de blocage et ajoutez les plages d'adresses IP de récupération d'origine CDN à la liste blanche (pour savoir comment les obtenir, consultez Quelles sont les adresses IP des nœuds de récupération d'origine CDN).

5. Actualisez le cache CDN : Si une erreur 503 est toujours renvoyée après la récupération du serveur d'origine, effectuez une actualisation d'URL. Pour les codes d'état tels que 500, 502, 503 et 504, la priorité de mise en cache de CDN est : ne pas mettre en cache lorsque le serveur d'origine renvoie Set-Cookie → mettre en cache selon le temps d'expiration du code d'état configuré dans la console si l'un est configuré → sinon mettre en cache selon les en-têtes de réponse Pragma, Cache-Control et Expires du serveur d'origine → mettre en cache pendant 1 seconde par défaut lorsqu'aucune des conditions précédentes ne s'applique. Par conséquent, par défaut, une erreur 503 ne cause pas d'impact persistant. Cependant, si un long temps d'expiration du code d'état a été configuré pour les codes d'état 5xx dans la console, les réponses anormales continuent d'être mises en cache jusqu'à leur expiration. Dans ce cas, actualisez manuellement ou définissez le temps de cache des codes d'état 5xx sur 0 (voir Configurer l'expiration pour les codes d'état HTTP).

Symptôme

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

Étapes de dépannage

1. Vérifiez si l'hôte d'origine correspond à la configuration de l'hôte virtuel du serveur d'origine

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

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

   • IIS : Dans IIS Manager, sélectionnez le site web 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 effacer toutes les réponses d'erreur qui auraient pu être mises en cache.

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

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

Client → CDN → 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 de la redirection 301/302 d'origine n'est pas configuré, CDN renvoie la 301 au client → le navigateur suit la redirection vers HTTPS → la récupération d'origine via CDN sur HTTP se produit à nouveau → le serveur d'origine renvoie une autre 301 → ... le navigateur redirige de manière répétée et finit par signaler ERR_TOO_MANY_REDIRECTS. Si le suivi de la redirection 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 301 à l'utilisateur après que la limite de suivi est atteinte, ce qui forme également une boucle. Pour plus d'informations sur la fonctionnalité de suivi de redirection, consultez Configurer la redirection 301/302.

Solutions (choisissez-en une) :

• Solution A : Faire en sorte que CDN utilise HTTPS pour la récupération d'origine. Prérequis : le serveur d'origine possède un certificat SSL valide et écoute normalement sur le port 443. Modifiez le port d'origine pour 443 et définissez le protocole d'origine sur HTTPS. Si le serveur d'origine écoute pour 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 redirige forcement HTTP vers HTTPS. Conservez le protocole d'origine CDN sur HTTP et le port d'origine sur 80. La connexion entre les clients et CDN peut toujours utiliser HTTPS, tant que 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, elle doit être distribuée à tous les nœuds sur le réseau, ce qui prend généralement quelques minutes. Pendant cette période, certains nœuds peuvent toujours renvoyer l'ancienne réponse de redirection. Pour les politiques de cache par défaut de CDN pour divers codes d'état, consultez Configurer l'expiration pour les codes d'état HTTP.

Ce point d'entrée s'applique uniquement aux scénarios dans lesquels 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 s'est produite avant de les configurer, consultez le point d'entrée précédent « Que faire si une boucle de redirection (ERR_TOO_MANY_REDIRECTS) se produit lors de la récupération d'origine CDN après que le serveur d'origine a été configuré pour rediriger HTTP vers HTTPS ? ». La cause profonde reste que le serveur d'origine a activé une redirection forcée HTTP vers HTTPS tandis que 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 à prendre effet, donc la boucle apparaît. Effectuez le 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 « HTTP to HTTPS redirect ».

• 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 conservez les 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é offre une authentification d'accès et empêche les requêtes non autorisées de consommer du trafic. Par conséquent, nous vous déconseillons de passer le bucket en lecture publique simplement pour supprimer cette erreur.

Solution : Activez la fonctionnalité Récupération depuis des buckets OSS privés pour le nom de domaine accéléré. Une fois cette 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 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 à l'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 Identités > Rôles.

2. Dans la liste des rôles, recherchez le rôle AliyunCDNAccessingPrivateOSSRole et cliquez sur Accorder une autorisation.

   Remarque

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

3. Dans la liste des stratégies d'autorisation, sélectionnez Stratégie système, recherchez et ajoutez AliyunKMSCryptoUserAccess, puis cliquez sur Accorder des autorisations.

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

Symptôme : Le serveur d'origine utilise des redirections 302 pour servir l'interface correspondante 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 de la fonctionnalité d'adaptation aux appareils.

Solution A (recommandée) : Ne pas mettre en cache la réponse 302. Configurez le CDN pour qu'il ne mette pas en cache l'URL demandée initialement, 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 pour 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 à l'origine à chaque fois, configurez une clé de cache personnalisée qui inclut la dimension du type d'appareil, de sorte que les appareils PC et mobiles disposent chacun d'une copie de cache indépendante. Pour la méthode de configuration, consultez la rubrique Clé de cache personnalisée.

Une cause possible est que le serveur d'origine s'appuie sur des paramètres d'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 non-concordance de l'en-tête Host. Procédez au dépannage comme suit :

1. Vérifiez la configuration des paramètres d'URL dans les règles de cache : Si le serveur d'origine s'appuie sur des paramètres d'URL pour les redirections ou la logique, faites attention à la fonctionnalité « Ignorer les paramètres » du CDN. Ignorer les paramètres affecte uniquement la clé de cache. Les requêtes de récupération à l'origine transportent toujours les paramètres d'URL complets. Par conséquent, le problème n'est pas que « le serveur d'origine ne peut pas traiter la requête car les paramètres sont perdus », mais que « les requêtes avec différents paramètres atteignent le même cache et reçoivent un contenu qui n'appartient pas aux paramètres actuels ». Nous vous recommandons de désactiver 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 (consultez la rubrique 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 reprises de téléchargement é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 Range à l'origine, les nœuds CDN envoient des requêtes de tranches 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 Range à l'origine 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 pour qu'il réponde correctement avec des tranches 206, ou désactivez d'abord la fonctionnalité de récupération Range à l'origine du CDN, afin d'éviter que le CDN n'envoie des requêtes de tranches que le serveur d'origine ne peut pas gérer. Chemin de configuration : Console CDN > Gestion des domaines > nom de domaine cible > Paramètres vidéo > Récupération Range à l'origine. Cet interrupteur est désactivé par défaut. Pour plus d'informations, consultez la rubrique Configurer la récupération Range à l'origine.

3. Vérifiez si les en-têtes de réponse du serveur d'origine sont stables : La récupération Range à l'origine 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 Range à l'origine 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 Range à l'origine, 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 à l'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 à l'origine anormalement élevé. Pour plus d'informations, consultez la rubrique Configurer l'expiration pour les codes d'état HTTP.

Symptôme

Lorsqu'elle est accessible 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 la 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 la « Compression intelligente » est activée 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 (comme 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 « Ne pas mettre en cache » pour les pages dynamiques (telles que .php, .jsp ou le chemin /api/) afin de vous assurer que ces requêtes retournent toujours vers le serveur d'origine.

3. Utilisez la fonctionnalité Modifier les en-têtes de réponse entrants 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é Modifier les en-têtes de réponse entrants 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.