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 :Aug 12, 2026

    Pour contourner le cache 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 spécifiques, la mise en cache sur les points de présence (POP) d'ESA suit la règle de cache par défaut.

    Cas d'usage

    Si votre serveur d'origine contient des ressources que vous ne souhaitez pas mettre en cache sur les POP ESA, comme des ressources dynamiques nécessitant la récupération du contenu le plus récent à chaque requête, configurez une règle de contournement du cache pour ces ressources. Contourner le 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 doit être mise en cache par les nœuds périphériques ESA. Voici les 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 — Garantissez que les pages de connexion, les API et le contenu personnalisé ne soient pas mis en cache.

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

    • Exclusion sélective du cache — 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 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 POP et sont récupérées directement auprès de l'origine, ce qui 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 POP plutôt que depuis l'origine. Cela évite les longs trajets de récupération à l'origine, réduit la latence et améliore les performances d'accès.

    Options et limites d'éligibilité au cache

    Bypass Cache

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

    • Les requêtes correspondantes sont transférées directement au 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 d'un comportement de non-mise en cache basé sur des en-têtes de réponse HTTP (comme X-Fallback) ou des marqueurs de commentaires HTML. Utilisez plutôt des conditions de correspondance basées sur les en-têtes de requête ou l'URL.

    Comportement de cache par défaut

    Si aucune règle de cache n'est configurée ou si 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 l'URL se termine par / sont transférées au serveur d'origine par défaut.

    • Si 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 avancées de mise en cache

    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 usurpation 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 endpoints 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 nom de fichier equals php

    • Éligibilité au cache : Bypass Cache

    Remarque

    Lorsque vous spécifiez des extensions de nom 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 endpoints 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

    • Éligibilité au cache : 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 : Par défaut, ESA ne met pas en cache les URL sans extension (comme /). 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

    • Éligibilité au cache : Eligible for Cache

    • TTL du cache : Définissez-le 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 nom de fichier), OU l'extension de nom de fichier equals xml (saisissez xml, et non .xml)

    • Éligibilité au cache : 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 à l'origine.

    Approche recommandée :

    1. Supprimez toutes les règles de cache existantes pour l'ensemble du site.

    2. Créez une règle pour mettre en cache les ressources statiques. Par exemple, faites correspondre l'extension de nom 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 endpoints 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.

    Remarques sur la 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 noms de fichiers ou répertoires nécessitent des durées de cache distinctes, créez une règle séparée 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 de l'origine — Configurez des règles de contournement du cache pour le contenu dynamique et activez des règles de cache pour les ressources statiques afin de minimiser les requêtes transférées au serveur d'origine.

    • Priorité d'application des sous-modules — Dans la fonctionnalité @xref node="4727152" Cache Rules @/xref, la priorité d'application des sous-modules, de la plus haute à la plus basse, est la suivante : POST Cache > Bypass Cache > Autres sous-modules. Lorsque POST Cache est activé, les requêtes sont traitées via le flux de travail de mise en cache des ressources statiques, rendant la fonctionnalité Bypass Cache 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 qui correspond involontairement aux requêtes d'autres domaines.

      • Des valeurs d'extension de nom de fichier ou de chemin mal formatées. 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 (comme sec-fetch-site), assurez-vous que les requêtes client réelles incluent bien 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 sous une règle de mise en cache à long TTL, cette dernière risque de correspondre en premier. Déplacez la règle de contournement du cache vers une position supérieure dans la liste.

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

    5. Limites du plan : L'édition gratuite 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 toute interférence liée au cache local du navigateur.

    Pourquoi ne puis-je pas me connecter, ou pourquoi les redirections de pages échouent-elles après l'activation d'ESA ?

    Cause : Ce problème survient généralement lorsqu'une règle de cache pour l'ensemble 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 pour l'ensemble du site.

    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 pour leur accorder la priorité la plus élevée.

    3. Dans la console ESA, purgez 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 malgré une configuration correcte : Vérifiez la logique métier de votre serveur d'origine. Assurez-vous par exemple 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.

    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 aussi aux ressources situées sous /test/_nuxt/chunk-abc.js.

    Contains

    Correspondance floue. Toute URL contenant la chaîne spécifiée, où qu'elle se trouve, est considérée comme correspondante.

    Pour la correspondance des noms d'hôte, Equals et Contains produisent des résultats équivalents et peuvent être utilisés de manière interchangeable.

    Pourquoi l'activation des règles de cache permet-elle la réussite des tests de sondage, alors 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 à volume élevé — 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 un goulot d'étranglement des performances 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 à 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 associée

    Les fonctionnalités liées aux règles varient en termes de priorité effective, de réentrance et de granularité d'application. Pour plus de détails, consultez la rubrique Properties of Rule-Related Features.