預設緩衝策略和緩衝生效邏輯 - Edge Security Acceleration

預設緩衝策略

用戶端請求只有在進入ESA緩衝組件的情況下，緩衝配置才會生效。用戶端請求是否進入緩衝組件需要按順序經過三重判斷，相關說明如下：

使用者請求類型判斷：預設只有 GET、HEAD 請求類型才能進入緩衝組件。
緩衝規則判斷：判斷使用者請求是否符合緩衝規則中設定的規則條件，如果符合，使用者請求將會使用緩衝規則中設定的緩衝配置（緩衝規則的生效優先順序高於全域緩衝配置），具體請參見緩衝配置生效邏輯。
請求檔案類型判斷：判斷使用者請求需要訪問的檔案類型是否符合預設緩衝的副檔名中的檔案類型，如果符合，使用者請求將會使用全域配置中設定的緩衝配置。

預設緩衝的副檔名

預設情況下，使用者請求的資源的檔案尾碼是下面這些類型時，使用者請求會經過緩衝模組（即對應繞過緩衝功能的預設規則），至於資源在緩衝模組上的緩衝到期時間，還需要按該資源命中的緩衝規則。

說明

如果要緩衝的資源類型不在以下檔案類型中，可以參閱規則以建立緩衝所需資源的規則策略。

檔案類型	副檔名說明
文檔檔案	`.DOC`, `.DOCX` - Microsoft Word 文檔 `.PPT`, `.PPTX` - Microsoft PowerPoint 簡報 `.PDF` - 攜帶型文檔格式 `.CSV` - 逗點分隔值檔案
影像檔	`.BMP` - 位元影像映像 `.GIF` - 圖形交換格式 `.ICO` - 表徵圖影像檔 `.JPEG`, `.JPG` - JPEG 映像 `.PNG` - 可移植網狀圖形 `.SVG`, `.SVGZ` - 可縮放向量圖形 `.TIF`, `.TIFF` - 標籤影像檔格式 `.WEBP` - 一種現代的映像格式，提供有損和無損壓縮
音頻檔案	`.MP3` - MPEG 音頻層 III `.FLAC` - 無損音頻壓縮 `.MID`, `.MIDI` - 樂器數位介面音樂
視頻檔案	`.AVI` - Audio Video Interleave `.MP4` - MPEG-4 視頻 `.MKV` - Matroska 視頻容器 `.WEBM` - 一種開放的媒體容器格式，可使用視訊和音頻
壓縮檔	`.7Z` - 7-Zip 壓縮檔 `.GZ` - GNU 壓縮檔 `.RAR` - RAR 壓縮檔 `.TAR` - 帶封存檔案 `.ZIP` - ZIP 壓縮檔 `.ZST` - Zstandard 壓縮檔
執行檔案（可執行程式/安裝包）	`.APK` - Android 包檔案 `.BIN` - 二進位檔案，常用於韌體更新等 `.CLASS` - Java 位元組碼檔案 `.DMG` - macOS 磁碟映像檔案 `.EXE` - Windows 可執行檔 `.JAR` - Java 應用程式封存檔案 `.MSI` - Windows 安裝程式 `.ISO` - 光碟片鏡像檔案
字型檔	`.EOT` - Embedded OpenType 字型檔案 `.OTF` - OpenType 字型檔案 `.TTF` - TrueType 字型檔案 `.WOFF`, `.WOFF2` - Web Open Font Format 字型檔
指令碼與代碼檔案	`.CSS` - 層疊樣式表 `.EJS` - 嵌入式 JavaScript 模板引擎檔案 `.JS` - JavaScript 檔案
設計與向量圖形檔案	`.EPS` - Encapsulated PostScript 檔案 `.PICT` - Apple PICT 影像檔 `.PS` - PostScript 檔案 `.SWF` - Shockwave Flash 檔案

緩衝配置生效邏輯

對於來源站點響應的 200、203、206、300、301、308、410 狀態代碼，緩衝到期時間按以下規則生效。

節點緩衝到期時間功能有四種模式，這四種模式分別具備不同的緩衝生效邏輯：

優先遵循來源站點緩衝策略（如果存在），否則使用預設緩衝策略：如果來源站點響應資訊中帶有用於設定緩衝策略的響應標題欄位，包括：Cache-Control、Expires、Last-Modified、ETag，則遵循來源站點的緩衝策略；如果來源站點響應資訊中不帶有Cache-Control、Expires、Last-Modified、ETag其中任一欄位，則遵循ESA的預設緩衝策略。
緩衝策略詳情
來源站點響應中包含Cache-Control，遵循來源站點的緩衝策略

來源站點響應的Cache-Control緩衝策略存在以下兩種情況：
1. Cache-Control的值為以下任意一種時，表示不緩衝。
  - no-cache
  - no-store
  - max-age=0
2. 來源站點響應中使用Cache-Control設定緩衝到期時間，取值為max-age或s-maxage，並且max-age或s-maxage的值大於 0，例如：Cache-Control:max-age=3600。如果同時存在max-age和s-maxage，則以s-maxage的值為準。
來源站點響應中不包含Cache-Control，使用ESA的預設緩衝策略

來源站點響應資訊中不包含緩衝策略Cache-Control的情況下，使用ESA的預設緩衝策略，優先順序由高至低為：Expires>Last-Modified>ETag。
1. 如果來源站點響應中攜帶了Expires，則使用Expires設定到期時間，例如：Expires:Tue, 25 Nov 2031 17:25:43 GMT。
2. 如果來源站點響應中未攜帶Expires，但是攜帶了Last-Modified，則使用以下規則來計算緩衝時間：
  - 使用公式（目前時間-Last-Modified）* 0.1，計算結果在 10 秒~3600 秒之間的，取計算結果時間；小於 10 秒的，按照 10 秒處理；大於 3600 秒的，按照 3600 秒處理。
3. 如果來源站點響應中只攜帶了ETag，則緩衝 10 秒。
4. 來源站點返回的資料中Cache-Control、Expires、ETag和Last-Modified等這些緩衝相關的回應標頭都沒有攜帶，則不緩衝。
優先遵循來源站點緩衝策略（如果存在），否則不緩衝：如果來源站點響應資訊中帶有用於設定緩衝策略的響應標題欄位：Cache-Control，則遵循來源站點的緩衝策略；如果來源站點響應資訊中不帶有Cache-Control欄位，則不緩衝。
緩衝策略詳情
來源站點緩衝策略判斷

只判斷來源站點響應資訊中是否包含緩衝策略Cache-Control，如果不包含就不緩衝；如果包含，來源站點響應緩衝策略Cache-Control包含以下兩種情況：
1. Cache-Control:no-cache（或者no-store，或者max-age=0）時，不緩衝。
2. 來源站點響應中使用Cache-Control設定到期時間，取值為max-age或s-maxage，並且max-age或s-maxage的值大於 0，例如：Cache-Control:max-age=3600。如果同時存在max-age和s-maxage，則以s-maxage的值為準。
不緩衝：ESA節點收到的所有來源站點響應資源均不緩衝。
忽略來源站點緩衝策略，使用自訂緩衝TTL：忽略來源站點響應資訊中的緩衝策略的響應標題欄位，包括：Cache-Control、Expires、Last-Modified、ETag，使用ESA上設定的緩衝到期時間。

異常狀態代碼緩衝規則

對於 204、305、404、405、414、424、429、500、501、502、503 和 504 狀態代碼，緩衝規則如下：
1. 如果來源站點返回set-cookie回應標頭，ESA不緩衝。
2. 如果來源站點沒有返回set-cookie回應標頭，則判斷ESA控制台是否配置狀態代碼到期時間：
  1. 若已配置，則遵循ESA控制台配置的狀態代碼到期時間來緩衝。若配置了多條規則，規則序號越小則優先順序越高。
  2. 若未配置，則按照來源站點設定的Pragma、Cache-Control或者Expires回應標頭來緩衝。
3. 如果來源站點也沒有配置Pragma、Cache-Control或者Expires回應標頭，則預設緩衝 1 秒。

對於 302、307 和 403 狀態代碼，緩衝規則如下：
- 如果來源站點返回set-cookie回應標頭，ESA不緩衝。
- 如果來源站點沒有返回set-cookie回應標頭，則判斷ESA控制台是否配置狀態代碼到期時間：
  - 若已配置，則遵循ESA控制台配置的狀態代碼到期時間來緩衝。若配置了多條規則，規則序號越小則優先順序越高。
  - 若未配置，則按照來源站點設定的Pragma、Cache-Control或者Expires回應標頭來緩衝。
- 如果來源站點也沒有配置Pragma、Cache-Control或者Expires回應標頭，則不緩衝。
對於其他異常狀態代碼，如 400 狀態代碼，緩衝規則如下：
1. 如果來源站點返回set-cookie回應標頭，ESA不緩衝。
2. 如果來源站點沒有返回set-cookie回應標頭，則遵循ESA控制台配置的狀態代碼到期時間來緩衝。若配置了多條規則，規則序號越小則優先順序越高。
3. 其他情境不緩衝。
對於採用 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 的情況下，將會更新 Date 資訊。
- 格式為 GMT（格林尼治標準時間）時區的時間格式，例如：Sat, 19 Apr 2025 08:58:31 GMT。

X-Site-Cache-Status: 表示本次請求的資源在ESA節點上的緩衝狀態，不同狀態的說明詳見下表。

狀態	說明
HIT	在ESA節點的緩衝中找到了該資源。
MISS	在ESA節點的緩衝中找不到該資源，而是由來源站點伺服器提供該資源。
NONE/UNKNOWN	該資源不符合緩衝條件。這可能是由於以下原因造成的：一個邊緣函數產生了響應，但沒有發送任何子請求。在這種情況下，響應並非來自緩衝，因此緩衝狀態將為`none/unknown`。邊緣函數主請求發起了一個子請求（`fetch`）。在這種情況下，子請求將被記錄緩衝狀態，而主請求將被記錄`none/unknown`狀態（主請求沒有經過緩衝模組，因為邊緣函數模組位於緩衝模組之前）。用戶端請求命中了一條 WAF 自訂規則，並且請求被 WAF 攔截了。因為 WAF 模組位於緩衝模組之前，被 WAF 攔截的請求不會經過緩衝模組，所以緩衝狀態將記錄為`none/unknown`。用戶端請求命中了重新導向規則或設定了強制 HTTPS 的 HTTPS 規則，ESA節點響應重新導向資訊到另一個 URL。因為重新導向規則和 HTTPS 規則這兩個模組位於緩衝模組之前，所以緩衝狀態將記錄為`none/unknown`。
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-store`。
REVALIDATED	該資源由ESA的緩衝提供，但是已到期。ESA的回源請求中攜帶`If-Modified-Since`標題或`If-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緩衝配置中邊緣緩衝到期時間的模式設定為優先遵循來源站點緩衝策略（如果存在），否則不緩衝，並且來源站點響應為：Cache-Control: no-store。
將ESA緩衝配置中邊緣緩衝到期時間的模式設定為不緩衝。
將ESA緩衝配置中邊緣緩衝到期時間的模式設定為忽略來源站點緩衝策略，使用自訂緩衝TTL，並且緩衝到期時間設定為 0 秒。

緩衝回源校正策略說明

ESA節點上的快取檔案到期之後，緩衝回源校正機制會在下次用戶端請求該檔案時發揮作用。此時，ESA節點會向來源站點發起校正請求：如果源檔案未發生變化，來源站點將會響應304 not-modified，ESA節點將會繼續使用已快取檔案響應給用戶端，無需重新下載檔案，有效提升用戶端請求的響應速度，並減少來源站點的響應流量。

特殊策略配置：檔案快取 0 秒，ESA節點對每次請求都回源校正。
- 將ESA緩衝配置中邊緣緩衝到期時間的模式設定為優先遵循來源站點緩衝策略（如果存在），否則使用預設緩衝策略。並且來源站點響應滿足以下兩種情況：
  - Cache-Control: no-cache
  - Cache-Control: max-age=0
常規策略配置：來源站點響應緩衝校正相關的策略，ESA節點按實際策略執行。
- 將ESA緩衝配置中邊緣緩衝到期時間的模式設定為優先遵循來源站點緩衝策略（如果存在），否則使用預設緩衝策略。並且來源站點響應滿足以下某個緩衝校正策略：
  - must-revalidate
  - proxy-revalidate
  - stale-while-revalidate=seconds
  - stale-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 秒）內仍可提供最後一次成功的緩衝版本。