Tous les produits
Search

Ce produit

    Edge Security Acceleration:Éligibilité au cache

    Centre de documentation

    Edge Security Acceleration:Éligibilité au cache

    Dernière mise à jour :Sep 14, 2026

    Pour contourner le cache d'Edge Security Acceleration (ESA) pour les ressources correspondant à la règle de cache par défaut, créez une règle afin de filtrer les requêtes et définissez l'option Cache Eligibility sur Bypass Cache.

    Remarque

    En l'absence de règles ou de configurations de cache, la mise en cache sur les points de présence (POP) d'ESA suit la règle de cache par défaut.

    Scénarios

    Si votre serveur d'origine contient des ressources que vous ne souhaitez pas mettre en cache sur les POP ESA, telles que des ressources dynamiques nécessitant la récupération du contenu le plus récent depuis l'origine à chaque requête, configurez une règle de contournement du cache pour ces ressources. Le contournement du cache pour les ressources dynamiques améliore les performances d'accès.

    Les règles d'éligibilité au cache déterminent si une requête est mise en cache par les nœuds périphériques ESA. Voici quelques cas d'utilisation courants :

    • Mise en cache des ressources statiques — Améliorez les performances en mettant en cache les images, les fichiers CSS et JavaScript sur les nœuds périphériques.

    • Contournement du contenu dynamique — Assurez-vous que les pages de connexion, les API et le contenu personnalisé ne sont pas mis en cache.

    • Séparation dynamique-statique — Mettez en cache les actifs statiques tout en contournant les requêtes dynamiques vers le serveur d'origine.

    • Absence de cache sélective — Empêchez la mise en cache de fichiers ou de chemins spécifiques.

    Procédure

    1. Dans la console ESA, choisissez Websites. Dans la colonne Website, cliquez sur le site cible.

    2. Dans le volet de navigation de gauche, sélectionnez Rules > Cache Rules.

    3. Cliquez sur Create Rule et saisissez un nom dans le champ Rule Name.

    4. Dans la section If requests match..., définissez les attributs de requête à faire correspondre. Pour plus d'informations sur la configuration des règles, consultez la rubrique Composition of a rule expression.

    5. Dans la zone Cache Eligibility , sélectionnez une politique de cache et cliquez sur OK.

      image

      • Bypass Cache : Toutes les requêtes ignorent le cache du POP et récupèrent les données directement depuis l'origine, ce qui vous permet de consulter les ressources les plus récentes du serveur d'origine en temps réel. Lorsque cette option est activée, seul le paramètre Browser Cache TTL s'applique.

      • Eligible for Cache : Toutes les requêtes éligibles sont servies depuis les nœuds de cache du POP plutôt que depuis l'origine. Cela évite les longs trajets de récupération vers l'origine, réduit la latence et améliore les performances d'accès.

    Options et limitations d'éligibilité au cache

    Bypass Cache

    Lorsque l'option Bypass Cache est sélectionnée :

    • Les requêtes correspondantes sont transférées directement vers le serveur d'origine sans être stockées sur les nœuds périphériques ESA.

    • Seul le paramètre Browser Cache TTL prend effet. Les autres fonctionnalités liées au cache (telles que Cache Deception Defense et Serve Stale Content) sont désactivées pour cette règle.

    • ESA ne prend pas en charge la configuration du comportement no-cache basée sur les en-têtes de réponse HTTP (tels que X-Fallback) ou les marqueurs de commentaires HTML. Utilisez plutôt des conditions de correspondance basées sur l'en-tête de requête ou l'URL.

    Comportement de cache par défaut

    En l'absence de règles de cache configurées, ou lorsqu'aucune règle ne correspond à une requête, ESA applique le comportement par défaut suivant :

    • Les requêtes suivent la politique de cache par défaut d'ESA.

    • Les requêtes dynamiques dont les URL se terminent par / sont transférées vers le serveur d'origine par défaut.

    • Lorsque le serveur d'origine renvoie un en-tête de réponse no-cache, la réponse n'est pas mise en cache.

    Fonctionnalités de cache avancées

    Les fonctionnalités suivantes sont désactivées par défaut et doivent être activées manuellement dans une règle de cache :

    • Cache Deception Defense : Protège contre les attaques par tromperie de cache.

    • Serve Stale Content : Permet à ESA de servir du contenu mis en cache obsolète lorsque l'origine est temporairement indisponible.

    Exemples de configuration courants

    Les exemples suivants couvrent les scénarios fréquents de configuration de l'éligibilité au cache.

    Exemple 1 : Contourner le cache pour les API dynamiques

    Scénario : Empêcher la mise en cache des points de terminaison d'API dynamiques sur les nœuds périphériques.

    Configuration :

    • Condition de correspondance : Le chemin d'URL contains /api, OU le chemin d'URL contains /prod-api/, OU l'extension de fichier equals php

    • Cache Eligibility : Bypass Cache

    Remarque

    Lors de la spécification des extensions de fichier, n'incluez pas le point. Saisissez php, et non .php.

    Exemple 2 : Contourner le cache pour les pages d'administration et de connexion

    Scénario : Empêcher la mise en cache des pages d'administration WordPress, des interfaces de gestion CMS ou des points de terminaison de connexion.

    Configuration :

    • Condition de correspondance : Le chemin d'URL contains /wp-admin, OU le chemin d'URL contains /admin, OU le chemin d'URL contains /login

    • Cache Eligibility : Bypass Cache

    Important

    Placez cette règle en haut de la liste des règles pour garantir qu'elle soit prioritaire sur les règles générales de mise en cache des ressources statiques.

    Exemple 3 : Mettre en cache le chemin racine d'une SPA

    Scénario : ESA ne met pas en cache les URL sans extension (telles que /) par défaut. Pour mettre en cache le contenu text/html des applications monopages (SPA) :

    Configuration :

    • Condition de correspondance : L'en-tête de requête Accept contains text/html

    • Cache Eligibility : Eligible for Cache

    • Cache TTL : Définissez selon la fréquence de mise à jour de votre SPA.

    Exemple 4 : Contourner le cache pour des fichiers spécifiques

    Scénario : Empêcher la mise en cache de fichiers spécifiques tels que sitemap.xml.

    Configuration :

    • Condition de correspondance : Le chemin d'URL contains sitemap (sans extension de fichier), OU l'extension de fichier equals xml (saisissez xml, et non .xml)

    • Cache Eligibility : Bypass Cache

    Exemple 5 : Séparation dynamique-statique

    Scénario : Mettre en cache les actifs statiques tout en garantissant que les requêtes dynamiques sont transférées vers l'origine.

    Approche recommandée :

    1. Supprimez toutes les règles de cache existantes couvrant l'intégralité du site.

    2. Créez une règle pour mettre en cache les ressources statiques. Par exemple, faites correspondre l'extension de fichier equals l'une des valeurs suivantes : jpg, png, css ou js.

    3. Créez une règle distincte pour contourner le cache des points de terminaison d'API dynamiques. Par exemple, faites correspondre le chemin d'URL contains /api.

    Cette approche empêche la mise en cache accidentelle des requêtes dynamiques.

    Notes de configuration

    • Un seul TTL de cache par règle — Une règle de cache unique ne peut définir qu'un seul TTL de cache. Si différentes extensions de fichier ou répertoires nécessitent des durées de cache différentes, créez une règle distincte pour chacun.

    • Indépendance des règles — La désactivation ou la suppression d'une règle de cache spécifique n'affecte pas le comportement de mise en cache des autres ressources. ESA continue d'évaluer les règles restantes dans l'ordre.

    • Réduction de la charge sur l'origine — Configurez des règles de contournement du cache pour le contenu dynamique et activez les règles de cache pour les ressources statiques afin de minimiser les requêtes transférées vers le serveur d'origine.

    • Priorité d'application des sous-modules — Dans la fonctionnalité Cache Rules, la priorité d'application des sous-modules, de la plus élevée à la plus faible, est la suivante : POST Cache > Bypass Cache > Autres sous-modules. Lorsque POST Cache est activé, les requêtes sont traitées via le workflow de mise en cache des ressources statiques, et la fonctionnalité Bypass Cache devient inefficace.

    FAQ

    Pourquoi ma règle de contournement du cache ne prend-elle pas effet ?

    Vérifiez les points suivants :

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

      • Une condition OR correspond involontairement aux requêtes provenant d'autres domaines.

      • Les valeurs d'extension de fichier ou 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 client 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 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 haute dans la liste.

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

    5. Limitations du plan : L'édition Free peut ne pas garantir une application cohérente des règles. Envisagez de passer à un plan payant.

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

    Pourquoi ne puis-je pas me connecter, ou pourquoi les pages redirigent-elles incorrectement après l'activation d'ESA ?

    Cause : Cela se produit généralement lorsqu'une règle de cache couvrant l'intégralité 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 périphériques ESA.

    Résolution :

    1. Suspendez ou supprimez toute règle de cache suspecte couvrant l'intégralité du site.

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

    3. Dans la console ESA, videz le cache des 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 relève d'un problème extérieur au périmètre d'ESA.

    Quelle est la différence entre « equals » et « contains » dans les conditions de correspondance ?

    Type de correspondance

    Comportement

    Equals

    Correspondance exacte du chemin d'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 des noms d'hôte, Equals et Contains produisent des résultats équivalents et peuvent être utilisés indifféremment.

    Pourquoi l'activation des règles de cache permet-elle la réussite des sondes, tandis que leur désactivation provoque des délais d'attente ?

    Lorsque les règles de cache sont actives, les nœuds périphériques 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 lié à 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 simultanées.

    Documentation connexe

    Les fonctionnalités liées aux règles varient en termes de priorité effective, de réentrance et de granularité effective. Pour plus de détails, consultez la rubrique Characteristics of rule-based features.