配置自訂Cachekey，開發人員可以根據HTTP請求的不同部分（例如URI、請求參數、HTTP要求標頭或自訂變數等）制定規則來產生Cachekey，將訪問同一個檔案的一類請求轉化為統一的Cachekey，避免將同一類請求緩衝為不同檔案的問題，從而提高緩衝的命中率，降低回源率，減少請求的回應時間和頻寬消耗。
注意事項
由於功能特性，自訂CacheKey和忽略參數配置功能存在衝突。如果您已經配置了忽略參數，那麼CDN節點在處理使用者請求時，會去除請求URL中攜帶在
?之後的參數，這將導致CacheKey中配置的請求參數不可用。開啟自訂CacheKey功能前，請確保您的忽略參數沒有設定。自訂Cachekey功能不會修改回源的URL，僅會修改請求的緩衝標識，回源的請求和用戶端發起的請求內容保持一致。
URL重新整理功能目前無法重新整理設定了自訂Cachekey以後的緩衝內容。
使用情境
自訂Cachekey功能不會修改回源的URL，僅會修改請求的緩衝標識，回源的請求和用戶端發起的請求內容保持一致。
Cachekey是一個檔案在CDN節點上緩衝時唯一的身份ID，每個在CDN節點上緩衝的檔案都對應一個Cachekey。檔案的Cachekey預設為用戶端請求的URL（帶參數）。
情境一
客戶不同請求的URL中含有複雜的參數，因此即使多個請求訪問的是同一個檔案，但由於URL參數不同，CDN節點會視為請求不同檔案而將不同請求緩衝成多個檔案，造成回源的請求增加。
可通過自訂Cachekey規則將同一類請求的Cachekey統一，降低回源率。
情境二
用戶端請求的URL一樣時，CDN將視為請求同一個檔案。但實際上請求的Http Header中攜帶了client欄位區分了用戶端系統，希望請求不同檔案。
此時可通過自訂Cachekey將client欄位的值拼接至Cachekey，兩個請求即可識別為2個不同的Cachekey。
操作步驟
登入CDN控制台。
在左側導覽列，單擊域名管理。
在域名管理頁面，找到目標網域名稱，單擊操作列的管理。
在指定網域名稱的左側導覽列，單擊缓存配置。
在自訂Cachekey頁簽下，單擊配置，配置Cachekey。
參數類型
操作說明
規則條件
規則條件能夠對使用者請求中攜帶的各種參數資訊進行識別，以此來決定某個配置是否對該請求生效。
不使用：不使用規則條件。
若需新增或編輯規則條件，請在規則引擎中進行管理。
URI
源URI：以正斜線（/）開頭的URI，不含http://頭及網域名稱。支援PCRERegex。
目標URI：以正斜線（/）開頭的URI，不含http://頭及網域名稱。操作結果是使用改寫後的目標URI來拼接Cachekey。
請求參數
操作的對象是使用者發起的原始請求URL中攜帶的參數，可以對參數進行新增、刪除、修改、保留操作，操作後的結果將會拼接到Cachekey中。
HTTP Header
操作的對象是使用者發起的原始請求中攜帶的HTTP Header，可以將多個HTTP Header的值拼接到Cachekey中。
自訂變數
可使用Regex從使用者發起的原始請求中的請求參數、HTTP Header、Cookie、URI中截取出任意欄位拼接到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。
用戶端的請求URLhttp://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中。
樣本四
同時設定規則條件和自訂變數，使來自Mobile端和PC端的請求產生不同的Cachekey。
Mobile規則條件：
User-Agent包含*Mobile*,*Android*,*iPhone*,*ipad*其中任意一個
PC規則條件：
User-Agent不包含*Mobile*,*Android*,*iPhone*,*ipad*其中任意一個
Mobile自訂Cachekey：
規則條件選擇Mobile，自訂變數的變數名為Mobile，來源為Path，匹配規則為/，Variant 運算式為+mobile。
PC自訂Cachekey：
規則條件選擇PC，自訂變數的變數名為PC，來源為Path，匹配規則為/，Variant 運算式為+pc。
用戶端的請求URLhttp://aliyundoc.com/image.jpg，根據User-Agent的值，請求分別命中Mobile端和PC端的自訂Cachekey規則。Mobile端最終產生的Cachekey為：http://aliyundoc.com/image.jpg+mobile；PC端最終產生的Cachekey為：http://aliyundoc.com/image.jpg+pc。