Edge Acceleration
  • Site Acceleration
    • Overview
    • Quickly Import and Export Site Configuration
    • Access Control
      • Token Authentication
    • Smart Acceleration
    • File Optimization
      • Smart Compression
    • Network Optimization
      • HTTP/2
      • HTTP/3(QUIC)
        • Overview
        • Enable HTTP/3
        • QUIC SDK
          • SDK Overview
          • SDK Download and Integration
          • Sample Code
            • Android
            • iOS
          • API Documentation
            • Android
            • iOS
      • IPv6 Access
      • Maximum Upload Size
      • WebSocket
      • Client IP Geolocation Header
      • Client IP Geographical Location
      • gRPC
    • URL Rewrite
      • Access URL Redirection
      • Origin-Pull URL Rewrite
    • Modifying Header
      • Modifying HTTP Response Headers
      • Modifying HTTP Request Headers
    • Custom Error Page
    • Request and Response Actions
      • Processing order
      • Default HTTP Headers of Origin-Pull Requests
      • Default HTTP Response Headers
    • Media Services
      • Audio and Video Pre-pulling
      • Just-in-Time Image Processing
      • Just-in-Time Media Processing
      • VOD Media Origin
  • L4 Proxy
    • Overview
    • Creating an L4 Proxy Instance
    • Modifying an L4 Proxy Instance
    • Disabling or Deleting an L4 Proxy Instance
    • Batch Configuring Forwarding Rules
    • Obtaining Real Client IPs
      • Obtaining Real TCP Client IPs via TOA
      • Obtaining Real Client IPs Through Protocol V1/V2
        • Overview
        • Method 1: Obtaining Real Client IPs Through Nginx
        • Method 2: Parsing Real Client IPs on Application Server
        • Format of Real Client IPs Obtained Through Proxy Protocol V1/V2
      • Transmitting Client Real IP via SPP Protocol
  • Edge DNS
    • Hosting DNS Records
      • Modifying DNS Servers
      • Configuring DNS Records
      • Advanced DNS Configuration
    • Domain Connection
      • Adding A Domain Name for Acceleration
      • Ownership Verification
      • Modifying CNAME Records
    • Domain alias
      • Overview
      • Configuration Guide
      • Batch Connecting SaaS Domain Names
      • Configuring Alias Domain Names for Disaster Recovery
    • Traffic Scheduling
      • Traffic Scheduling Management
    • Origin Configuration
      • Origin-pull configuration
        • Configuring Origin-Pull HTTPS
        • Host Header Rewrite
        • Controlling Origin-pull Requests
        • Redirect Following During Origin-Pull
        • HTTP/2 Origin-Pull
        • Range GETs
      • Load Balancing
        • Overview
        • Quickly Create Load Balancers
        • Health Check Policies
        • Viewing the Health Status of Origin Server
        • Related References
          • Load Balancing-Related Concepts
          • Introduction to Request Retry Strategy
      • Origin Group Configuration
      • Related References
        • ld Version Origin Group Compatible Related Issues
      • Collect EdgeOne origin-pull node IP
  • Edge Cache
    • Overview
    • EdgeOne Cache Rules
      • Content Cache Rules
      • Cache Key Introduction
      • Vary Feature
    • Cache Configuration
      • Custom Cache Key
      • Node Cache TTL
      • Status Code Cache TTL
      • Browser Cache TTL
      • Offline Caching
      • Cache Prefresh
    • Clear and Preheat Cach
      • Cache Purge
      • URL Pre-Warming
    • How to improve the Cache Hit Rate of EdgeOne
  • Rules Engine
    • Overview
    • Supported Matching Types and Actions
    • Rule Management
    • variables
このページは現在英語版のみで提供されており、日本語版も近日中に提供される予定です。ご利用いただきありがとうございます。

Cache Key Introduction

What is Cache Key

Cache Key is used to determine whether the file resources accessed by users hit the edge caching content of EdgeOne, and it is the unique identifier of cached resources within the node. Cache hits can help your site:
Reduce origin-pull requests and lower the bandwidth consumption of the origin.
Improve the access request speed of users.
The working principle of Cache Key is as follows:
When a file is cached in the EdgeOne edge node, the node will generate a corresponding Cache Key identifier for the file according to the Cache Key rules. By default, the Cache Key is calculated based on the client request URL and query string. When other clients initiate an HTTP request to the edge node, the node will compare the HTTP request with the Cache Key of all cached resources in the node according to the Cache Key calculation rule. If they are consistent, the corresponding cached resources will be directly responded to the client, which is a cache hit.




Cache Key's application scenarios

Cache Key is used for EdgeOne nodes to establish multi-version caching content for different versions of files. Even if the client requests through the same path, the correct user file can be responded through the calculation rules of Cache Key.

You can understand how to correctly configure Cache Key to help you correctly match the requested cache files and reduce the origin-pull rate through the following scenario examples.
For example, User A and User B have the following requests:
Request A: https://www.example.com/Image/test.jpg?version=1&time=1651752743
Request B: https://www.example.com/Image/test.jpg?version=2&time=1651758319
Scenario 1: The file paths accessed by users are completely identical, but there are version differentiations according to version parameter carried in the query string. The above requests are two different images. In this case, version parameter that affects the file version should be retained in the Cache Key to ensure that the node can correctly cache and respond to the corresponding file content.
Scenario 2: The content of the query string in the user's access URL does not affect the file content. The files corresponding to the above requests are the same and do not affect the file version. In this case, all query strings should be ignored in the Cache Key calculation to improve the hit rate of files in the node and reduce the origin-pull requests.

Customizable Cache Key content and effective rules

EdgeOne allows users to customize Cache Key rules, supports configuring query strings, HTTP request headers, or cookies to distinguish caches. You can learn how to configure custom Cache Key rules through Custom Cache Key.
Note:
1. The calculation of Cache Key is based on the HTTP request content initiated by the client to the node. The origin URL rewriting, origin follow redirect, origin HTTP request header, and Rewrite access URL do not affect the calculation of Cache Key.
2. When Token authentication is configured in EdgeOne, the authentication content will not participate in the Cache Key calculation.
3. When image processing parameters are enabled in EdgeOne, the image processing parameters carried in the request will participate in the Cache Key calculation by default.

Query string

The query string refers to the string parameters after the "?" in the request URL (including one or multiple parameters, separated by "&"), for example, color=blue&size=large in https://www.example.com/images/example.jpg?color=blue&size=large.

EdgeOne supports customizing the retention of specified query string content to distinguish caches.
Note:
When retaining the query string as the Cache Key, if the position order of the parameters changes, the Cache Key will also change.
For example, when clients initiate the following requests separately:
Request A: https://www.example.com/Image/test.jpg?version=1&type=a
Request B: https://www.example.com/Image/test.jpg?version=2&type=a
Request C: https://www.example.com/Image/test.jpg?type=a&version=1
Configuration
Cache behavior
Query string configuration is to retain all
The parameter content carried by Request A and Request B is different, corresponding to different cache versions. The parameter content of Request A and Request C is consistent, but the order is different, corresponding to different cache versions.
Query string configuration is to ignore all
Requests A, B, and C all correspond to the same cache version.
Query string configuration is to retain the specified parameter Type
The parameter order and content of Request A and Request B are completely identical, corresponding to the same cache version; the parameter content of Request B and Request C is the same, but the order is different, corresponding to different cache versions.
Query string configuration is to ignore the specified parameter Type
The remaining parameter content of Request A and Request B is not consistent, corresponding to different cache versions; the remaining parameter content of Request A and Request C is consistent, but the order is not consistent, corresponding to different cache versions.

HTTP request header

EdgeOne supports adding specified HTTP request headers to the Cache Key calculation. EdgeOne edge nodes will establish different cache versions based on the request header content. The order change of the request header does not affect the calculation of the Cache Key.
For example, specify the HTTP request header User-Agent to be included in the Cache Key calculation. The URL and parameter content of the following Request A and Request B are consistent, but the User-Agent header content is not consistent, corresponding to different cache versions.
Request A: https://www.example.com/Image/test.jpg?version=1&type=a, with User-Agent: chrome
Request B: https://www.example.com/Image/test.jpg?version=1&type=a, with User-Agent: ios

Cookie

EdgeOne supports adding specified parameters in the Cookie to the Cache Key calculation, distinguishing cache versions based on Cookie parameters and content. When multiple parameters in the Cookie participate in the Cache Key calculation, the order change of the parameters does not affect the Cache Key calculation.
For example, specify the User parameter in the Cookie to be included in the Cache Key calculation. The parameter content of the following Request A and Request B is the same, corresponding to the same cache, and the parameter content of Request A and Request C is different, corresponding to different cache versions.
Request A: https://www.example.com/Image/test.jpg?version=1&type=a, with Cookie: User=A;ID=1.
Request B: https://www.example.com/Image/test.jpg?version=1&type=a, with Cookie: User=A;ID=2.
Request C: https://www.example.com/Image/test.jpg?version=1&type=a, with Cookie: User=B;ID=1.

Learn more