在使用邊緣安全加速 ESA加速靜態資源時，ESA會將來源站點上的資源緩衝到距離用戶端最近的ESA節點上。當您訪問該靜態資源時，可以直接從ESA的緩衝節點上擷取，有效避免通過較長的鏈路回源，提高資源訪問效率。阿里雲ESA的所有節點都包含緩衝軟體，在使用者請求或者來源站點響應資源經過ESA節點時，緩衝軟體會根據需要對來源站點資源進行緩衝，並設定緩衝到期時間。
預設緩衝策略
用戶端請求只有在進入ESA緩衝組件的情況下，緩衝配置才會生效。用戶端請求是否進入緩衝組件需要按順序經過三重判斷，相關說明如下：
使用者請求類型判斷：預設只有GET、HEAD請求類型才能進入緩衝組件。
緩衝規則判斷：判斷使用者請求是否符合緩衝規則中設定的規則條件，如果符合，使用者請求將會使用緩衝規則中設定的緩衝配置（緩衝規則的生效優先順序高於全域緩衝配置），具體請參見緩衝配置生效邏輯。
請求檔案類型判斷：判斷使用者請求需要訪問的檔案類型是否符合預設緩衝的副檔名中的檔案類型，如果符合，使用者請求將會使用全域配置中設定的緩衝配置。
預設緩衝的副檔名
預設情況下，使用者請求的資源的檔案尾碼是下面這些類型時，使用者請求會經過緩衝模組（即對應繞過緩衝功能的預設規則），至於資源在緩衝模組上的緩衝到期時間，還需要按該資源命中的緩衝規則。
如果要緩衝的資源類型不在以下檔案類型中，可以參閱規則以建立緩衝所需資源的規則策略。
檔案類型 | 副檔名說明 |
文檔檔案 |
|
影像檔 |
|
音頻檔案 |
|
視頻檔案 |
|
壓縮檔 |
|
執行檔案（可執行程式/安裝包） |
|
字型檔 |
|
指令碼與代碼檔案 |
|
設計與向量圖形檔案 |
|
緩衝配置生效邏輯
對於來源站點響應的200、203、206、300、301、308、410狀態代碼，緩衝到期時間按以下規則生效。
節點緩衝到期時間功能有四種模式，這四種模式分別具備不同的緩衝生效邏輯：
優先遵循來源站點緩衝策略（如果存在），否則使用預設緩衝策略：如果來源站點響應資訊中帶有用於設定緩衝策略的響應標題欄位，包括：
Cache-Control、Expires、Last-Modified、ETag，則遵循來源站點的緩衝策略；如果來源站點響應資訊中不帶有Cache-Control、Expires、Last-Modified、ETag其中任一欄位，則遵循ESA的預設緩衝策略。優先遵循來源站點緩衝策略（如果存在），否則不緩衝：如果來源站點響應資訊中帶有用於設定緩衝策略的響應標題欄位：
Cache-Control，則遵循來源站點的緩衝策略；如果來源站點響應資訊中不帶有Cache-Control欄位，則不緩衝。不緩衝：ESA節點收到的所有來源站點響應資源均不緩衝。
忽略來源站點緩衝策略，使用自訂緩衝TTL：忽略來源站點響應資訊中的緩衝策略的響應標題欄位，包括：
Cache-Control、Expires、Last-Modified、ETag，使用ESA上設定的緩衝到期時間。
異常狀態代碼緩衝規則
對於204、305、404、405、414、424、429、500、501、502、503和504狀態代碼，緩衝規則如下：
如果來源站點返回
set-cookie回應標頭，ESA不緩衝。如果來源站點沒有返回
set-cookie回應標頭，則判斷ESA控制台是否配置狀態代碼到期時間：若已配置，則遵循ESA控制台配置的狀態代碼到期時間來緩衝。若配置了多條規則，規則序號越小則優先順序越高。
若未配置，則按照來源站點設定的
Pragma、Cache-Control或者Expires回應標頭來緩衝。
如果來源站點也沒有配置
Pragma、Cache-Control或者Expires回應標頭，則預設緩衝1秒。
對於302、307和403狀態代碼，緩衝規則如下：
如果來源站點返回
set-cookie回應標頭，ESA不緩衝。如果來源站點沒有返回
set-cookie回應標頭，則判斷ESA控制台是否配置狀態代碼到期時間：若已配置，則遵循ESA控制台配置的狀態代碼到期時間來緩衝。若配置了多條規則，規則序號越小則優先順序越高。
若未配置，則按照來源站點設定的
Pragma、Cache-Control或者Expires回應標頭來緩衝。
如果來源站點也沒有配置
Pragma、Cache-Control或者Expires回應標頭，則不緩衝。
對於其他異常狀態代碼，如400狀態代碼，緩衝規則如下：
如果來源站點返回
set-cookie回應標頭，ESA不緩衝。如果來源站點沒有返回
set-cookie回應標頭，則遵循ESA控制台配置的狀態代碼到期時間來緩衝。若配置了多條規則，規則序號越小則優先順序越高。其他情境不緩衝。
對於採用range方式回源的請求，ESA節點如果收到來源站點響應的非206狀態代碼，則ESA節點會刪除已緩衝的分區檔案（回源逾時不會刪除快取檔案）。Range回源情況下，來源站點會把一個大檔案分割成多個小的檔案分區來返回給ESA節點。比如有個檔案被分割成了10個分區，ESA節點已經緩衝了5個分區，在請求第6個分區時，來源站點響應了5xx狀態代碼，這時會把前面已經緩衝的5個分區全部刪除。
緩衝響應資訊說明
ESA節點提供了正常化響應資訊，以方便使用者調試HTTP請求和響應，與緩衝相關的響應標題包含以下內容：
Ali-Swift-Global-Savetime: 表示該資源首次進入到ESA邊緣節點（由網站的緩衝架構決定，可能是L2節點，也可能其他的緩衝層級節點）的時間。格式為Unix時間戳記，例如：1745053111，表示2025-04-19 16:58:31。Date：表示來源站點響應該資源給ESA節點的時間。ESA節點在與來源站點對該資源進行重新驗證（回源請求中攜帶
If-Modified-Since標題或If-None-Match標題），並且來源站點響應狀態代碼為304的情況下，將會更新Data資訊。格式為GMT（格林尼治標準時間）時區的時間格式，例如：
Sat, 19 Apr 2025 08:58:31 GMT。
X-Site-Cache-Status: 表示本次請求的資源在ESA節點上的緩衝狀態，不同狀態的說明詳見下表。狀態
說明
HIT
在ESA節點的緩衝中找到了該資源。
MISS
在ESA節點的緩衝中找不到該資源，而是由來源站點伺服器提供該資源。
EXPIRED
該資源已在ESA節點的緩衝中找到，但已到期，並由來源站點伺服器提供（來源站點響應狀態代碼為200或206）。
STALE
該資源是由ESA的緩衝提供的，但已到期，具體分為三種情況：
ESA設定為優先遵循來源站點緩衝策略，且來源站點響應中設定了
Cache-Control:stale-while-revalidate=<seconds>，在指定的時間內，ESA在回源重新驗證該資源的同時響應到期緩衝給用戶端。ESA設定為優先遵循來源站點緩衝策略，且來源站點響應中設定了
Cache-Control:stale-if-error==<seconds>，在指定的時間內，如果ESA無法訪問來源站點（來源站點響應逾時）以檢索更新的資源，那麼將響應到期緩衝給用戶端。ESA開啟了響應到期緩衝，如果ESA無法訪問來源站點（來源站點響應逾時）以檢索更新的資源，那麼將響應到期緩衝給用戶端。
BYPASS
表示該資源繞過ESA緩衝，具體分為兩種情況：
ESA未設定為優先遵循來源站點緩衝策略，並且ESA設定緩衝時間為0。
ESA設定為優先遵循來源站點緩衝策略，來源站點響應的
Cache-Control值是這三種之一：no-cache、no-store、max-age=0。
REVALIDATED
該資源由ESA的緩衝提供，但是已到期。ESA的回源請求中攜帶
If-Modified-Since標題或lf-None-Match標題對該資源做了重新驗證（來源站點響應狀態代碼為304）。DYNAMIC
ESA認為該資源為動態內容，並且在ESA上未明確設定針對該資源的緩衝策略。該資源由來源站點伺服器提供。
X-Swift-Cachetime: 表示該資源在ESA節點上的緩衝到期時間，單位為秒。X-Swift-Cachetime並不完全等於在ESA中設定的緩衝到期時間，具體為：X-Swift-Cachetime=Ali-Swift-Global-Savetime+ ESA設定的緩衝到期時間 -X-Swift-SaveTime。因此可能出現以下幾種情況：X-Swift-Cachetime等於在ESA中設定的緩衝到期時間，例如：3600秒。X-Swift-Cachetime略小於ESA設定的緩衝到期時間，例如：ESA設定的緩衝到期時間為300秒，但是X-Swift-Cachetime為295秒，這種情況可能的原因有以下：L1節點回源L2節點的延遲較大
L1節點與L2節點上的時鐘不同步
X-Swift-Cachetime的數值為負數，這種情況可能的原因是使用者對ESA設定的緩衝到期時間做了調整，用戶端訪問的時候，L1節點上的緩衝已經到期，L2節點上的緩衝尚未到期，例如：原先ESA設定的緩衝到期時間為3600秒，後來調整到了300秒，用戶端首次訪問之後過600秒再次訪問，這時候收到X-Swift-Cachetime:-300，可通過重新整理緩衝可以解決。
X-Swift-SaveTime: 表示該資源首次進入用戶端請求訪問的當前節點（L1節點）的時間。格式為GMT（格林尼治標準時間）時區的時間格式，例如：Sat, 19 Apr 2025 08:58:31 GMT。
檔案不緩衝策略說明
如果符合以下情況，ESA節點將完全不快取檔案，透傳所有對檔案的請求。
緩衝回源校正策略說明
ESA節點上的快取檔案到期之後，緩衝回源校正機制會在下次用戶端請求該檔案時發揮作用。此時，ESA節點會向來源站點發起校正請求：如果源檔案未發生變化，來源站點將會響應304 not-modified，ESA節點將會繼續使用已快取檔案響應給用戶端，無需重新下載檔案，有效提升用戶端請求的響應速度，並減少來源站點的響應流量。
特殊策略配置：檔案快取0秒，ESA節點對每次請求都回源校正。
將ESA緩衝配置中邊緣緩衝到期時間的模式設定為優先遵循來源站點緩衝策略（如果存在），否則使用預設緩衝策略。並且來源站點響應滿足以下兩種情況：
Cache-Control: no-cacheCache-Control: max-age=0
常規策略配置：來源站點響應緩衝校正相關的策略，ESA節點按實際策略執行。
將ESA緩衝配置中邊緣緩衝到期時間的模式設定為優先遵循來源站點緩衝策略（如果存在），否則使用預設緩衝策略。並且來源站點響應滿足以下某個緩衝校正策略：
must-revalidateproxy-revalidatestale-while-revalidate=secondsstale-if-error=seconds
緩衝校正策略說明
策略名稱稱
策略說明
策略樣本
must-revalidate這個指令指示任何緩衝（不僅僅是代理緩衝，還包括瀏覽器緩衝等）在返回緩衝的響應之前，如果資源已經到期，則必須先回原始伺服器驗證資源的新鮮度。即使使用者離線或者網路不可用，緩衝也不能直接使用到期資源，除非成功驗證了資源未發生變化。
Cache-Control: max-age=3600, must-revalidate表示該資源在到期之後必須要回源校正資源的新鮮度。proxy-revalidate這個指令與
must-revalidate類似，但它只應用於共用快取（如CDN、Proxy 伺服器），而不針對私人緩衝（如使用者的瀏覽器緩衝）。這意味著，在使用proxy-revalidate時，對於到期的資源，只有共用快取需要在提供快取複本前向來源站點進行有效性驗證，而用戶端的私人緩衝則不受此限制。Cache-Control: max-age=3600, proxy-revalidate表示該資源在到期之後必須要回源校正資源的新鮮度。stale-while-revalidate=seconds這個指令指示緩衝可以在資源到期後，在指定的時間段（以秒為單位）內繼續提供舊的緩衝版本，同時在後台非同步地向原始伺服器請求最新的內容進行更新。當你希望減少使用者等待時間，並且可以接受在短時間內顯示可能不是最新鮮的內容時非常有用。
Cache-Control: max-age=3600, stale-while-revalidate=60表示該資源在首次發布後的3600秒（1小時）內被視為新鮮；一旦到期，在接下來的60秒內，仍然可以提供給使用者，但同時會嘗試從原始伺服器擷取更新。stale-if-error=seconds這個指令指示當嘗試從原始伺服器擷取最新內容失敗時（比如伺服器宕機或網路錯誤），這個指令允許節點返回已經到期但仍被緩衝的響應。它定義了一個時間段（以秒為單位），在此期間如果遇到錯誤，可以回退到使用到期的緩衝內容。用於提升系統的容錯能力，確保即使原始伺服器不可用，使用者也能訪問到之前緩衝的內容，從而改善使用者體驗並減少服務中斷的影響。
Cache-Control: max-age=86400, stale-if-error=604800表示該資源在首次發布後的86400秒（24小時）內視為新鮮；若在這之後嘗試重新驗證失敗，則在未來的一周（604800秒）內仍可提供最後一次成功的緩衝版本。