配置自訂緩衝鍵（Cache Key），開發人員可以根據HTTP請求的不同部分（例如URI、請求參數、HTTP要求標頭或自訂變數等）制定規則來產生Cache Key，將訪問同一個檔案的一類請求轉化為統一的Cache Key，提高快取命中率，降低回源率，減少請求的回應時間和頻寬消耗。
注意事項
自訂 CacheKey 與忽略參數
自訂 CacheKey 的參數操作功能與忽略參數功能均可控制 URL 查詢參數是否參與緩衝鍵的產生。同時開啟兩項功能時，可能導致緩衝鍵建置規則衝突，出現快取命中率下降或緩衝內容異常。
如果已開啟自訂 CacheKey 的參數操作，建議關閉忽略參數功能，避免規則相互覆蓋。自訂 CacheKey 的參數操作已涵蓋忽略參數的能力（通過刪除或僅保留操作實現），且提供更靈活的參數控制。
如果當前使用忽略參數功能，可參考以下對比表格，選擇是否遷移到自訂 CacheKey 的參數操作。
情境 | 忽略參數 | 自訂 CacheKey |
在緩衝鍵中忽略所有請求參數 | 忽略參數設定為是，保留指定參數為空白 | 添加一條 請求參數 處理策略：
|
在緩衝鍵中僅保留請求參數 | 忽略參數設定為是，保留指定參數設定為 | 添加一條 請求參數 處理策略：
|
在緩衝鍵中僅刪除請求參數 | 刪除指定參數設定為 | 添加一條 請求參數 處理策略：
|
如果需要在忽略或保留參數的基礎上，進一步修改參數值或新增額外參數，建議使用自訂 CacheKey 的參數操作替代忽略參數功能。
規則引擎引用時的執行順序
當本功能引用規則引擎中配置的規則條件時，執行順序不是按照本功能配置的優先順序順序執行，而是按照規則引擎中配置的規則條件的優先順序順序來執行。
緩衝重新整理
配置自訂 CacheKey 後，DCDN 節點上緩衝的檔案將使用處理後的緩衝鍵進行索引。通過 URL 重新整理緩衝時，提交的 URL 必須與 DCDN 節點上實際儲存的緩衝鍵一致，否則重新整理操作無法命中目標緩衝。
例如，配置了 URI 替換規則將 `/a/b/image.jpg` 替換為 `/c/image.jpg`，則 DCDN 節點上該檔案的緩衝鍵為 `http://aliyundoc.com/c/image.jpg`。重新整理該檔案的緩衝時，需要提交 `http://aliyundoc.com/c/image.jpg`（處理後的緩衝鍵），而非用戶端的原始請求 URL。
如果配置了參數操作（如刪除或修改參數），重新整理時同樣需要使用參數處理後的 URL 作為重新整理地址。建議在配置自訂 CacheKey 規則後，記錄最終產生的緩衝鍵格式，便於後續執行緩衝重新整理操作。
回源參數改寫
自訂 CacheKey 僅影響 DCDN 節點上緩衝鍵的建置規則，不會修改實際的回源 URL。DCDN 節點回源時仍然使用用戶端原始請求的 URL 向來源站點發起請求。如需改寫回源請求的參數或路徑，請使用回源改寫功能。
例如，用戶端請求 http://example.com/image.jpg?key1=1&key2=2，配置自訂 CacheKey 刪除參數 key1 後，緩衝鍵變為 http://example.com/image.jpg?key2=2，但回源時 DCDN 節點仍然向來源站點請求原始 URL http://example.com/image.jpg?key1=1&key2=2。
使用情境
自訂Cache Key功能不會修改回源的URL，僅會修改請求的緩衝標識，回源的請求和用戶端發起的請求內容保持一致。
Cachekey 是檔案在 DCDN 節點上緩衝時的唯一標識，每個快取檔案都對應一個 Cachekey。預設的 Cachekey 為用戶端請求的完整 URL（含參數）。
情境一
客戶不同請求的 URL 中含有複雜的參數，因此即使多個請求訪問的是同一個檔案，但由於 URL 參數不同，DCDN 節點會視為請求不同檔案而將不同請求緩衝成多個檔案，造成回源的請求增加。
可通過自訂 Cachekey 規則將同一類請求的 Cachekey 統一，降低回源率。
情境二
用戶端請求的 URL 一樣時，DCDN 將視為請求同一個檔案。但實際上請求的 HTTP Header 中攜帶了 client 欄位區分了用戶端系統，希望請求不同檔案。
此時可通過自訂 Cachekey 將 client 欄位的值拼接至 Cachekey，兩個請求即可識別為 2 個不同的 Cachekey。
操作步驟
登入DCDN控制台。
在左側導覽列，單擊域名管理。
在域名管理頁面，單擊目標網域名稱對應的配置。
在指定網域名稱的左側導覽列，單擊緩衝配置。
在自訂Cachekey頁簽配置 Cachekey。
說明支援對 URI、參數操作、HTTP Header 進行修改，同時支援自訂變數，從請求中提取需要的欄位。最終的 Cachekey 將由 URI、參數操作、HTTP Header、自訂變數四部分組合而成。
參數類型
操作說明
規則條件
規則條件能夠對使用者請求中攜帶的各種參數資訊進行識別，以此來決定某個配置是否對該請求生效。
重要引用規則條件時，按所關聯規則條件的優先順序匹配，而非按功能自身的配置順序匹配。
不使用：不使用規則條件。
若需新增或編輯規則條件，請在規則引擎中進行管理。
URI
當用戶端請求的 URI 與配置中的源URI相匹配時，系統會用配置中的目標URI替換源URI來產生 Cachekey。
支援配置多個 URI 替換策略。若存在多條策略，則按照從上到下的順序依次進行匹配。一旦匹配到某個源URI，系統將使用該策略對應的目標URI執行替換操作，並停止與後續策略的匹配。
源URI：以正斜線（/）開頭的 URI，不含 http：//頭及網域名稱。支援
PCRERegex。目標URI：以正斜線（/）開頭的 URI，不含 http：//頭及網域名稱。
參數操作
操作的對象是使用者發起的原始請求 URL 中攜帶的參數，可以對參數進行新增、刪除、修改、僅保留操作，操作後的結果將會拼接到 Cachekey 中。支援設定多個操作，存在多個操作的情況下，將會從上到下按順序逐個執行。
新增：將新增的請求參數拼接到 Cachekey 中。例如：原始 URL 為
http://image.example.com/cat.jpg，新增一個請求參數type=jpg，則 Cachekey 為http://image.example.com/cat.jpg?type=jpg。刪除：在產生 Cachekey 時刪除原始請求 URL 中的指定參數。例如：原始 URL 為
http://image.example.com/cat.jpg?type=jpg，刪除參數type，則 Cachekey 為http://image.example.com/cat.jpg。修改：在產生 Cachekey 時修改原始請求 URL 中的指定參數。例如：原始 URL 為
http://image.example.com/cat.jpg?type=jpg，修改參數type=png，則 Cachekey 為http://image.example.com/cat.jpg?type=png。僅保留：在產生 Cachekey 時僅保留原始請求 URL 中的指定參數。例如：原始 URL 為
http://image.example.com/cat.jpg?type=jpg&path=image，保留參數type，則 Cachekey 為http://image.example.com/cat.jpg?type=jpg。
HTTP HEADER
將用戶端原始請求中攜帶的指定 HTTP Header 的值拼接到 Cachekey 中。支援配置多個 HTTP Header 名稱（多個名稱之間用空格分隔），每個 HTTP Header 的值將按順序拼接到 Cachekey 中。
例如：原始 URL 為
http://image.example.com/cat.jpg，用戶端請求攜帶了一個HTTP Header（path:image）；如果HTTP Header中設定了path這個要求標頭，則 Cachekey 為http://image.example.com/cat.jpgimage。自訂變數
可以使用Regex來匹配用戶端原始請求中攜帶的指定請求參數的值、指定 HTTP Header 的值、指定 Cookie 參數的值、指定的 URI，Regex匹配命中時，將對應的值拼接到 Cachekey 中。具體使用請參見配置樣本。
單擊確定，完成配置。
配置樣本
URI
用戶端的請求http://aliyundoc.com/a/b/image.jpg和http://aliyundoc.com/a/b/c/image.jpg 將視為請求同一個檔案，該檔案的 Cachekey 為http://aliyundoc.com/c/image.jpg。
參數操作
用戶端的請求http://aliyundoc.com/a/b/image.jpg?delete_par=1&modify_par=1 將按規則添加add_par=1，刪除delete_par，將modify_par的值修改為2，最終轉化為http://aliyundoc.com/a/b/image.jpg?modify_par=2&add_par=1。
參數操作中，如對同一個變數同時進行了多個操作，則各種操作的生效優先順序：新增>；刪除>；僅保留>；修改。
HTTP HEADER
用戶端請求的 HTTP Header 的User-Agent和Accept-Language的值將被拼接到 Cachekey 中。例如請求http://aliyundoc.com/a/b/image.jpg中的User-Agent=Mozilla/5.0 (Linux; X11)，Accept-Language=en，則該請求的 Cachekey 為：http://aliyundoc.com/a/b/image.jpgMozilla/5.0(Linux;X11)en。
自訂變數
樣本一
變數名為language，來源為Request Header，來源欄位名為Accept-Language，匹配規則為 ([%w]+),([%w]+)，Variant 運算式為$1aa。
用戶端的請求http://aliyundoc.com/a/b/image.jpg且攜帶 HTTP 要求頭Accept-Language=en,ch ，則匹配規則將匹配到en賦值給Variant 運算式中的$1。Variant 運算式還將在末尾拼接上aa，得到enaa的變數並取別名為language，拼接在 URL 後方形成最終的 Cachekey：http://aliyundoc.com/a/b/image.jpgenaa。
Variant 運算式中的$n的含義是匹配規則中第n個括弧所匹配到的內容。例如樣本一中Accept-Language=en,ch，匹配規則為([%w]+),([%w]+)，則$1=en，$2=ch。
樣本二
變數名為expired，來源為Request Cookie，來源欄位名為a，匹配規則為[%w]+:(.*)，Variant 運算式為 $1。
用戶端的請求http://aliyundoc.com/a/b/image.jpg且攜帶Cookie a=expired_time:12635187，則匹配規則將匹配到12635187賦值給Variant 運算式中的$1並取別名為expired，拼接在 URL 後方形成最終的 Cachekey：http://aliyundoc.com/a/b/image.jpg12635187。
樣本三
同時設定 URI 規則和自訂變數。
URI：
將所有 URI 符合
/abc/.*/abc的請求都合并成/abc。
自訂變數：
變數名為
testname，來源為Path，匹配規則為/abc/xyz/(.*)，Variant 運算式為$1。
用戶端的請求 URL
http://aliyundoc.com/abc/xyz/abc/image.jpg，按 URI 的配置 Cachekey 將被合并成http://aliyundoc.com/abc/image.jpg， 然後根據自訂變數的配置該 URL 將會命中/abc/xyz/(.*)，此時$1將被賦值為abc並拼接到 Cachekey 中，形成最終的 Cachekey：http://aliyundoc.com/abc/image.jpgabc，從而達到兩個規則群組合使用，實現更複雜的緩衝邏輯。如果沒有匹配到 CacheKey 的自訂變數，則Variant 運算式
$1就不會被拼接到 CacheKey 中。