Edge Security Acceleration:Rules FAQ

Certains fournisseurs d'accès à Internet (FAI) dans certaines régions attribuent des adresses IP privées aux clients. Par conséquent, un nœud ESA peut recevoir une adresse IP client issue d'un bloc CIDR privé. Les règles utilisant des paramètres tels que le pays/la région, la province ou l'opérateur ne peuvent alors pas identifier précisément ces requêtes. Pour gérer les requêtes issues de blocs CIDR privés, suivez les étapes ci-dessous.

Étape 1 : Créer une liste d'adresses IP

1. Accédez à Global Settings > Lists. Cliquez sur Create List et ajoutez les trois entrées IP Address/CIDR Block privées suivantes :

   • Adresse IP privée de classe A : 10.0.0.0 à 10.255.255.255, masque de sous-réseau : 10.0.0.0/8.

   • Adresse IP privée de classe B : 172.16.0.0 à 172.31.255.255, masque de sous-réseau : 172.16.0.0/12.

   • Adresse IP privée de classe C : 192.168.0.0 à 192.168.255.255, masque de sous-réseau : 192.168.0.0/16.

2. Une fois les entrées ajoutées, la configuration s'affiche comme illustré dans la figure suivante. Cliquez sur OK.

Étape 2 : Ajouter une règle pour le bloc CIDR privé

1. Cet exemple utilise une règle personnalisée. Sur la page WAF Custom Rules, sélectionnez is in list pour l'expression logique, choisissez le groupe nouvellement créé dans la liste déroulante, puis cliquez sur Create Rule .

2. Une fois terminé, cliquez sur OK.

Symptômes

Après avoir configuré une règle basée sur le débit dans ESA (par exemple, déclencher un défi JS/slider pendant 1 heure si plus de 20 requêtes sont reçues en 10 secondes), toutes les images d'un mini-programme ne se chargent pas. La suppression de la règle résout le problème.

Cause

Lors du chargement, un mini-programme envoie de nombreuses requêtes concurrentes pour les images. Cette rafale de requêtes peut facilement dépasser le seuil de fréquence configuré. Lorsque la règle basée sur le débit est déclenchée, elle intercepte les requêtes d'images légitimes et présente un défi JS/slider. L'environnement du mini-programme ne pouvant pas exécuter ce défi, toutes les requêtes d'images sont bloquées.

Solution

Pour résoudre ce problème, utilisez une ou plusieurs des méthodes suivantes :

• Augmentez le seuil de fréquence : Définissez un seuil plus élevé (par exemple, 100 requêtes par 10 secondes) pour empêcher le déclenchement de la règle lors du chargement normal des images.

• Réduisez la portée de la correspondance : Dans la condition de correspondance de la règle, excluez les requêtes d'images en filtrant selon le chemin URL ou l'extension de fichier. Cela garantit que la règle basée sur le débit s'applique uniquement aux requêtes de ressources non statiques.

• Configurez une liste blanche : Ajoutez les adresses IP sources connues du mini-programme ou le Referer à une liste blanche pour les exempter de la règle basée sur le débit.

• Supprimez temporairement la règle : Si vous ne pouvez pas déterminer immédiatement un seuil approprié, supprimez d'abord la règle basée sur le débit pour rétablir le service. Ensuite, utilisez la fonctionnalité d'analyse des requêtes dans la console ESA pour identifier les adresses IP anormales et configurer une règle plus précise.

Lorsqu'une requête est identifiée comme une menace potentielle, le système émet un défi :

• Défi JavaScript : Injecte du JavaScript pour vérifier que le client est un navigateur réel. Transparent pour la plupart des utilisateurs, mais peut affecter les clients API qui ne prennent pas en charge JavaScript.

• CAPTCHA : Requiert une tâche interactive (puzzle ou curseur) pour prouver que l'utilisateur est humain. Interrompt le flux d'accès.

Les niveaux de sécurité et les règles WAF sont des fonctionnalités indépendantes. Les niveaux de sécurité bloquent ou défient automatiquement les requêtes en fonction des informations de renseignement sur les menaces. Les règles WAF sont des règles personnalisées que vous définissez pour faire correspondre des chemins, des paramètres ou des comportements spécifiques, offrant ainsi un contrôle plus granulaire.

Vérifiez les points suivants :

1. Condition de correspondance incorrecte : Vérifiez l'expression de la règle. Les erreurs courantes incluent :

   • Une condition OU correspond involontairement à des requêtes provenant d'autres domaines.

   • L'extension de nom de fichier ou les valeurs de chemin sont formatées incorrectement. Par exemple, .php au lieu de php.

2. Caractéristiques de requête manquantes : Si la règle dépend d'un en-tête de requête spécifique (tel que sec-fetch-site), confirmez que les requêtes clientes réelles incluent cet en-tête.

3. Priorité de règle insuffisante : ESA évalue les règles de haut en bas. Si la règle de contournement du cache est placée en dessous d'une règle de mise en cache avec un TTL long, la première règle peut correspondre en premier. Déplacez la règle de contournement du cache vers une position plus élevée dans la liste.

4. Cache non vidé après modification de la règle : Après avoir modifié les règles, videz les URL ou répertoires concernés dans la console ESA. Le rafraîchissement de votre navigateur n'invalide pas le contenu mis en cache sur les nœuds de périphérie.

5. Approche de vérification : Vérifiez l'en-tête de réponse Server pour confirmer si les requêtes sont traitées par les nœuds de périphérie ESA. Utilisez une fenêtre de navigation privée pour éliminer l'interférence du cache local du navigateur.

Cause : Cela se produit généralement lorsqu'une règle de mise en cache complète du site ou une règle de cache mal configurée entraîne la mise en cache des cookies de connexion, des données de session ou des réponses d'API dynamiques sur les nœuds de périphérie ESA.

Résolution :

1. Suspendez ou supprimez toute règle de mise en cache complète du site suspecte.

2. Créez des règles Bypass Cache spécifiquement pour les pages de connexion, les endpoints CAPTCHA et les chemins d'administration. Placez ces règles en haut de la liste des règles pour leur donner la priorité la plus élevée.

3. Dans la console ESA, videz le cache pour les URL concernées.

4. Vérifiez la correction à l'aide d'une fenêtre de navigation privée.

Si le problème persiste après une configuration correcte : Vérifiez la logique métier de votre serveur d'origine. Par exemple, assurez-vous que la logique de redirection 302 identifie correctement l'état de connexion. Si le serveur d'origine ne gère pas correctement l'état de connexion, cela sort du cadre d'ESA.

Type de correspondance	Comportement
Equals	Correspondance exacte du chemin URL spécifié. Correspond également automatiquement à tous les sous-chemins. Par exemple, la configuration de /test/_nuxt/ avec Equals correspond également aux ressources situées sous /test/_nuxt/chunk-abc.js.
Contains	Correspondance floue. Toute URL incluant la chaîne spécifiée n'importe où est mise en correspondance.

Pour la correspondance de nom d'hôte, Equals et Contains produisent des résultats équivalents et peuvent être utilisés indifféremment.

Lorsque les règles de cache sont actives, les nœuds de périphérie ESA servent les requêtes directement depuis le cache, réduisant ainsi la charge sur le serveur d'origine.

Lorsque les règles de cache sont désactivées, toutes les requêtes — y compris les requêtes dynamiques à fort volume — sont envoyées directement au serveur d'origine en temps réel. Lors de tests de charge à haute concurrence, cela peut submerger le serveur d'origine et provoquer des délais d'attente des requêtes.

Ce comportement reflète une limitation de performance du serveur d'origine, et non un problème ESA. Pour y remédier :

• Configurez des règles de cache pour réduire le volume de requêtes transférées vers l'origine.

• Activez JS Challenge ou Intelligent Rate Limiting pour protéger le serveur d'origine contre un nombre excessif de requêtes concurrentes.

La fonctionnalité Serve Stale Content est déclenchée uniquement lorsque le serveur d'origine renvoie un code d'état HTTP 4xx ou 5xx, ou lorsque la requête expire. Si vous supprimez simplement un fichier de votre serveur d'origine mais que le serveur continue de répondre normalement (par exemple, en renvoyant une page par défaut avec un code d'état 200, ou en renvoyant un code d'état 404), cela n'est pas considéré comme un échec de récupération depuis l'origine et ne déclenchera pas Serve Stale Content.

Si vous devez accéder à un fichier depuis le cache après sa suppression du serveur d'origine, confirmez les points suivants :

• Le serveur d'origine doit être inaccessible (par exemple, le serveur a planté, il y a une interruption réseau ou il renvoie un code d'erreur 5xx), et non simplement qu'un seul fichier a été supprimé.

• Une copie du fichier était déjà mise en cache sur le nœud de périphérie avant sa suppression. Si le fichier n'a jamais été mis en cache ou si le cache a été purgé, il n'y a pas de contenu obsolète à servir, même si la fonctionnalité est déclenchée.

1. Le cache a expiré : Vérifiez si la valeur TTL configurée est trop courte. Examinez les en-têtes de réponse tels que Cache-Control pour confirmer le TTL du cache.

2. Paramètres URL différents : Par défaut, différents paramètres URL sont traités comme des clés de cache différentes. Configurez des règles de clé de cache pour ignorer les paramètres non pertinents.

3. La règle n'a pas pris effet : Vérifiez les conditions de correspondance de la règle, telles que le modèle de chemin, pour vous assurer qu'elles couvrent la requête cible.

Utilisez la commande curl pour afficher les en-têtes de réponse détaillés :

curl -v -I https://example.com/target-url

x-site-cache-status: HIT : Le statut de cache de la ressource demandée sur le POP ESA.

Vous pouvez actualiser le cache par URL ou par dossier.

La limite de taille du corps détermine quelles requêtes POST sont éligibles à la mise en cache. Les requêtes dépassant cette limite sont transférées directement au serveur d'origine sans être mises en cache. Tenez compte des éléments suivants lors de la définition de la limite :

• Augmentez la limite (par exemple, à 6 Ko–8 Ko) : Si vos requêtes POST ont des corps de requête complexes ou volumineux, tels que des requêtes de recherche avec des structures imbriquées ou des requêtes d'agrégation avec des paramètres de filtre multidimensionnels, une limite plus élevée est nécessaire. Cela garantit que ces requêtes sont mises en cache, maximisant ainsi les avantages en termes de performances.

• Utilisez une limite plus petite (par exemple, 1 Ko–2 Ko) : Si vos requêtes POST contiennent uniquement des paramètres simples ou quelques identifiants, tels qu'un ID utilisateur ou un horodatage, une grande limite est inutile.

• Vérifier l'adresse IP d'origine ou les modifications de configuration

  Après avoir mis à jour la configuration d'origine, accédez à votre site web et vérifiez que le contenu renvoyé provient du nouveau serveur d'origine. Vous pouvez également consulter les journaux d'accès sur le serveur d'origine pour confirmer que les requêtes arrivent depuis les nœuds ESA.

• Dépanner les échecs de fonctionnalité d'origine (par exemple, changement de langue)

  Si une fonctionnalité du site (telle que le changement de langue) cesse de fonctionner après l'activation d'ESA, suivez ces étapes :

  1. Ajoutez une entrée hosts locale qui mappe l'adresse IP du serveur d'origine au domaine de test. Accédez au site via cette connexion directe, en contournant ESA, pour déterminer si le problème provient du serveur d'origine lui-même.

  2. Videz le cache du navigateur et réessayez.

La règle s'applique uniquement aux codes d'erreur renvoyés par le serveur d'origine.

Les règles sont évaluées de haut en bas. La première règle correspondante est appliquée et l'évaluation s'arrête. Placez les règles plus spécifiques au-dessus des règles générales.

Oui. Les deux types de règles partagent le même quota de règles de redirection. Le nombre affiché sur la page Redirect Rules reflète le total combiné des deux types de règles.

L'approche dépend de votre configuration DNS :

1. Utilisation d'ESA pour la redirection : Le domaine racine et le domaine www doivent être connectés à ESA via des enregistrements CNAME ou NS. Même si vous configurez une règle de redirection, le domaine source doit conserver son enregistrement CNAME afin qu'ESA puisse reconnaître le trafic entrant. Une fois les deux domaines connectés à ESA, configurez la règle de redirection de nom d'hôte correspondante dans les règles de redirection ESA.

2. Le domaine racine possède des enregistrements MX et ne peut pas utiliser CNAME (conflit DNS) : Utilisez la fonctionnalité de transfert d'URL fournie par votre fournisseur DNS. Notez que le transfert d'URL DNS ne prend en charge que HTTP et que le trafic ne passe pas par ESA.

3. Important : Si vous avez précédemment configuré un enregistrement de transfert d'URL dans vos paramètres DNS, vous devez supprimer cet enregistrement et ajouter le CNAME ESA avant d'utiliser les règles de redirection ESA. Sinon, les règles de redirection ESA ne prendront pas effet.

Vérifiez les éléments suivants dans l'ordre :

1. Vérifiez que la condition de correspondance couvre précisément le domaine cible : Par exemple, si vous avez configuré une règle uniquement pour le domaine www mais que les utilisateurs accèdent au domaine racine, ajoutez une règle pour le domaine racine ou utilisez un caractère générique pour couvrir les deux.

2. Confirmez que le DNS est correctement connecté à ESA : Si vous utilisez la redirection ESA, le domaine doit être connecté à ESA via des enregistrements CNAME ou NS. S'appuyer uniquement sur la configuration de redirection du serveur d'origine ou sur le transfert d'URL DNS ne fonctionnera pas.

3. Vérifiez l'existence de règles de priorité supérieure remplaçant la règle de redirection : Examinez l'ordre de priorité des règles et assurez-vous qu'aucune règle en amont n'intercepte ou ne modifie la requête avant que la règle de redirection ne soit évaluée.

4. Vérifiez la syntaxe des expressions dynamiques : La concaténation d'URL nécessite la fonction concat . La saisie d'une chaîne brute avec des variables échouera. Utilisez des fonctions d'expression valides telles que concat , regex_replace ou wildcard_replace .

Essayez les étapes de dépannage suivantes :

1. Vérifiez la présence d'une configuration de redirection circulaire : Vérifiez si le serveur d'origine du domaine www pointe vers le domaine racine alors que vous avez également configuré une redirection racine vers www, créant ainsi une boucle. Restaurez l'origine à l'adresse IP réelle ou à l'adresse d'origine amont d'origine.

2. Redirection HTTP vers HTTPS : Utilisez la fonctionnalité Force HTTPS dans la console ESA plutôt que de configurer manuellement des règles de redirection. Les règles manuelles peuvent entrer en conflit les unes avec les autres et créer des boucles de redirection.

3. Videz le cache de redirection : Si une réponse de redirection obsolète persiste en raison de la mise en cache, purgez le cache dans la console ESA, puis retestez le comportement de redirection.

4. Vérifiez les règles incompatibles : Confirmez que les règles de redirection ne correspondent pas involontairement aux endpoints de contrôle de santé ou aux chemins internes spéciaux, ce qui pourrait provoquer des échecs d'accès.

Vous pouvez utiliser des en-têtes de requête tels que User-Agent dans les conditions de correspondance de la requête entrante :

1. Méthode de correspondance : Utilisez Contains plutôt que Equals pour la correspondance User-Agent, car les chaînes User-Agent sont généralement longues et varient selon les appareils.

2. Exemple de redirection mobile : Définissez la condition de correspondance sur User-Agent Contains Mobile ou utilisez des mots-clés tels que Android ou iPhone , puis configurez l'action comme une redirection 302 vers le domaine mobile.

3. Contrôle avancé : Combinez le chemin, les paramètres de requête et d'autres conditions pour un contrôle granulaire de la redirection. Par exemple, redirigez les utilisateurs mobiles accédant à / vers m.example.com , tandis que les utilisateurs de bureau continuent vers le domaine standard.

Si l'URL du navigateur ne change pas, vous utilisez peut-être la réécriture d'URL au lieu de la redirection de requête :

1. La redirection de requête ESA envoie une réponse 3xx au client, ce qui amène le navigateur à naviguer vers la nouvelle URL et à mettre à jour la barre d'adresse.

2. La réécriture d'URL modifie uniquement le chemin de la requête d'origine de manière transparente (proxy côté serveur) et ne change pas l'URL du navigateur. Si vous devez conserver l'URL du navigateur inchangée tout en modifiant le chemin envoyé à l'origine, utilisez la fonctionnalité URL Rewrite au lieu des règles de redirection.

3. Remarque sur la région d'accélération : Si la région d'accélération n'inclut pas la Chine continentale, les utilisateurs en Chine continentale peuvent ne pas bénéficier de l'accélération lors de l'accès à la cible de redirection.