Si une requête adressée à une ressource accélérée par le CDN renvoie une erreur 403, ou si votre nom de domaine présente des anomalies de trafic ou un vol de trafic malveillant suspecté, utilisez les catégories de symptômes décrites dans cette rubrique pour identifier la cause et résoudre le problème. Cette rubrique traite uniquement du dépannage. Pour les questions relatives à la configuration et à l'assistance, consultez la section FAQ sur le contrôle d'accès.
Référence rapide des symptômes
Utilisez curl -v ou les outils de développement du navigateur pour vérifier le champ X-Tengine-Error dans les en-têtes de réponse, puis identifiez la cause à l'aide du tableau suivant :
Remarque : Si le champ X-Tengine-Error existe dans les en-têtes de réponse mais que sa valeur ne figure pas dans le tableau précédent, ou si l'authentification distante est activée pour le nom de domaine, consultez la section Erreurs 403 causées par l'authentification distante.
Comment déterminer si l'erreur 403 est renvoyée par le CDN ou par le serveur d'origine ?
Si une requête adressée à une ressource accélérée renvoie une erreur 403, déterminez d'abord l'origine de l'erreur, puis procédez au dépannage en fonction de la famille de symptômes correspondante :
Si les en-têtes de réponse ne contiennent pas le champ X-Tengine-Error, modifiez le fichier hosts local pour mapper le nom de domaine accéléré à l'adresse IP du serveur d'origine, puis accédez directement au serveur d'origine pour vérifier. Si le serveur d'origine renvoie également une erreur 403, sa politique de contrôle d'accès a bloqué la requête. Consultez la section Erreurs 403 renvoyées par le serveur d'origine. Pour les méthodes générales de dépannage côté serveur d'origine, consultez le Guide de dépannage de la récupération d'origine.
Erreurs 403 causées par l'authentification URL
Une fois l'authentification URL activée, le CDN renvoie une erreur 403 si une requête ne contient pas le paramètre de signature ou si ce paramètre est invalide. Utilisez le message X-Tengine-Error: denied by req auth présent dans les en-têtes de réponse pour déterminer la cause spécifique.
Remarque : L'authentification URL contrôle uniquement les permissions d'accès ; le résultat de l'authentification n'affecte pas le comportement de mise en cache du CDN. Une fois l'authentification réussie, le nœud CDN supprime le paramètre de signature (tel que auth_key) de l'URL et utilise l'URL d'origine comme clé de cache. Ainsi, différentes URL signées générées par différents utilisateurs pour la même ressource atteignent le même contenu mis en cache. Une authentification expirée bloque uniquement les nouvelles requêtes ultérieures avec une erreur 403 et n'invalide pas les ressources déjà mises en cache.
Erreur denied by req auth: no url arg auth_key (aucun paramètre de signature n'est transmis)
Cause : L'authentification URL est activée sur le CDN, mais l'URL réellement consultée ne contient pas le paramètre de signature.
Solution : Si vous avez besoin de la fonctionnalité d'authentification, suivez les instructions de la section Configurer la signature d'URL pour générer et transmettre le paramètre de signature correct pour les requêtes. Si vous n'avez pas besoin de la fonctionnalité d'authentification, connectez-vous à la console CDN et désactivez l'authentification URL pour le nom de domaine.
Erreur denied by req auth: expired timestamp (la signature a expiré)
Cause : L'URL contient le paramètre de signature, mais l'horodatage inclus dans ce paramètre a expiré. La durée de validité d'une URL signée est déterminée par la durée de validité que vous avez configurée. La signature devient invalide une fois cette durée écoulée.
Solution : Consultez la section Configurer la signature d'URL pour régénérer l'URL signée. Si le chargement de vos pages métier prend beaucoup de temps, vous pouvez prolonger judicieusement la durée de validité de la signature.
Erreur denied by req auth: invalid md5hash (erreur de calcul de l'authentification)
Cause : La valeur MD5 du paramètre de signature est calculée incorrectement. Cela est généralement dû à une inadéquation entre l'algorithme de signature de votre code de signature et les exigences de la méthode d'authentification du CDN.
Solution : Nous vous recommandons d'utiliser d'abord le générateur d'URL dans la console CDN pour créer une URL signée, de la comparer champ par champ avec l'URL générée par votre propre code de signature, et d'identifier la différence de signature. Pour connaître l'algorithme de signature de chaque méthode d'authentification, consultez la section Signature de type A. Pour des exemples de code de signature, consultez la section Exemples de signature d'URL.
Erreurs 403 causées par la liste noire/liste blanche Referer
Après avoir configuré une liste noire/liste blanche Referer, le CDN renvoie une erreur 403 si le Referer d'une requête ne correspond pas aux règles. Le message d'erreur dans les en-têtes de réponse est X-Tengine-Error: denied by Referer ACL. Vous pouvez exécuter la commande curl -e "<Referer value>" <accelerated resource URL> pour simuler une requête contenant un Referer spécifié et vérifier le comportement.
Une requête contenant un Referer est bloquée (denied by Referer ACL)
Cause : Le Referer transmis par la requête ne figure pas dans la liste blanche ou correspond à la liste noire. Cela se produit souvent lorsque la liste blanche omet le nom de domaine du site qui référence réellement les ressources.
Diagnostic : Dans la console CDN, vérifiez la configuration de la liste noire/liste blanche Referer du nom de domaine accéléré et déterminez si le Referer de la requête bloquée correspond aux règles. Vous pouvez également télécharger les journaux CDN pour trouver l'en-tête Referer de l'enregistrement d'accès correspondant.
Solution : Ajoutez le Referer bloqué à la liste blanche (ou supprimez-le de la liste noire). Pour la méthode de configuration, consultez la section Configurer une liste noire ou une liste blanche Referer.
Une requête avec un Referer vide est bloquée (l'accès direct à l'URL renvoie une erreur 403)
Cause : Les requêtes dans les scénarios suivants ne contiennent pas de Referer (Referer vide) : accès direct à une URL de ressource depuis la barre d'adresse du navigateur ; construction de requêtes dans des applications ou programmes clients sans définir l'en-tête Referer ; page HTTPS référençant des ressources HTTP, auquel cas le navigateur n'envoie pas le Referer selon la Referrer-Policy par défaut ; page définissant explicitement Referrer-Policy: no-referrer ; et utilisation d'outils en ligne de commande tels que curl ou wget, qui ne transmettent pas de Referer par défaut. Si l'option Allow direct access to resource URLs from the browser address bar n'est pas sélectionnée dans la configuration de la liste noire/liste blanche Referer, les requêtes avec un Referer vide sont bloquées.
Solution : Si votre activité nécessite d'autoriser l'accès avec un Referer vide, sélectionnez Allow direct access to resource URLs from the browser address bar dans la configuration de la liste noire/liste blanche Referer. Si vous souhaitez intentionnellement bloquer les requêtes avec un Referer vide pour prévenir le vol de trafic, ne les autorisez pas et consultez la section Anomalies de trafic et vol de trafic malveillant pour configurer des politiques d'atténuation plus fines. Pour la méthode de configuration, consultez la section Configurer une liste noire ou une liste blanche Referer.
Erreurs 403 causées par d'autres fonctionnalités de contrôle d'accès CDN
Erreurs 403 causées par la liste noire/liste blanche IP
Après avoir configuré une liste noire/liste blanche IP, le nœud CDN rejette une requête et renvoie une erreur 403 si l'adresse IP du client correspond à la liste noire ou ne figure pas dans la liste blanche. L'en-tête de réponse X-Tengine-Error: denied by IP ACL = blacklist indique que l'adresse IP correspond à la liste noire IP, et X-Tengine-Error: denied by IP ACL = not in whitelist indique que l'adresse IP ne figure pas dans la liste blanche IP.
Diagnostic : Confirmez d'abord l'adresse IP publique réelle du client (vous pouvez la consulter en exécutant curl ifconfig.me ou curl myip.ipip.net). Si les requêtes passent par un proxy ou un équilibreur de charge, l'adresse IP du client obtenue par le CDN peut être l'adresse IP du proxy plutôt que l'adresse IP de l'utilisateur final ; vous devez donc confirmer l'adresse IP du client réellement identifiée par le nœud CDN. Dans la console CDN, vérifiez la configuration de la liste noire/liste blanche IP du nom de domaine et confirmez si l'adresse IP correspond aux règles.
Solution : Confirmez d'abord si le blocage est intentionnel. Si vous devez autoriser l'adresse IP, accédez à la page Domain Names dans la console CDN, cliquez sur Manage pour le nom de domaine cible. Dans le volet de navigation de gauche, cliquez sur Access Control, et ajustez les règles dans la section IP Blacklist/Whitelist. Pour la méthode de configuration, consultez la section Configurer une liste noire ou une liste blanche IP. Si une adresse IP figurant dans la liste noire IP peut toujours accéder aux ressources, consultez la section Pourquoi une adresse IP figurant dans la liste noire peut-elle toujours accéder à mes ressources ?.
Erreurs 403 causées par la liste noire/liste blanche UA
Après avoir configuré une liste noire/liste blanche UA, le nœud CDN rejette une requête et renvoie une erreur 403 si l'User-Agent dans l'en-tête de requête correspond à la liste noire UA ou ne figure pas dans la liste blanche UA. L'en-tête de réponse X-Tengine-Error: black ua indique que l'User-Agent correspond à la liste noire UA, et X-Tengine-Error: not in white ua indique que l'User-Agent ne figure pas dans la liste blanche UA.
Diagnostic : Exécutez curl -v <accelerated resource URL> pour vérifier la valeur User-Agent réellement envoyée par la requête, ou examinez les en-têtes de requête dans les outils de développement du navigateur. Dans la console CDN, vérifiez les règles de la liste noire/liste blanche UA du nom de domaine et confirmez si l'User-Agent correspond. Notez que la liste noire/liste blanche UA prend en charge la correspondance avec des caractères génériques ; vérifiez donc si l'User-Agent n'est pas involontairement concerné par une règle utilisant des caractères génériques.
Solution : Confirmez d'abord si le blocage est intentionnel. Si vous devez autoriser la requête, accédez à la page Domain Names dans la console CDN, cliquez sur Manage pour le nom de domaine cible. Dans le volet de navigation de gauche, cliquez sur Access Control, et ajustez les règles dans l'onglet UA Blacklist/Whitelist. Pour la méthode de configuration, consultez la section Configurer une liste noire ou une liste blanche User-Agent.
Erreurs 403 causées par l'authentification distante
Une fois l'authentification distante activée, le nœud CDN transfère les requêtes au serveur d'authentification que vous avez spécifié pour vérification. Les requêtes sont bloquées et une erreur 403 est renvoyée dans les deux cas suivants :
Le serveur d'authentification renvoie le Authentication Failure Status Code défini dans la configuration (par exemple, 403). Le CDN considère que l'authentification a échoué et rejette la requête.
L'authentification expire (l'interaction entre le nœud CDN et le serveur d'authentification ne se termine pas dans le délai d'attente configuré), et l'option Action After Authentication Timeout est définie sur Reject.
Diagnostic : Si l'erreur 403 n'appartient à aucune des catégories d'authentification URL, Referer, IP ACL ou UA ACL décrites ci-dessus (la valeur X-Tengine-Error dans les en-têtes de réponse ne correspond à aucune d'entre elles) et que l'authentification distante est activée pour le nom de domaine, vous devez d'abord procéder au dépannage de l'authentification distante. Dans la console CDN, vérifiez les paramètres Authentication Failure Status Code, Authentication Timeout Settings et Action After Authentication Timeout dans la configuration de l'authentification distante du nom de domaine, puis examinez les journaux d'accès du serveur d'authentification pour confirmer le code d'état réellement renvoyé par le serveur d'authentification et vérifier s'il y a eu des expirations de délai.
Solution : Si le blocage n'est pas intentionnel, ajustez la logique de vérification du serveur d'authentification ou la configuration du code d'état d'échec d'authentification. Si l'authentification expire fréquemment, dépannez les performances du serveur d'authentification (le délai d'attente peut être réglé jusqu'à 3 000 millisecondes), ou définissez Action After Authentication Timeout sur Allow en fonction de votre évaluation des risques métier. Pour la méthode de configuration, consultez la section Configurer l'authentification distante.
Erreurs 403 renvoyées par le serveur d'origine
Si les en-têtes de réponse ne contiennent pas le champ X-Tengine-Error et que X-Cache est MISS, le cache CDN a manqué sa cible et le serveur d'origine a renvoyé une erreur 403 après la récupération d'origine. Dans ce cas, vous devez dépanner les politiques de contrôle d'accès du serveur d'origine lui-même.
Erreurs 403 lorsque le serveur d'origine est OSS (AccessDenied et autres erreurs)
Le serveur d'origine OSS renvoie l'erreur 403. Il existe trois messages d'erreur courants :
L'erreur You have no right to access this object because of bucket acl : le bucket dispose d'autorisations de lecture privées, et la requête de récupération d'origine du CDN ne passe pas l'authentification OSS. Nous vous recommandons d'activer l'autorisation de récupération d'origine pour les buckets OSS privés dans la console CDN. Pour la méthode de configuration, consultez la section Configurer la récupération d'origine depuis un bucket OSS privé.
L'erreur You are denied by bucket referer policy : une liste noire/liste blanche Referer est configurée pour le bucket, et le Referer de la requête de récupération d'origine du CDN ne correspond pas aux règles du bucket. Vérifiez les paramètres de la liste noire/liste blanche Referer du bucket dans la console OSS et autorisez l'accès depuis les requêtes de récupération d'origine du CDN (par exemple, autorisez un Referer vide, ou ajoutez le Referer transmis par les requêtes de récupération d'origine du CDN à la liste blanche).
L'erreur You are forbidden to list buckets : la récupération d'origine privée du CDN et l'hébergement de site statique d'OSS sont activés simultanément, ce qui crée un conflit entre les deux fonctionnalités. Désactivez l'une d'elles : désactivez l'autorisation de récupération d'origine pour les buckets CDN privés, ou désactivez la fonctionnalité d'hébergement de site statique d'OSS. Pour la description du conflit, consultez la section Que faire si des erreurs surviennent après avoir activé l'accès aux buckets OSS privés et l'hébergement de site statique ?.
Erreurs 403 causées par l'hôte d'origine ou d'autres politiques du serveur d'origine
Cause : Lorsque le CDN effectue une récupération d'origine, l'hôte d'origine détermine vers quel site sur l'adresse IP du serveur d'origine la requête de récupération d'origine accède. Si l'hôte d'origine est configuré incorrectement, la requête peut être associée à un site qui ne fournit pas de services ou qui impose des restrictions d'accès sur le serveur d'origine, et le serveur d'origine renvoie une erreur 403. De plus, les règles de pare-feu, les politiques WAF ou le contrôle d'accès au niveau applicatif du serveur d'origine lui-même peuvent également bloquer les requêtes de récupération d'origine du CDN.
Diagnostic : Mappez le nom de domaine accéléré à l'adresse IP du serveur d'origine en liant le fichier hosts, accédez directement au serveur d'origine et vérifiez s'il renvoie également une erreur 403. Vérifiez la configuration de l'hôte d'origine dans la console CDN et confirmez qu'elle pointe vers le site qui fournit réellement des services sur le serveur d'origine.
Solution : Corrigez la configuration de l'hôte d'origine pour vous assurer qu'il pointe vers le site qui fournit réellement des services sur le serveur d'origine. Si le pare-feu ou le WAF du serveur d'origine bloque les requêtes de récupération d'origine du CDN, ajoutez les plages d'adresses IP de récupération d'origine du CDN à la liste blanche du serveur d'origine. Pour les méthodes générales de dépannage côté serveur d'origine, consultez le Guide de dépannage de la récupération d'origine.
Anomalies de trafic et vol de trafic malveillant
Lorsqu'un nom de domaine est attaqué ou que son trafic fait l'objet d'un vol malveillant, une bande passante soudainement élevée ou un trafic important est généré, ce qui engendre principalement deux risques :
Le nom de domaine est déplacé vers un bac à sable (sandbox) : Alibaba Cloud CDN est un service d'accélération public et ne fournit pas de capacités anti-attaque par défaut. Lorsqu'un nom de domaine est attaqué, le CDN a le droit de déplacer le nom de domaine vers un bac à sable en fonction de la situation commerciale et de la gravité de l'impact de l'attaque, afin d'éviter d'affecter les services d'accélération des autres utilisateurs. Si les attaques sont sévères, d'autres noms de domaine sous le même compte peuvent également être déplacés vers un bac à sable, et l'intégration de nouveaux noms de domaine sous le compte est restreinte. Une fois qu'un nom de domaine entre dans le bac à sable, le CDN ne garantit plus la qualité de service. Pour plus d'informations sur le bac à sable, consultez la section Présentation du bac à sable (Sandbox).
Les accès malveillants entraînent des factures anormalement élevées : Les attaques et le vol de trafic consomment effectivement des ressources de bande passante CDN. Les coûts de bande passante résultants sont à votre charge, ce qui peut facilement entraîner des factures anormalement élevées et peut même provoquer la suspension du compte en raison de paiements en retard. Pour plus d'informations sur la protection contre la suspension de service et le contrôle des coûts, consultez la section Avertissement de risque de facture élevée.
Comment confirmer si le nom de domaine subit un vol de trafic ou des attaques ?
Confirmez-le préalablement de la manière suivante :
Connectez-vous à la console CDN et vérifiez les tendances de la bande passante et du trafic du nom de domaine dans Monitoring Reports. Vérifiez si des pics anormaux se produisent en dehors des heures d'activité.
Téléchargez les journaux d'accès CDN du nom de domaine, analysez la distribution des adresses IP, la distribution des Referer et la distribution des User-Agents des sources d'accès, et identifiez les plages d'adresses IP anormalement fréquentes, les sources Referer anormales ou les User-Agents ressemblant à des robots d'exploration.
Vérifiez dans CloudMonitor si des alertes de bande passante ou de trafic ont été déclenchées.
Comment se protéger et gérer la situation ?
Nous vous recommandons de prendre des mesures de protection à l'avance : configurez des règles d'alerte pour la bande passante de pointe et le trafic descendant via la fonctionnalité de paramètres d'alerte afin d'être notifié rapidement lorsque les seuils sont atteints ; et configurez des politiques de contrôle d'accès telles qu'une liste noire IP, une liste noire Referer, une liste noire UA ou une authentification URL en fonction des caractéristiques de l'attaque pour bloquer les attaques. Pour les solutions de blocage contre les scénarios de vol de trafic, consultez la section Prévenir l'abus de trafic.
Si le nom de domaine a été déplacé vers un bac à sable, attendez que le trafic d'attaque diminue, puis soumettez un ticket pour demander sa suppression du bac à sable. Pour éviter que cela ne se reproduise, nous vous recommandons de configurer les politiques de contrôle d'accès avant la suppression.