Tous les produits
Search
Centre de documentation

Edge Security Acceleration:Custom cache key

Dernière mise à jour :Oct 09, 2026

Définissez des règles basées sur les chaînes de requête, les en-têtes HTTP ou les cookies pour générer des clés de cache personnalisées. Cela permet d'unifier l'identité de cache pour des requêtes similaires, améliorant ainsi les taux de succès et réduisant le temps de réponse ainsi que la consommation de bande passante.

Fonctionnement

  • Les clés de cache personnalisées modifient uniquement l'identité de cache, sans affecter l'URL de retour à l'origine. La requête vers l'origine reste identique à la requête du client.

  • Une clé de cache identifie de manière unique un fichier mis en cache sur un point de présence (POP) ESA. Par défaut, la clé de cache correspond à l'URL complète de la requête du client, y compris ses paramètres.

Notes d'utilisation

Si votre clé de cache personnalisée inclut des en-têtes de requête HTTP, des cookies ou des caractéristiques utilisateur, vous ne pouvez pas utiliser Purge cache by URL pour vider le cache d'une URL spécifique. Utilisez plutôt la fonction Purge cache by custom key.

Cas d'utilisation

Cas d'utilisation 1 : Unifier les clés de cache

Lorsque les URL de requête contiennent des paramètres complexes, le POP ESA traite les requêtes visant le même fichier comme des fichiers distincts en raison des variations des paramètres d'URL. Ces fichiers sont mis en cache séparément, ce qui augmente le nombre de requêtes vers l'origine.

Utilisez la fonction de clé de cache personnalisée pour ignorer les chaînes de requête. Cette approche unifie les clés de cache pour une même catégorie de requêtes et réduit le trafic vers l'origine.

image

Cas d'utilisation 2 : Différencier les clés de cache

Lorsque les URL de requête des clients sont identiques, ESA les considère comme des requêtes pour le même fichier. Toutefois, le champ client dans l'en-tête de la requête HTTP peut indiquer que différents systèmes clients demandent des contenus distincts.

Utilisez la fonction de clé de cache personnalisée pour générer des clés différentes selon le type de client, garantissant ainsi que chaque requête corresponde à un fichier mis en cache distinct.

image

Procédure

Lorsque les règles sont appliquées, les requêtes sont mises en correspondance selon les Rules.

  1. Dans la console ESA, sélectionnez Websites, puis cliquez sur le site cible dans la colonne Websites.

  2. Dans le volet de navigation de gauche, choisissez Websites > Website.

  3. Cliquez sur Rules et saisissez un nom de règle dans le champ Cache Rules.

  4. Sous Create Rule, définissez les conditions de correspondance pour les requêtes entrantes. Pour en savoir plus sur la création d'une expression de règle, consultez la rubrique Composition of a rule expression.

  5. Dans la section Rule Name, définissez le paramètre If requests match... sur Cache Eligibility.

  6. Dans la section Cache Eligibility, cliquez sur Eligible for Cache et configurez les paramètres suivants.

    Paramètre

    Description

    Custom Cache Keys

    Indique s'il faut activer la fonction Sort Query String.

    Configure

    Indique s'il faut supprimer le caractère ? et la chaîne de requête suivante de l'URL de la requête.

    Sort Query Strings

    • Query String : ajoute les noms et valeurs d'en-têtes de requête HTTP spécifiés à la clé de cache.

    • HTTP Request Header : ajoute les noms d'en-têtes de requête HTTP à la clé de cache si ces en-têtes existent dans la requête.

    Include these header names and values (enter header name; lowercase only)

    • Check existence (enter header name; lowercase only) : ajoute les noms et valeurs de paramètres de cookie spécifiés à la clé de cache.

    • Cookie : ajoute les noms de paramètres de cookie à la clé de cache si les cookies existent dans la requête.

    • Types de caractères pris en charge :

      • Symboles : ! # $ % & ' * + - . ^ _ ` | ~

      • Chiffres : 0-9

      • Lettres : a-z (lettres anglaises minuscules)

    Include these cookie names and values (enter cookie name; lowercase only)

    • Check existence (enter header name; lowercase only) : génère une clé de cache basée sur le type de client déduit de l'en-tête User-Agent. Valeurs valides : desktop, tablet, mobile

    • User : génère une clé de cache basée sur le pays ou la région du client, déduite de l'adresse IP du client.

    • Device Type : génère une clé de cache basée sur la langue du client, déduite de l'en-tête de requête Accept-Language.

    Country/Region

    Protège contre les attaques par tromperie de cache web tout en permettant la mise en cache du contenu statique.

  7. Cliquez sur Language.

Exemples de configuration

Scénario d'exemple

  • URL de la requête utilisateur : http://www.example.com/image.jpg?key123=321&key456=654

  • En-têtes de requête inclus dans la requête utilisateur :

    • name123:321

    • name456:654

    • User-Agent:Mozilla/5,0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537,36 (KHTML, like Gecko) Chrome/126,0.X.X Safari/537,36

    • Accept-Language:zh-CN

  • Le client utilise une adresse IP China Telecom pour accéder au service.

Configuration de la fonctionnalité

  • Cache Deception Defense : Delete parameter key456

  • OK :

    • Query String : name123

    • HTTP Request Header : name456

  • Include these header names and values (enter header name; lowercase only) : Les commutateurs Check existence (enter header name; lowercase only), User et Device Type sont tous activés.

Clé de cache générée

Fragments de clé de cache pour chaque paramètre :

  • http://www.example.com/image.jpg?key123=321

  • name123:321

  • name456

  • desktop

  • CN

  • Accept-Language:zh-CN

La clé de cache finale concatène ces fragments : http://example.com/image.jpg?key123=321name123:321name456desktopCNAccept-Language:zh-CN

Documentation connexe

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 Characteristics of rule-based features.