通過配置緩衝到期時間規則，可以精細化控制CDN節點的資源緩衝時間長度，以平衡內容更新、訪問效能與回源成本。此文檔介紹緩衝規則的工作原理、配置方法、驗證、排障流程及最佳實務。
工作原理
請求到達CDN節點時，系統遵循以下決策流程（序號越小，優先順序越高）決定是響應快取複本，還是回源擷取最新內容。
不緩衝資源：來源站點響應
pragma:no-cache、cache-control:no-cache（或者no-store，或者max-age=0）時，CDN遵循來源站點的策略，完全不緩衝資源。遵循控制台緩衝規則：CDN控制台為指定目錄或檔案尾碼名設定規則，且來源站點未配置上述不緩衝規則，此時控制台緩衝規則為最高優先順序策略。
多條控制台緩衝規則匹配時的優先順序邏輯：
情境
優先順序邏輯
樣本
權重不同
權重值（1-99）大的規則優先生效。
規則A（目錄
/image/，權重50）和規則B（尾碼.jpg，權重90）都匹配image/a.jpg，則規則B生效。權重相同
先建立的規則優先生效。
為網域名稱配置權重同為60的目錄規則（
/static/）和尾碼規則（.js），若目錄規則建立時間早於尾碼規則，則/static/app.js命中目錄規則。請求命中某條緩衝規則後，不再繼續匹配其他規則。
預設情況下，若來源站點響應
Pragma: no-cache或Cache-Control: no-cache/no-store/max-age=0，CDN節點不緩衝該資源。如果需要強制緩衝資源，可以在控制台配置緩衝到期時間時勾選忽略來源站點不緩存標題。
CDN遵循來源站點緩衝策略：若請求未命中任何CDN控制台規則，或命中的規則開啟了優選遵循來源站點緩衝策略，此時CDN將遵循來源站點的HTTP響應標題。回應標頭的優先順序由高至低為：
cache-control>expires>last-modified>ETag。回應標頭
CDN 如何處理
注意事項與樣本
Cache-Control
優先用
s-maxage（CDN 緩衝時間長度），其次max-age。樣本：
s-maxage=86400, max-age=3600Expires
到期時間，僅當無
Cache-Control時生效。樣本：
Expires: Wed, 21 Oct 2025 07:28:00 GMTLast-Modified
Last-Modified是一個時間戳記，表示資源最後被修改的時間。緩衝時間計算規則如下：
（目前時間-
last-modified）* 0.1，計算結果在10秒~3600秒及之間的，取計算結果時間；小於10秒的，按照10秒處理；大於3600秒的，按照3600秒處理。樣本：
Last-Modified: Wed, 21 Oct 2023 07:28:00 GMTETag
ETag是伺服器為每個資源產生的一個唯一識別碼，通常是一個雜湊值或版本號碼。ETag預設緩衝10秒。樣本：
ETag: "abc123"CDN不緩衝策略：若沒有命中CDN控制台的緩衝規則，並且來源站點也沒有返回
Cache-Control等緩衝回應標頭，則CDN執行不緩衝策略。
CDN僅對來源站點響應200, 203, 206, 300, 301, 308, 410狀態代碼的請求執行緩衝策略。如需緩衝其他狀態代碼的請求（例如404），需在 緩衝配置 > 狀態代碼到期時間 版面設定。
操作步驟
控制台（推薦）
CDN控制台的網域名稱管理頁，單擊目標網域名稱右側的管理。
在缓存配置 > 缓存过期时间頁面單擊添加，配置緩衝規則。
參數名
說明
預設值/樣本
类型
支援按目錄或檔案尾碼名指定資源範圍。
• 目錄：為路徑下所有資源統一設定緩衝規則。
• 檔案尾碼名：為指定類型的檔案統一設定緩衝規則。目錄、檔案尾碼名
地址
根據所選類型填寫：
• 目錄：以/開頭（如/static/），/可匹配所有路徑，每次僅支援添加一條。
• 檔案尾碼名：輸入一個或多個尾碼，用英文逗號分隔（如jpg,png,css），區分大小寫，不支援豎線（|）或其他符號。/static/、jpg,png,css过期时间
資源在CDN節點的緩衝時間長度，最長3年。
• 不常更新的靜態資源（如圖片、安裝包）：建議 ≥ 1 個月。
• 頻繁更新的靜態資源（如 JS/CSS）：建議設定為較短時間（如 1～7 天）。
• 動態內容（如 PHP/JSP）：建議設為 0 秒（不緩衝）。0 秒～3 年
優先遵循來源站點緩衝策略
預設關閉。開啟後，優先採用來源站點緩衝策略，覆蓋本規則配置。
關閉
忽略來源站點不緩存標題
開啟後，CDN 將忽略來源站點返回的以下不緩衝指令：
Cache-Control: no-store、no-cache、max-age=0，以及 Pragma: no-cache，仍按CDN控制台規則緩衝。關閉
客戶端跟隨CDN緩衝策略
開啟後，CDN 會將自身生效的緩衝策略（如
max-age=3600）通過回應標頭返回給用戶端。關閉
強制內容重新驗證
僅在到期時間設為 0 秒時生效。
• 關閉（預設，等同於緩衝策略no-store）：CDN節點不快取檔案，每次請求都需要回源擷取內容。
• 開啟（等同於緩衝策略no-cache）：CDN節點會快取檔案，但每次請求都需要回源驗證緩衝內容（304機制）。適用於需要即時驗證但希望減少來源站點頻寬壓力的情境。關閉
权重
規則優先順序，取值 1～99，數值越大優先順序越高。當多條規則匹配同一資源時，權重值大的規則優先生效；若權重相同，先建立的規則優先生效。建議為具體路徑或尾碼設定高權重，為根目錄
/設定低權重，以實現精細化控制。1～99
規則條件
可基於請求中的參數（如 Header、URL 參數等）進一步限定規則生效範圍。預設不使用；如需配置，請通過規則引擎管理。引用規則條件時，按所關聯規則條件的優先順序匹配，而非按功能自身的配置順序匹配。
不使用
緩衝規則匹配邏輯
CDN 緩衝到期時間支援兩種規則類型，匹配行為有所不同：
目录：使用路徑首碼匹配。配置
/static/將匹配該目錄下所有資源（如/static/image/1.jpg、/static/css/style.css）；配置/將匹配所有路徑。目錄路徑須以正斜線（/）開頭，每條規則僅支援添加一個目錄。文件后缀名：使用尾碼名精確匹配。輸入的尾碼名不帶點（
.），多個尾碼名以半形逗號分隔（如jpg,css,js）。尾碼名僅允許字母和數字組合，無特定尾碼限制——以下類型均可配置：常見靜態資源尾碼：
jpg、png、gif、css、js、html字型檔尾碼：
ttf、otf、woff、woff2、eot動態網頁面尾碼：
php、aspx、jsp其他任意字母數字組合的尾碼
如果同時配置了多條緩衝規則（如一條目錄規則和一條尾碼名規則），當同一請求匹配多條規則時，以权重更高的規則為準。權重相同時，先建立的規則優先生效。具體優先順序邏輯請參見上方「工作原理」章節。
如果為緩衝規則關聯了規則條件（通過規則引擎配置），多個條件之間為"且"（AND）關係，即請求需同時滿足所有條件才會命中該規則。
若將全站動態尾碼（如
aspx）設為不緩衝，需確保不影響需要緩衝的同類型靜態資源。若需緩衝字型檔，需單獨添加包含對應尾碼（如ttf,otf,woff,woff2,eot）的規則。
API
調用BatchSetCdnDomainConfig介面，可以大量設定網域名稱。更多功能參數的配置方法，敬請參考網域名稱配置功能函數。
使規則變更立即生效
配置變更或新增規則，僅對新緩衝的資源生效。變更前已緩衝的資源，將繼續沿用舊的緩衝策略直至到期。
要使新規則立即對全網生效，必須手動清理已有緩衝。如果是規則變更，通過重新整理和預熱資源功能執行重新整理操作；如果是新增規則，通過預熱資源功能執行預熱操作。
生效驗證
配置完成後，可通過curl命令或瀏覽器開發人員工具查看資源的HTTP響應標題，以判斷緩衝是否按預期工作。
1. 執行驗證命令
在終端上執行以下命令進行測試。
curl -I "https://your.domain.com/path/to/file.jpg"2. 解讀關鍵回應標頭
響應標題 | 常見值與解讀 |
| 指示請求是否命中CDN緩衝。 |
| 開啟"用戶端跟隨CDN緩衝策略"後，此標題會顯示CDN傳遞給瀏覽器的緩衝指令，如 |
| 資源在CDN節點上配置的緩衝總時間長度，單位為秒。 |
應用於生產環境注意事項
版本化檔案名稱（推薦）：更新靜態資源（如
style.css）時，使用帶版本或雜湊值的新檔案名稱（如style-v2.css或style-a1b2c3d.css），並更新HTML中的引用。此方式無需手動重新整理緩衝，可確保使用者立即擷取最新內容，是推薦的緩衝更新方式。動靜分離：為動態和靜態資源使用不同網域名稱或目錄路徑，並配置獨立的、高權重的緩衝規則，以避免策略混淆。例如，為
/static/目錄下的所有資源設定長緩衝，為/api/目錄下的資源設定不緩衝。善用瀏覽器緩衝：開啟"用戶端跟隨緩衝策略"，可減少對CDN的重複請求，提升載入速度並節省CDN流量。
避免緩衝時間過短：過短的緩衝時間會導致CDN頻繁回源，無法起到加速效果，反而增加來源站點的流量消耗和成本。
注意緩衝時間過長：過長的緩衝時間會導致用戶端擷取資料更新不及時。對於需頻繁更新的內容，務必配合重新整理快取作業或使用版本化檔案名稱。
遊戲行業及小檔案情境：對於遊戲行業的小檔案資源（如設定檔、素材包），若更新頻率較低（例如每周或每兩周更新一次），建議將緩衝到期時間設定為 15 天或與資源實際更新周期保持一致，以平衡更新速度與加速效果。過短的緩衝時間會導致頻繁回源，影響加速效果；過長則可能導致使用者擷取到舊版本資源。建議結合重新整理預熱功能，在版本更新時主動重新整理緩衝。
HTTP協議緩衝控制機制說明
在HTTP協議中定義了三種不同類型的協議頭部來實現緩衝控制相關的機制：