私有快取與共用快取的定義

快取保存下來的回應，本模組稱為副本。RFC 9111 把快取分成兩種，分界是一份副本會被幾個使用者重用：

A “shared cache” is a cache that stores responses for reuse by more than one user; shared caches are usually (but not always) deployed as a part of an intermediary. A “private cache”, in contrast, is dedicated to a single user; often, they are deployed as a component of a user agent.（RFC 9111 §1）

私有快取只替一個使用者保存副本，最常見的是瀏覽器的 HTTP 快取：使用者 A 的瀏覽器存下的副本，只會再拿來回應使用者 A 自己的請求。共用快取保存的副本會被拿去回應不同使用者的請求，CDN、放在 origin 前面的反向代理、企業或電信業者的轉送代理都屬於這一種。

這個分界看的是重用範圍，不看快取放在網路上的哪個位置，原文的「usually」「often」就是在交代這一點。一台放在 origin 同一個機房、由同一個團隊維運的 nginx 反向代理，只要它把同一份副本發給不同使用者，它就是共用快取，所有適用於共用快取的規則都套用在它身上。

區分兩者的理由在後果：同一份回應如果帶著某個使用者的個人資料，存進私有快取只會回到那個使用者手上，存進共用快取就會被發給別人。規範裡多數只針對共用快取的規則，都在防止這件事。

各種快取的經營者與 origin 能直接操作的範圍

一個回應從 origin 到使用者之間，可能依序經過反向代理、CDN、轉送代理，最後到瀏覽器；本模組把路徑上的每一個快取稱為一層。各層的經營者不同，origin 能對它們做的事也不同：

「origin 能直接操作的範圍」這一欄推出一個前提：瀏覽器快取與第三方轉送代理沒有任何管理介面可用，origin 想改變它們手上的副本，都要等它們再向 origin 送出請求。 轉送代理會在副本過期、回來驗證或重抓時送出請求，經過它的請求帶的快取指令它可以不理（12.7 瀏覽器端的快取行為：重新整理、強制重新整理與上一頁 的〈請求端快取指令對中介快取的效力〉），origin 不能指望它提早更新；瀏覽器另外還有使用者之後造訪同一個網站時的請求，origin 可以利用那些請求帶上清除指令（Clear-Site-Data），或由網頁程式以重抓模式覆寫副本、改用新網址繞開副本（12.7 瀏覽器端的快取行為：重新整理、強制重新整理與上一頁 的〈Fetch 規範的快取模式〉）。例如一個 API 回應誤設 max-age=86400 上線：企業轉送代理裡的副本，最壞的情況要等這一天過完；使用者瀏覽器裡的副本，可以讓前端改呼叫新的網址，或以 fetch(url, { cache: "reload" }) 重抓一次，兩者都要等使用者再打開這個網站才會發生。簽約的 CDN 同樣不由 origin 經營，但它另外提供清除介面，清得到的範圍限於簽約的那一家。

可以被保存的回應

規範用一份條件清單規定快取什麼時候不可以保存回應（RFC 9111 §3）。規範用大寫的 MUST、SHOULD、MAY 標示要求的強度（RFC 9111 §1.1 引用 RFC 2119 與 RFC 8174 的定義）：MUST 是必須，SHOULD 是除非有充分理由否則應該，MAY 是允許；小寫的同一個字是一般用語。主要條件整理如下，全部滿足才可以保存：

• 請求方法是快取理解、而且允許快取的方法（多數實作只支援 GET 與 HEAD，見 12.4 快取鍵與副本共用：Vary、Cookie 與 Authorization）。
• 回應的狀態碼是最終回應（不是 1xx 這類中間回應）。
• 狀態碼是 206 或 304、或回應帶 must-understand 指令時，快取要理解這個狀態碼。
• 回應沒有 no-store。
• 共用快取另外兩條：回應沒有 private；請求沒有 Authorization，或回應用指令明確允許共用（見 12.4 快取鍵與副本共用：Vary、Cookie 與 Authorization 的〈帶 Authorization 的請求在共用快取的重用規則〉）。
• 回應至少帶有下列一項：public、private（僅限私有快取）、Expires、max-age、s-maxage（僅限共用快取）、允許快取的擴充指令，或狀態碼屬於「可啟發式快取」的種類。

清單的最後一條決定了沒有任何快取指令的回應能不能被保存：狀態碼在可啟發式快取的清單裡（例如 200、301），就可以保存，保存之後能直接使用多久由快取自己估算；不在清單裡（例如 302、307），規範不允許保存。這份清單與估算方式在 12.2 新鮮度期限的計算：max-age、s-maxage、Expires 與啟發式期限 的〈沒有明確期限時的啟發式期限〉。

這份清單是規範的要求，而實作的預設可能和它有三種落差，本模組各篇用同一組名稱標出：

• 比規範保守：規範允許保存或重用的回應，實作不保存或不重用。對 origin 的代價是失去快取的效益，這些請求的負載全部回到 origin。例子是 Varnish 預設不保存 no-cache 的回應（12.3 過期副本的驗證：條件請求、304 回應、no-cache 與 no-store 的〈共用快取實作的驗證預設〉）。
• 比規範寬鬆：規範預設不允許、但留了出口讓經營者用設定開啟的行為，實作預設就開著。RFC 9111 §4.2.4 預設不給出過期副本，同時允許依「out-of-band contract」的設定給出，Varnish 預設的寬限時間就落在這個出口上（12.6 過期副本的延用：stale-while-revalidate 與 stale-if-error）。代價落在使用者這一端：拿到的舊內容比標頭宣告的期限更舊。
• 違反規範：規範沒有留出口的禁止，實作照樣做。代價最直接，可能把一個使用者的回應發給別人。例子是預設設定的 nginx 共用帶 Authorization 請求的回應（12.4 快取鍵與副本共用：Vary、Cookie 與 Authorization 的〈帶 Authorization 的請求在共用快取的重用規則〉）；回應明寫 must-revalidate 而 Varnish 仍在寬限時間內給出它的過期副本，也屬於這一類，因為明確的指令禁止沒有設定上的出口（12.6 過期副本的延用：stale-while-revalidate 與 stale-if-error）。

三種落差都只能從實作的文件、原始碼或實測得知。規範隱含的保護（例如帶 Authorization 的回應不被共用）不能依賴，要由回應明寫的標頭（private、no-store）承擔；延用過期副本這一類，連明寫的 must-revalidate 都可能被實作的寬限時間略過，要回到快取自己的設定處理。

只對共用快取或只對私有快取有效的指令

Cache-Control 標頭裡有幾個指令只對共用快取或只對私有快取有效，表中 no-store 列作對照，它對兩種快取都有效：

private 只規定保存位置：共用快取不可以存，瀏覽器可以存。規範在同一節明寫它不是保密機制：

This usage of the word “private” only controls where the response can be stored; it cannot ensure the privacy of the message content.（RFC 9111 §5.2.2.7）

public 在多數情形下是多餘的：回應本來就可以被快取時，加上它不改變任何行為（RFC 9111 §5.2.2.9）。它有作用的情形是請求帶了 Authorization 標頭，這種情形在 12.4 快取鍵與副本共用：Vary、Cookie 與 Authorization 說明。

本模組的實測環境是 docker 上的一支 Python origin，前面分別接 Varnish 7.7.3 與 nginx 1.27.5，瀏覽器是 Chrome 154。Varnish 只另外加了測試 purge 與 ban 用的規則，一般路徑的請求都走內建設定；nginx 在一般路徑上只加了開啟快取所需的 proxy_cache_path 與 proxy_cache，另有轉送與記錄用的設定，不影響快取判斷。各篇說的「預設設定」都指這個狀態，個別調過參數的測試會在該處寫明。用實測對照規範：回應帶 Cache-Control: private, max-age=60 時，Varnish 7.7 與 nginx 1.27 的 proxy_cache 兩者都沒有保存，每個請求都送到 origin，與規範一致。回應帶 max-age=5, s-maxage=30 時，兩者在第一次請求之後的第 18 秒（max-age 的 5 秒已過、s-maxage 的 30 秒未到）仍由快取直接回應，也就是採用了 s-maxage。

把指令指定給特定快取：CDN-Cache-Control

s-maxage 能區分「共用快取」與「私有快取」，但無法再細分到某一個共用快取。規範明寫這個限制：

It is not possible to target a directive to a specific cache.（RFC 9111 §5.2）

這個限制的代價是：origin 經常想讓自己簽約的 CDN 把副本當作新鮮久一點（因為 CDN 有清除介面，內容要改時可以主動清掉），同時讓瀏覽器與第三方轉送代理短一點（因為它們清不掉）。用 s-maxage 只能把 CDN 與轉送代理綁在一起設定。

RFC 9213 為這個需求定義了「指定目標的快取控制欄位」：欄位的語意和 Cache-Control 相同，但欄位名稱指明了適用對象。其中 CDN-Cache-Control 適用於代表 origin 運作的分散式快取網路，也就是 CDN。實作這個欄位的快取，在這個欄位有有效值時忽略回應裡的 Cache-Control 與 Expires，改用它（RFC 9213 §2.2）。規範裡的例子：

1Cache-Control: max-age=60, s-maxage=120
2CDN-Cache-Control: max-age=600

這組標頭讓 CDN 把副本視為新鮮 600 秒，其他共用快取 120 秒，瀏覽器 60 秒。不支援 CDN-Cache-Control 的快取把它當成一個不認得的標頭欄位：RFC 9110 §5.1 要求代理照樣轉送不認得的欄位，其他接收者應該（SHOULD）忽略這個欄位；實作了 RFC 9213、但 CDN-Cache-Control 不在自己目標清單裡的快取，依 RFC 9213 §2.2 不可以因為這個欄位改變行為。所以加上這個欄位，不支援的快取照 Cache-Control 運作。反過來，實作這個欄位的 CDN 會整個忽略 Cache-Control，包括其中的 private（RFC 9213 §2.2；§5 也提醒這種組合可能讓帶敏感資訊的回應被重用）；Varnish 的內建設定在回應帶 Surrogate-Control 時，不再檢查 Cache-Control 的 no-cache、no-store 與 private，只看 Surrogate-Control 裡有沒有 no-store。個人化的回應要在 CDN-Cache-Control 裡寫 private 或 no-store、在 Surrogate-Control 裡寫 no-store，或不送這些欄位。

在 RFC 9213 之前，部分 CDN 用 Surrogate-Control 這類自訂欄位把指令指定給 CDN。它出自 2001 年的一份 W3C Note（Edge Architecture Specification 1.0），不是標準，RFC 9213 對這類先行做法的評語是「their interoperability is low」。手上的 CDN 支援 CDN-Cache-Control、Surrogate-Control 還是自己的欄位，以該 CDN 的文件為準。

沒有快取標頭的回應的預設處理

規範的預設立場是重用保存的回應：

it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it.（RFC 9111 §2）

所以沒有寫 Cache-Control 的回應仍可能被快取：依〈可以被保存的回應〉的最後一條，狀態碼在可啟發式快取的清單裡就能保存，直接使用多久由各快取自行估算，估算方式在 12.2 新鮮度期限的計算：max-age、s-maxage、Expires 與啟發式期限。要確定某個回應不被任何快取保存，要明寫 no-store；要讓它可以保存但每次使用前都先問 origin，寫 no-cache，兩者的差別在 12.3 過期副本的驗證：條件請求、304 回應、no-cache 與 no-store。

規範用兩個量描述一份副本：新鮮度期限（freshness lifetime，這份副本從 origin 產生起可以被直接使用多久）與目前年齡（current age，這份副本從 origin 產生或最近一次驗證起過了多久）。CDN 的設定介面與 Varnish 的參數把新鮮度期限稱為 TTL（time to live）。目前年齡小於新鮮度期限的那段時間稱為新鮮期間，兩者的差就是副本剩下的新鮮時間。判斷式只有一行：

1response_is_fresh = (freshness_lifetime > current_age)

（RFC 9111 §4.2）新鮮的副本可以不詢問 origin 直接拿來回應請求；過期的副本要先驗證，或在 12.6 過期副本的延用：stale-while-revalidate 與 stale-if-error 說明的條件下延用。

新鮮度期限的取用順序

快取從回應標頭裡依序找第一個存在的值當新鮮度期限（RFC 9111 §4.2.1）：

1. 快取是共用快取，而且回應有 s-maxage：用 s-maxage 的值。
2. 回應有 max-age：用 max-age 的值。
3. 回應有 Expires：用 Expires 減去 Date 的值；回應沒有 Date 時，以收到回應的時間代替。
4. 以上都沒有：沒有明確期限，快取可以改用啟發式期限（見〈沒有明確期限時的啟發式期限〉）。

用 Expires 減 Date 而不是減快取自己的時鐘，是為了避開 origin 與快取之間的時鐘偏差：兩個時間都由 origin 的時鐘產生，相減的結果不受快取那台機器的時間影響。

幾條處理衝突與異常值的規則：

• 同時有 max-age 與 Expires 時，忽略 Expires（RFC 9111 §5.3）。
• Expires 的值無法解析，特別是常見的 Expires: 0，當成過去的時間處理，也就是回應一送到就已經過期（RFC 9111 §5.3）。
• 指令互相衝突（例如同時有 max-age 與 no-cache）時，規範用小寫的 should（一般用語，不是 RFC 以大寫 SHOULD 標示的要求）建議採用限制最嚴的那個（RFC 9111 §4.2.1）。

Age 標頭與副本的目前年齡

Age 標頭記錄的是：

the cache’s estimate of the number of seconds since the origin server generated or validated the response.（RFC 9111 §4.2.3）

快取不經驗證、直接用保存的副本回應請求時，必須在回應裡帶上 Age，值是這份副本目前的年齡（RFC 9111 §4）。下游的快取收到帶 Age 的回應，會把這個值算進自己那份副本的年齡。規範給的保守算法還計入網路傳輸的延遲，結構是：

1corrected_initial_age = max(收到時 Date 與自己時鐘的差, 上游給的 Age + 這次請求的往返時間)
2current_age = corrected_initial_age + 副本在自己這裡放了多久

這個機制讓年齡沿著快取鏈累加，影響的是下游拿到的剩餘新鮮時間。一個回應帶 Cache-Control: max-age=600，在 CDN 上放了 500 秒之後被某個瀏覽器請求，CDN 回給瀏覽器的回應帶 Age: 500，瀏覽器算出的剩餘新鮮時間就只有 100 秒，不是 600 秒。origin 寫的 max-age 是從 origin 產生回應起算的總期限，不是每一個快取各自重新計時。

送不送 Age，實作之間就有差異。實測時 Varnish 7.7 每次由快取回應都送出遞增的 Age；nginx 1.27 的 proxy_cache 不送 Age，而且把 Date 換成送出當下的時間。下游原本可以用 Date 與自己時鐘的差估出副本的年齡；Age 沒送、Date 又被換成送出當下的時間，下游（例如接在 nginx 外面的 CDN）就估不出來，因此會把副本多用一段時間，長度等於副本在 nginx 裡已經放了的時間。規範也提醒，回應裡沒有 Age 不代表它剛從 origin 拿來（RFC 9111 §5.1）。

沒有明確期限時的啟發式期限

回應沒有 s-maxage、max-age、Expires 時，規範允許快取自己估一個期限，稱為啟發式期限（heuristic freshness）。允許的範圍有兩個限制（RFC 9111 §4.2.2）：

• 只能用在狀態碼屬於可啟發式快取的回應上，或回應用 public 這類指令明確標成可快取。
• 回應有明確期限時，不可以使用啟發式期限。

可啟發式快取的狀態碼由 RFC 9110 列舉：

200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501（RFC 9110 §15.1）

302 與 307 不在這份可啟發式快取的清單裡，規範不允許快取保存沒有快取標頭的 302、307（12.1 HTTP 回應的保存位置：私有快取與共用快取 的〈可以被保存的回應〉）；實測的 Varnish 7.7 與 nginx 1.27 都照做，但部分 CDN 的文件記載會替沒有快取標頭的轉址套用自己的預設保存時間，以各家文件為準。301 與 308 在清單裡，沒有快取標頭時可以被保存，能直接使用多久由快取自己估算。

規範沒有規定估算的演算法，只建議一個上限的參考做法：以回應的 Last-Modified 為起點，期限不超過「從那個時間點到現在」這段間隔的某個比例。

caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.（RFC 9111 §4.2.2）

措辭是「encouraged」與「might」，10% 是例子，不是規定。一個在一年前修改過的檔案，照 10% 估算的新鮮度期限約 36 天；一個剛修改過的檔案，期限就很短。這個做法的假設是：很久沒改的內容，短期內也不太會改。

各實作的啟發式期限

因為規範沒有規定演算法，各實作的做法差很多。以下是 2026-10-02 讀原始碼與實測的結果，版本會變，套用到自己的環境前要查當下的文件或原始碼：

上面這張各實作的啟發式期限表，解釋了沒有快取標頭的 301 為什麼在各快取上的結果不同。這樣的 301 在 Chromium 上永不過期，副本只要還在快取裡，就不會再向 origin 確認：實測時先讓 Chrome 跟著 /r301 轉到 /target-a，再把 origin 的轉址目的地改成 /target-b，Chrome 再次前往 /r301 時沒有送出請求，直接去了 /target-a。Chrome 不再送出請求，origin 的存取紀錄裡也就看不到這些使用者，這類問題只會從使用者回報裡出現。同一個回應在 Varnish 上只在預設存活時間內直接使用，在 nginx 上完全不保存。同一組標頭在三個快取上得到三種結果，原因是這個回應把新鮮度期限交給了各實作自己估。

所以內容可能改變的回應，要明寫新鮮度期限：要被保存就寫 max-age（以及需要時的 s-maxage），不要被保存就寫 no-store。不寫等於把期限交給每一個經過的快取各自決定。

新鮮度期限與實際保存時間

新鮮度期限規定的是副本最多可以被直接使用多久，不保證快取會保存那麼久。規範把快取定位為選用功能：

Although caching is an entirely OPTIONAL feature of HTTP（RFC 9111 §2）

規範要求的是哪些回應不能存、不能重用，不要求快取把副本存到期滿。快取空間滿了、副本太少被用到、快取重啟，都會讓副本提早消失。所以 max-age 不能拿來當「這段時間內 origin 一定不會收到請求」的保證：容量規劃時 origin 要能承受副本提早消失、快取命中率下降時多出來的回源流量：容量怎麼估見 9.6 容量規劃模型；命中率掉下來時擋住回源尖峰的手段見 Origin Protection 卡。

新鮮度期限也只約束快取，不約束瀏覽器怎麼顯示畫面：

freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload a resource.（RFC 9111 §4.2）

使用者按上一頁看到的舊畫面，屬於瀏覽器的歷史機制，不受新鮮度期限約束，見 12.7 瀏覽器端的快取行為：重新整理、強制重新整理與上一頁。

副本過期之後仍可以繼續使用，條件是先向 origin 確認：快取帶著副本的版本識別去問 origin，如果 origin 端的內容沒變，origin 只回一個沒有內容的 304，快取更新副本的標頭後繼續使用原本的內容。規範把這個過程稱為驗證（validating 或 revalidating，RFC 9111 §4.3）。驗證省下的是傳輸內容的頻寬與 origin 產生內容的成本，請求本身仍然要送到 origin。

驗證子：ETag 與 Last-Modified

拿來比對版本的值稱為驗證子（validator），有兩種：

• ETag：origin 替內容的每個版本給的識別字串，例如 ETag: "v1"。內容改變時 ETag 跟著改變。
• Last-Modified：內容最後修改的時間，例如 Last-Modified: Mon, 01 Jan 2024 00:00:00 GMT。

ETag 分強弱兩種。強驗證子在內容的任何位元改變時都會改變；做不到這一點的（例如只在語意有變時才換值），origin 必須在值前面加 W/ 標成弱驗證子，例如 ETag: W/"v1"（RFC 9110 §8.8.1、§8.8.3）。驗證快取副本時用的是弱比較，所以強弱 ETag 都能用來驗證（RFC 9110 §13.1.2）；強弱的差別影響的是分段請求（Range）這類需要逐位元一致的場合。

Last-Modified 的時間解析度只到秒。同一秒內改了兩次的內容，Last-Modified 分不出來，這時要靠 ETag（RFC 9110 §8.8.3）。origin 通常兩種都送，規範也要求快取送出驗證請求時，副本有 ETag 就必須放進請求，有 Last-Modified 通常也要放（RFC 9111 §4.3.1）。

條件請求與 304 回應

快取驗證時送出的是條件請求：在請求裡附上副本的驗證子，問 origin「這個版本還是最新的嗎」。

1GET /res.js HTTP/1.1
2If-None-Match: "v1"
3If-Modified-Since: Mon, 01 Jan 2024 00:00:00 GMT

• If-None-Match 帶副本的 ETag。origin 端目前的 ETag 與它相符（弱比較），代表內容沒變。
• If-Modified-Since 帶副本的 Last-Modified。origin 端內容的修改時間早於或等於這個時間，代表內容沒變。
• 兩個都有時，origin 只看 If-None-Match，忽略 If-Modified-Since（RFC 9110 §13.1.3）。

內容沒變時，origin 對 GET 與 HEAD 回 304 Not Modified；內容變了就回 200 與新內容（RFC 9110 §13.1.2）。304 沒有內容，但必須帶上 200 回應會帶的 Cache-Control、Expires、ETag、Date、Vary 等標頭（RFC 9110 §15.4.5）。快取收到 304 之後，用這些標頭更新副本，副本因此重新變新鮮，新的期限照 304 帶來的 Cache-Control 計算（RFC 9111 §4.3.3、§4.3.4）。

所以 origin 修改一個網址回應的 Cache-Control 時，不必等快取把副本丟掉：下一次驗證時 origin 回的 304 帶著新的 Cache-Control，快取把副本標頭裡的指令換成新的，內容仍沿用原本那一份。

驗證時 origin 回 5xx，快取可以把錯誤轉給客戶端，也可以當成 origin 沒有回應（RFC 9111 §4.3.3）；當成沒有回應時，快取能在 12.6 過期副本的延用：stale-while-revalidate 與 stale-if-error 說明的條件下延用過期副本。

過期副本在驗證前的處理

規範的預設是過期副本不能直接給出：

A cache MUST NOT generate a stale response unless it is disconnected or doing so is explicitly permitted by the client or origin server（RFC 9111 §4.2.4）

也就是只有兩種情形可以給出過期副本：快取連不上 origin，或 origin 與客戶端用指令明確允許（例如 stale-while-revalidate）。有些指令連這兩種情形也一併禁止：no-cache 與 must-revalidate（語意見下方〈no-cache、no-store 與 must-revalidate 的語意〉），以及只對共用快取有效的 proxy-revalidate 與 s-maxage（12.1 HTTP 回應的保存位置：私有快取與共用快取）。

no-cache、no-store 與 must-revalidate 的語意

這三個回應指令在保存、新鮮期間內（副本目前年齡小於新鮮度期限的那段時間）的使用、過期後與連不上 origin 時各有規定：

規範原文：

• no-cache：「the response MUST NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response」（RFC 9111 §5.2.2.4）。no-cache 的回應可以保存，每次使用前都要驗證成功；名稱裡的「cache」指的是不經驗證就直接使用。
• no-store：「a cache MUST NOT store any part of either the immediate request or the response」（RFC 9111 §5.2.2.5）。它是唯一禁止所有快取保存的指令（private 只禁止共用快取保存）。規範同一節也寫明它不是可靠的隱私保證（「not a reliable or sufficient mechanism for ensuring privacy」）。另外，MDN 註明一個回應帶 no-store，不會刪掉快取裡同一個網址先前存下的副本。
• must-revalidate：新鮮期間內照常使用，過期之後一定要驗證；連不上 origin 時要回錯誤，不能拿過期副本頂替（RFC 9111 §5.2.2.2）。規範對它的用途說得很具體：「if and only if failure to validate a request could cause incorrect operation, such as a silently unexecuted financial transaction」。

選擇的依據是兩個問題。第一，內容能不能留在任何快取裡，包括使用者自己的裝置：不能就是 no-store；只是不能讓別人拿到，用 private 就夠了（12.4 快取鍵與副本共用：Vary、Cookie 與 Authorization），no-store 會連帶失去瀏覽器保存與條件請求省下的傳輸頻寬。第二，拿到舊內容的後果有多嚴重：每次都要確認是最新就是 no-cache；新鮮期間內可以接受、過期後即使連不上 origin 也不能拿舊內容頂替，就是 must-revalidate。

常見的遺留寫法是把幾個指令與舊標頭疊在一起，例如：

1Cache-Control: no-cache, no-store, must-revalidate
2Pragma: no-cache
3Expires: 0

這一組的實際效果由 no-store 決定：任何快取都不保存，no-cache 與 must-revalidate 只對保存下來的副本有意義，在這裡不起作用。Expires: 0 不是有效的日期，規範要求快取把無法解析的值、特別是 0，當成過去的時間處理（RFC 9111 §5.3）；這一組沒有 max-age 或 s-maxage，所以 Expires 不會被忽略，只認得 Expires 的舊快取會把這份回應當成一到就過期。Pragma 是 HTTP/1.0 時代給請求用的標頭，RFC 9111 §5.4 已將它廢止，並註明它在回應裡的意思從來沒有被定義，不能拿來代替回應的 Cache-Control: no-cache；規範沒有定義它在回應裡的作用，個別舊快取理不理會它無法預期。所以要的效果是「不保存」時，寫 Cache-Control: no-store 就夠了；要的是「可以保存、每次先確認」時，寫 no-cache，兩者不要疊在一起，否則 no-store 會讓 no-cache 想保留的條件請求省不到任何傳輸。

共用快取實作的驗證預設

快取向 origin 送條件請求這一步，在實測的情境（no-cache 的回應，以及 Varnish 寬限時間過後、nginx 過期後的請求）裡，Varnish 7.7 與 nginx 1.27 預設設定下都沒有發生：

• no-cache 回應：兩者預設都不保存，比規範保守。規範允許保存 no-cache 回應，Varnish 自己的期限計算也判定可以保存；讓 Varnish 不保存的是內建設定（builtin VCL，VCL 是 Varnish 的設定語言）裡一條在回應沒有 Surrogate-Control 時，把 no-cache|no-store|private 一律標成不可快取的規則。結果是 Varnish 與 nginx 把每個請求都以一般的 GET 轉給 origin，不是條件請求，origin 每次都回完整的 200。也就是說，回應寫 no-cache 時，這一層反向代理的命中率是零，所有請求的負載都由 origin 承擔；容量規劃要把這類回應當成前面沒有快取來估（Origin Protection 卡）。
• 有 max-age 的回應過期之後：Varnish 預設在一段寬限時間（參數 default_grace）內先給出過期副本，同時在背景向 origin 抓新的（見 12.6 過期副本的延用：stale-while-revalidate 與 stale-if-error）；依 Varnish 7.7 的原始碼，副本是帶 ETag 或 Last-Modified 的 200 回應、內容不是空的時，這次背景抓取會送條件請求；實測在 max-age=5 的副本過期後約 2 秒、仍在寬限時間內送出請求，客戶端拿到的是過期副本（回應的 Age 為 7、Varnish 回報命中），origin 端同時收到帶 If-None-Match 與 If-Modified-Since 的請求。寬限時間也過了之後，副本只在保留時間（參數 default_keep，預設 0）內留著供條件請求使用；預設設定下副本已經丟掉，實測在這個時間點的請求，Varnish 送給 origin 的是一般的 GET。nginx 預設不打開 proxy_cache_revalidate，過期後同步向 origin 送一般的 GET。把 Varnish 的 keep 設成大於 0（實測同時把 grace 設為 0、keep 設為 60 秒）、或打開 nginx 的 proxy_cache_revalidate 之後，Varnish 寬限時間過後的請求、以及 nginx 過期後的請求才改送帶 If-None-Match 與 If-Modified-Since 的條件請求，origin 回 304，快取繼續使用原本的內容。
• 客戶端自己送條件請求、而快取裡的副本還新鮮：兩者都直接回 304 給客戶端，不轉送到 origin。這是規範允許的行為。

這代表 origin 端設定好 ETag 與 no-cache，不保證共用快取會照規範去驗證。origin 有多台伺服器時，同一份內容在每一台算出的 ETag 也要相同，否則條件請求落到另一台就比對不上，只能回完整的 200。要讓驗證在共用快取上發生，要另外查手上那個快取的設定：Varnish 的 keep 與內建設定的覆寫方式，nginx 的 proxy_cache_revalidate，CDN 則查各家文件裡「revalidation」或「conditional request」相關的說明。

瀏覽器上的驗證什麼時候發生，跟使用者是重新整理、強制重新整理還是一般瀏覽有關，見 12.7 瀏覽器端的快取行為：重新整理、強制重新整理與上一頁。

快取鍵的組成

快取用來挑選副本的資訊稱為快取鍵（cache key）。規範定義的最小組成是請求方法加上目標網址：

The “cache key” is the information a cache uses to choose a response and is composed from, at a minimum, the request method and target URI（RFC 9111 §2）

規範也指出，許多常用的快取只保存 GET 的回應，所以只用網址當快取鍵。網址包含查詢字串，/products?id=1 與 /products?id=1&utm_source=mail 是兩個不同的快取鍵，各自保存一份副本。行銷追蹤參數這類不影響內容的查詢字串，會讓同一份內容被拆成很多份副本、降低命中率；CDN 通常提供忽略特定參數的設定，名稱與用法查各家文件。

方法方面，規範定義了 GET、HEAD、POST 三種方法的快取語意，而 PUT、DELETE 這類方法的回應不能快取（RFC 9110 §9.2.3、§9.3）。POST 的回應只有在帶明確期限、而且帶一個值和請求網址相同的 Content-Location 時才能保存（RFC 9110 §9.3.3）；規範也指出，絕大多數實作只支援 GET 與 HEAD（「the overwhelming majority of cache implementations only support GET and HEAD」，RFC 9110 §9.2.3）。

Vary 標頭加進快取鍵的請求標頭

同一個網址可能依請求標頭回不同內容：依 Accept-Encoding 回 gzip 或 brotli 壓縮的版本，依 Accept-Language 回不同語言。origin 用 Vary 標頭告訴快取：這個回應的內容跟哪些請求標頭有關，挑副本時這些標頭也要相符。

1Vary: Accept-Encoding

In other words, Vary expands the cache key required to match a new request to the stored cache entry.（RFC 9110 §12.5.5）

比對規則有幾個細節（RFC 9111 §4.1）：

• 快取比對新請求與副本當初那個請求在 Vary 列出的標頭值時，只允許去掉空白、合併同名標頭這類不改變語意的正規化，其餘要逐字相符。
• 請求沒有帶某個 Vary 列出的標頭時，只能和同樣沒有帶這個標頭的副本相符。
• Vary: * 永遠不相符，等於這個回應每次被重用前都要先向 origin 驗證。

Vary 列出的標頭值越分散，副本就越多。實測時同一個網址回 Vary: Accept-Encoding，nginx 1.27 依請求標頭的原始字串分開保存：gzip、br、gzip, deflate, br 與沒帶這個標頭各存一份。Varnish 7.7 在預設設定下會先把 Accept-Encoding 正規化、向 origin 一律要 gzip、再自己替客戶端解壓，所以四種請求共用同一份副本。這是實作的處理，不是規範的要求；所用的快取產品怎麼處理 Vary，要查它的文件。

帶 Authorization 的請求在共用快取的重用規則

請求帶 Authorization 標頭，代表回應可能只屬於那個使用者。規範對共用快取的規則是：除非回應用指令明確允許，否則不能把這種回應拿去回應其他請求。

A shared cache MUST NOT use a cached response to a request with an Authorization header field … to satisfy any subsequent request unless the response contains a Cache-Control field with a response directive … that allows it to be stored by a shared cache（RFC 9111 §3.5）

明確允許的指令是 public、s-maxage 與 must-revalidate。所以帶 Authorization 的請求，回應只寫 max-age=60 時，共用快取不能拿它回應別人；寫成 public, max-age=60 時可以，而且可以拿去回應任何請求，包括沒有帶 Authorization 的匿名請求：共用快取不替 origin 檢查權限。只對登入者開放、但每個登入者內容都相同的回應，寫 public 等於對匿名使用者公開，仍要寫 private，或靠 CDN 自己在邊緣驗證身分。Vary 不必列 Authorization，因為 RFC 9111 §3.5 這條規則已經禁止跨使用者重用（RFC 9110 §12.5.5）。

實測兩個共用快取在 RFC 9111 §3.5 這條規則上的表現完全相反：

• Varnish 7.7：只要請求帶 Authorization，內建設定就不查快取、直接轉給 origin，連回應寫了 public 或 s-maxage 也一樣。這比規範保守。
• nginx 1.27 的 proxy_cache（預設設定）：使用者甲帶 Authorization: Bearer t1 請求一個只寫 max-age=60 的路徑，回應被保存下來；接著使用者乙帶 Bearer t2、以及完全沒帶 Authorization 的請求，都拿到了使用者甲的那份回應。這違反 RFC 9111 §3.5 的規則。

nginx 的行為代表：origin 依靠「請求帶了 Authorization，快取就不會共用」這條規則來保護個人資料，在預設設定的 nginx 前面失效。開發與測試時多半只用一個帳號打同一個路徑，拿到的永遠是自己的資料，這種共用因此不容易在上線前被看到。需要登入才能拿到的回應，要在 origin 端明寫 private 或 no-store，不依賴快取對請求裡 Authorization 標頭的判斷。改標頭只約束之後產生的回應；已經存進共用快取的那份副本仍照它當初的標頭運作，到期之前會繼續發給別人，要讓它立刻停止，得在副本所在的快取上清除，CDN 與反向代理的清除方式見 12.5 已保存副本的更新方式：失效、purge、版本化網址與等待到期 的〈purge〉。

Cookie 與 Set-Cookie 在共用快取的處理

以 Cookie 識別使用者的服務，規範沒有對請求的 Cookie 標頭訂任何快取規則；它只是一個普通的請求標頭，除非 Vary: Cookie，否則不進快取鍵。回應的 Set-Cookie 也不會阻止保存：

Note that the Set-Cookie response header field [COOKIE] does not inhibit caching; a cacheable response with a Set-Cookie header field can be (and often is) used to satisfy subsequent requests to caches.（RFC 9111 §7.3）

規範允許共用快取把一個帶 Set-Cookie: session=使用者甲的值 的回應保存下來，再原封不動地回應給使用者乙，原文也寫明這種事常常發生（「can be (and often is)」）；這時使用者乙的瀏覽器就收到了使用者甲的 session。規範在同一段建議 origin 自己用 Cache-Control 控制這類回應。

實作多半對帶 Cookie 的請求與帶 Set-Cookie 的回應加了保護，但做法不同，實測結果：

• Varnish 7.7：請求帶 Cookie 時內建設定一律不查快取；回應帶 Set-Cookie 時內建設定不保存。
• nginx 1.27：回應帶 Set-Cookie 時預設不保存；請求的 Cookie 不影響快取鍵，回應有 Vary: Cookie 時才依 Cookie 值分開保存。

這些保護是實作的預設，可以被設定關掉，CDN 的預設也各不相同。

個人化回應的標頭選擇

回應的內容因使用者而不同時，標頭層面的做法如下（private 那一列成立的前提是回應沒有另外帶 CDN-Cache-Control 或 Surrogate-Control，或這些欄位裡也寫了 private、no-store（Varnish 的 Surrogate-Control 只認 no-store），見 12.1 HTTP 回應的保存位置：私有快取與共用快取 的〈把指令指定給特定快取：CDN-Cache-Control〉）：

標頭以外還有一種做法：頁面只有一小塊因使用者而不同（例如右上角的使用者名稱）時，把那一塊拆成另一個帶 private 的請求，頁面主體就能讓共用快取保存；前提是共用快取不會因為請求帶 Cookie 就跳過快取，Varnish 的內建設定會，要在 VCL 裡移除頁面主體請求的 Cookie。

MDN 的建議與表中 private 那一列一致：「you should specify Cache-Control: private instead of specifying a cookie for Vary.」個人化回應寫 private，是讓「這份回應能不能給別人」由 origin 決定，而不是交給共用快取的預設設定決定；〈帶 Authorization 的請求在共用快取的重用規則〉與〈Cookie 與 Set-Cookie 在共用快取的處理〉兩節的實測顯示，共用快取的預設在「會不會把回應發給別的使用者」這一點上，不同實作的結果相反。從外部確認某個網址有沒有把一個使用者的回應發給別人，做法在 12.8 快取設定的應用：轉址、需登入的 API 回應與個人化頁面 的〈檢查實際送出的快取標頭〉。

沒有列進快取鍵的輸入與快取投毒

快取比對請求時只看快取鍵裡的部分。請求裡其他會改變回應內容的部分（某些請求標頭、某些查詢參數），PortSwigger 的研究稱為 unkeyed input，也就是沒有列進快取鍵的輸入。origin 依一個沒有列進快取鍵的輸入產生了不同的回應，而快取把這份回應存下來，在它過期之前，所有快取鍵相同的請求都會拿到它，不論那些請求有沒有帶那個輸入。攻擊者刻意利用這一點，送出帶惡意值的請求、讓有害的回應被存下來發給其他使用者，稱為 web cache poisoning（快取投毒）；James Kettle 在 2018 年 8 月發表於 PortSwigger 的研究〈Practical Web Cache Poisoning〉整理了這類實際案例。

一個常見的形態是框架讀取 X-Forwarded-Host 這類代理轉送用的請求標頭，拿它組出頁面裡的絕對網址。請求帶上攻擊者的網域時，回應裡的網址就指向攻擊者的伺服器；這個標頭不在快取鍵裡，被存下來的頁面就發給之後的每個使用者。這和本篇〈Vary 標頭加進快取鍵的請求標頭〉一節講的是同一件事的兩種結果：origin 依某個請求標頭改變回應時，那個標頭列進 Vary、或由快取設定加進快取鍵，不同的值就各存一份；沒有列進去，它就是一個沒有列進快取鍵的輸入，一個值產生的回應會被發給帶其他值的請求。

PortSwigger 列的防範裡，和快取鍵直接相關的有下面幾條：

• 網站用不到的請求標頭，在快取或 origin 前停用，不讓框架讀到。這類標頭多半是代理或框架預設支援的，網站本身不需要。
• 為了命中率想把某個輸入排除在快取鍵外時，改成在快取前把請求改寫成正規化的值，讓同一個快取鍵只對應一種回應。
• 不接受帶 body 的 GET 請求，因為 GET 請求的 body 不在快取鍵裡，卻可能被 origin 讀取。

其他還有把快取限縮在純靜態的回應、修補看似無法利用的前端漏洞，見研究原文。

快取規則與 web cache deception

web cache deception 和快取投毒是兩種不同的問題，PortSwigger 的文件也明確區分：快取投毒操弄的是快取鍵，讓攻擊者的有害回應被存下來發給別人；web cache deception 利用的是快取規則，讓受害者帶個人資料的回應被存下來，再被攻擊者取走。

CDN 常依副檔名（.css、.js）或目錄（/static）設定快取規則，把符合的網址當成可以保存的靜態檔，而快取與 origin 解析網址路徑的方式可能不同。攻擊者引誘已登入的使用者點一個在快取看來是靜態檔、在 origin 看來是個人頁面的網址，origin 回出帶個人資料的頁面，快取依規則存下它，攻擊者再請求同一個網址就拿到那份副本。這種情形下快取鍵本身沒有問題，出問題的是快取規則覆寫了 origin 對這份回應能不能保存的判斷。PortSwigger 的防範建議：

• 動態回應明寫 Cache-Control: no-store, private。
• CDN 的快取規則不覆寫 origin 的 Cache-Control。
• 啟用 CDN 比對回應的 Content-Type 與網址副檔名是否一致的保護。
• 確認 origin 與快取解析網址路徑的方式一致。

瀏覽器快取的分區

瀏覽器上另有一層規範允許的做法：在快取鍵裡加入額外資訊。規範舉的例子是加入發出請求的網站：

user agent caches might include the referring site’s identity, thereby “double keying” the cache to avoid some privacy risks（RFC 9111 §2）

WHATWG Fetch 規範把 HTTP 快取依「頂層網站」分區（Fetch 的 network partition key）：同一個第三方資源，在網站甲與網站乙上被載入時，各存一份，目的是防止網站透過「某個資源是否已經在快取裡」推測使用者造訪過哪些網站。它對 origin 的影響是：跨網站共用的資源（例如公共 CDN 上的函式庫），不能預期因為使用者在別的網站載入過而命中快取。各瀏覽器分區的確切方式查各自的文件。

規範定義的失效

HTTP 規範裡唯一讓快取主動丟棄副本的機制，綁在不安全的請求方法（規範術語，指會改變伺服器狀態的方法，RFC 9110 §9.2.1）上。快取收到 POST、PUT、DELETE 這類方法的成功回應時，必須讓同一個網址的副本失效：

A cache MUST invalidate the target URI … when it receives a non-error status code in response to an unsafe request method（RFC 9111 §4.4）

「失效」是把副本移除，或標成下次使用前必須驗證；「成功回應」指 2xx 與 3xx。回應裡 Location 與 Content-Location 指到的網址也可以一起失效，但必須和請求的網址屬於同一個來源（scheme、主機名稱與連接埠都相同；RFC 9110 稱為 origin，與本模組其他地方指源站伺服器的 origin 是兩件事）。

這個機制的作用範圍很窄，規範自己寫明了：

a state-changing request would only invalidate responses in the caches it travels through.（RFC 9111 §4.4）

使用者甲送出一個 PUT 修改商品資料，被失效的只有使用者甲瀏覽器快取裡的副本，以及這個請求經過的那一個 CDN 節點上的副本。使用者乙的瀏覽器、其他 CDN 節點、使用者乙公司的轉送代理，都不會知道這次修改，各自繼續使用手上的副本直到過期。

purge

purge 指 origin 直接要求某個快取刪除指定的副本。HTTP 規範沒有定義 purge 這個操作：RFC 9110 與 RFC 9111 都沒有規定它，IANA 的 HTTP 方法登錄表也沒有 PURGE 方法（2026-10-02 查閱）。MDN 對此的描述是：

There is no way to delete responses on an intermediate server that have been stored with a long max-age.

purge 因此是各個快取產品自己的功能，能用到什麼程度取決於經營者：

• CDN：透過 CDN 的管理介面或 API 清除，可以依網址、依前綴或依標籤（tag，見 Cache Tag Purge 卡）清除。依標籤清除的操作模型見 5.9 邊緣分發與靜態資源 的〈Tag-based Purge 的操作模型〉。清除傳到所有節點需要時間，傳播時間與 API 呼叫的額度限制查各家文件。
• 自己經營的反向代理：Varnish 的內建設定把 PURGE 當成不認得的方法，直接轉給 origin、不動快取，要在設定檔（VCL）裡自己寫處理規則；實測時寫了 PURGE（刪除指定網址的副本）與 BAN（依條件一次標記一批副本失效）兩種規則之後，兩者都能讓下一個請求回到 origin。其他產品是否支援、怎麼開啟，查各自的文件。
• 瀏覽器與第三方轉送代理：沒有 purge 管道。

purge 刪掉的副本不會留下可以延用的舊版，所以清除之後，下一批請求在被清掉的每一個節點上都對不到副本，同時回到 origin。清的是一個熱門網址、或一整個前綴與標籤時，這一批回源請求會在同一個時間點湧進 origin，形成 Cache Stampede 描述的回源尖峰，清除的範圍越大、流量越高，尖峰越高。能壓低尖峰的做法都在清除的方式與回源的路徑上：把清除的範圍縮到真正改了的網址或標籤、避開流量高峰再清、讓 CDN 的 origin shield 或 request coalescing 把同時回源的請求合併成一次（5.9 邊緣分發與靜態資源 的〈Origin Protection 的設計責任〉）；部分 CDN 另外提供把副本標成過期而不刪除的清除方式，配合 stale-while-revalidate 讓回源分散到背景進行，支援情形以各家文件為準。保護 origin 承受回源量的手段，見 Origin Protection 卡。

版本化網址與 immutable

既然已存的副本難以刪除，另一種做法是不去改它：內容一改就換一個網址。這個做法也稱 cache busting，最常見的形式是由前端建置工具在打包時，把內容的雜湊值寫進檔名：

1/static/app.3f9a1c.js

內容改變時雜湊值跟著改變，網址也就跟著改變。新網址是一個新的快取鍵，所有快取都沒有它的副本，第一次請求一定會到 origin；舊網址的副本留在各處，重新載入過的頁面已經不再引用舊網址，這些副本等新鮮度期限過了、或快取空間不夠時自然被丟掉。已經開著的分頁仍可能延遲載入舊網址的程式片段，所以 origin 部署時舊檔要再保留一段時間，否則這些請求一落到沒有副本的快取，就會回到 origin 拿到 404。這個做法對每一層快取都有效，包括瀏覽器與轉送代理，因為它不需要任何快取配合刪除。

代價在引用端：引用這個資源的頁面必須跟著更新網址，而那個頁面本身就不能被長期快取，否則使用者拿到的舊頁面仍然引用舊網址。所以版本化網址要和引用它的頁面一起設定：頁面用短期限或 no-cache，頁面引用的靜態資源用版本化網址加長期限。

版本化網址的資源內容永遠不會改變，RFC 8246 為此定義了 immutable 指令：

1Cache-Control: max-age=31536000, immutable

31536000 秒是一年，是常見的取值，不是規範規定的上限。

它告訴客戶端，新鮮期間內 origin 不會更新這個資源，客戶端在新鮮期間內不應該（SHOULD NOT）送條件請求確認，使用者按一般的重新整理時也不送（RFC 8246 §2）。幾個限制：使用者強制重新整理時仍然會重新抓取；規範建議客戶端只在 HTTPS 這類經過驗證的連線上採用 immutable（RFC 8246 §3）；不認得它的瀏覽器依 RFC 9111 忽略這個指令，照一般的 max-age 運作，各瀏覽器的支援情形查各自的文件。重新整理時瀏覽器送出什麼請求，見 12.7 瀏覽器端的快取行為：重新整理、強制重新整理與上一頁。

Clear-Site-Data

Clear-Site-Data 是 W3C 的一份規格，讓回應可以要求瀏覽器清除這個網站存在本機的資料，其中 "cache" 這個值清的是 HTTP 快取：

1Clear-Site-Data: "cache"

它有幾個限制，使它無法當成一般的更新手段：

• 只作用在瀏覽器。MDN 寫明它「has no effect on intermediate caches」，CDN 與轉送代理裡的副本不受影響。
• 要瀏覽器對同一個主機送出請求、並在回應裡收到 Clear-Site-Data 才會生效。清除的範圍是主機名稱相同的整批快取條目，不限於收到標頭的那個網址。一個在 Chromium 上永不過期的 301（見 12.2 新鮮度期限的計算：max-age、s-maxage、Expires 與啟發式期限），使用者點它時不會連到 origin，這次點擊本身不會觸發清除；這份 301 副本清不清得掉，取決於使用者之後會不會造訪同一個主機的其他網址，這不是 origin 控制得了的。
• 只在 HTTPS 上有效。
• 規格狀態：W3C 正式發布的版本停在 2017 年的 Working Draft，Editor’s Draft 最後更新於 2023 年，兩者都不是 Recommendation。各瀏覽器支援哪些值，查各自的文件。

它適合的用途是使用者登出這類「從這個使用者的瀏覽器裡清掉資料」的時機，而不是改版時讓所有人拿到新內容。登出時通常不只清 "cache"，還會一起清 "cookies" 與 "storage"，各值在各瀏覽器的支援情形查 MDN 的 Clear-Site-Data 頁面。

各種更新手段的作用範圍

等待到期與改版全面生效的時間

表中「規範的失效」那一列是規範的要求：依 Varnish 7.7 的內建設定，POST、PUT、DELETE、PATCH 走 pass、直接轉給 origin；實測對一個副本已經存在 Varnish 7.7 與 nginx 1.27 proxy_cache 裡的網址送出 POST、origin 回 200 之後，同一網址的下一個 GET 在兩者上都仍由快取直接回應，兩者預設都不做這項失效。各家 CDN 是否實作，查各自的文件。

上表的「等待到期」與「下一次驗證」兩種手段對每一層都有效，但它們都要等：等副本過期，或等快取下一次回來驗證。所以一個網址的內容「改了之後最慢多久所有人都看得到新版」，有三個成分：

• 各層的新鮮度期限：回應寫了明確期限、而且每一層都正確傳遞 Age 時，這個成分的上限是各層裡最長的那個期限。回應沒有寫明確期限時，期限由各層自己估算，Chromium 對沒有快取標頭的 301 永不過期，這時就沒有上限（12.2 新鮮度期限的計算：max-age、s-maxage、Expires 與啟發式期限）。
• 過期副本的延用：stale-while-revalidate 與 stale-if-error 的窗口（過期之後仍允許給出過期副本的秒數），以及 Varnish 這類實作自帶的寬限時間（參數 default_grace），會在期限之後再延長一段（12.6 過期副本的延用：stale-while-revalidate 與 stale-if-error）。
• 年齡沒有傳下去的層：這是各層新鮮度期限那一項的前提（每一層都正確傳遞 Age）不成立的情形。上游不送 Age 又改寫 Date 時，下游把收到的副本當成剛產生的，從零開始算它的期限；副本在上游已經放了的時間，會再加在下游的期限上，上限改成沿路各層期限相加（實測的 nginx proxy_cache 就是這樣，見 12.2 新鮮度期限的計算：max-age、s-maxage、Expires 與啟發式期限 的〈Age 標頭與副本的目前年齡〉）。

這三個成分只計 HTTP 快取：已經開著的分頁、back/forward cache 與 Service Worker 不受這些期限約束；也假設沒有任何一層用自己的設定覆寫 origin 的期限。

所以選各層的期限（max-age、s-maxage、CDN-Cache-Control）的值，同時也是在選內容改版時最慢多久能全面生效，而這個時間要估得出來，前提是回應寫了明確期限。業務上能容忍多久的舊資料，在 Freshness Window 卡裡是一個分級的需求；max-age 是讓 HTTP 快取符合那個需求的手段。

Cache Invalidation 卡以應用層快取為主，討論 TTL、主動刪除、版本鍵、事件驅動等失效策略，和本篇的差別在快取由誰經營：應用層快取由服務自己讀寫，刪除一定做得到；本篇的快取多數不在 origin 手上。

規範對過期副本的預設

規範的預設是過期副本不能直接給出，只有兩種情形例外：快取連不上 origin，或 origin 與客戶端用指令明確允許（RFC 9111 §4.2.4）。no-cache、must-revalidate、proxy-revalidate 與共用快取上的 s-maxage 會連這兩種例外一起禁止，完整的規定見 12.3 過期副本的驗證：條件請求、304 回應、no-cache 與 no-store 的〈過期副本在驗證前的處理〉。回應同時寫了 s-maxage 與下面兩個指令時，兩個指令的情形不同。s-maxage 在共用快取上禁止給出未經驗證的過期副本（RFC 9111 §4.2.4、§5.2.2.10）；§4.2.4 另一段列出的擴充指令許可，只在沒有這條禁止時才適用，所以 s-maxage 與 stale-while-revalidate 並用時，規範的答案是共用快取不延用過期副本。stale-if-error 則不同：RFC 5861 §4 寫它可以「regardless of other freshness information」，與 RFC 9111 的禁止衝突，兩份規範之間沒有一致的答案。實作上，Varnish 7.7 的原始碼把 stale-while-revalidate 的值直接當成寬限時間，不看 s-maxage；CDN 怎麼處理這個組合，以各家文件與實測為準。

明確允許的指令裡最常用的是 stale-while-revalidate 與 stale-if-error，兩者由 RFC 5861 定義。這份 RFC 的類別是 Informational，不在標準軌上（「This document is not an Internet Standards Track specification」），所以它的支援程度比 RFC 9111 的核心指令更依賴各實作。RFC 5861 寫到給出過期副本時要附 Warning 標頭，而 Warning 已在 RFC 9111 §5.5 廢止，實作多半不再送出它，不能拿它判斷回應是不是過期副本。

stale-while-revalidate

1Cache-Control: max-age=600, stale-while-revalidate=600

這組標頭的意思是：新鮮度期限 600 秒；過期之後的 600 秒內，快取可以先把過期副本給出去，同時在背景向 origin 驗證或重新抓取，不讓請求等待（RFC 5861 §3）。過期之後允許給出過期副本的這段時間，本篇稱為 stale-while-revalidate 的窗口，長度就是指令後面的秒數。

indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds.（RFC 5861 §3）

stale-while-revalidate 的使用條件：

• 背景更新要靠請求觸發。只有在窗口內有請求進來，快取才會開始背景驗證；窗口內完全沒有請求，窗口結束後副本就照一般規則處理（RFC 5861 §3.1）。規範建議以請求觸發背景驗證，理由是避免放大攻擊（amplification attack，RFC 5861 §5）。
• 使用者可能拿到的最舊內容，年齡是 max-age 加上 stale-while-revalidate 的值。以 max-age=600, stale-while-revalidate=600 為例，使用者最長可能拿到 1200 秒前產生的內容（RFC 5861 §3.1 的例子）。
• 窗口過後還沒更新成功，就不應該（SHOULD NOT）再給出過期副本，除非符合規範允許的另一種例外，例如連不上 origin（RFC 5861 §3）。

站內 Stale-While-Revalidate 卡從使用者體驗與新鮮度的取捨描述同一個機制。

stale-if-error

1Cache-Control: max-age=600, stale-if-error=1200

這組標頭的意思是：過期之後，如果向 origin 驗證時遇到錯誤，快取可以在 1200 秒內改給過期副本，不把錯誤轉給客戶端（RFC 5861 §4）；這 1200 秒是 stale-if-error 的窗口。規範對「錯誤」的定義是會產生 500、502、503、504 的情形，包括連不上 origin。

when an error is encountered, a cached stale response MAY be used to satisfy the request, regardless of other freshness information.（RFC 5861 §4）

它也可以出現在請求裡，作用範圍只限那一個請求。它的用途是把 origin 的短暫故障擋在快取這一層，站內 Stale-If-Error 卡把它放在 origin 保護的脈絡下討論。

stale-while-revalidate 與 stale-if-error 的實作支援差異

這兩個指令的實作支援差異很大。實測 Varnish 7.7 與 nginx 1.27（預設設定，origin 回 max-age=5 加上其中一個指令；最後一列不加 stale 指令，改用 max-age=10）：

沒有任何 stale 指令時，Varnish 預設也會在過期後的一段時間內給出過期副本。規範的預設是不給出過期副本，所以這是比規範寬鬆的實作預設：沒寫任何 stale 指令的回應（例如商品價格）放在 Varnish 後面，過期後仍可能被給出一小段時間。

在瀏覽器上，WHATWG Fetch 規範的 default 快取模式（見 12.7 瀏覽器端的快取行為：重新整理、強制重新整理與上一頁 的〈Fetch 規範的快取模式〉）納入了 stale-while-revalidate：快取裡的副本已過期、但還在窗口內時，先回傳它，同時發出條件請求更新快取。stale-if-error 在瀏覽器的支援情形查各自的文件。CDN 對這兩個指令的支援與上限，同樣查各家文件。

stale-while-revalidate 與 stale-if-error 的選擇

兩個指令回答的是不同的問題：

• stale-while-revalidate 回答「內容過期一小段時間，使用者拿到舊版可以接受嗎」。可以接受的內容（文章列表、商品介紹）用它換取每次都不必等 origin 回應；不能接受的內容（庫存數字、權限相關的回應）不用它。
• stale-if-error 回答「origin 故障時，給舊內容比給錯誤頁好嗎」。對多數讀取型內容答案是肯定的；對寫入結果、付款狀態這類「舊答案會造成錯誤行為」的內容，答案是否定的，那類回應用 no-cache，每次使用前都向 origin 確認；must-revalidate 只適合新鮮期間內可以接受舊值、過期後不能延用的內容（兩者的差別見 12.3 過期副本的驗證：條件請求、304 回應、no-cache 與 no-store）。must-revalidate 禁止給出過期副本是規範層的要求；Varnish 7.7 的原始碼裡，寬限時間預設取 default_grace，不因 must-revalidate 關閉，所以預設設定下帶 must-revalidate 的副本仍會在寬限時間內被給出，要在 VCL 裡另外處理（no-cache 的回應 Varnish 預設不保存，沒有這個問題）。

兩個窗口都會延長內容改版後全面生效的時間：正常運作時延長的是 stale-while-revalidate 的窗口，origin 出錯期間延長的是 stale-if-error 的窗口，加在 12.5 已保存副本的更新方式：失效、purge、版本化網址與等待到期 的〈等待到期與改版全面生效的時間〉列出的其他成分之上。決定窗口長度時，要同時看 12.5 已保存副本的更新方式：失效、purge、版本化網址與等待到期 裡各種更新手段的作用範圍：瀏覽器、CDN、反向代理這幾層快取當中，哪一層的副本清得掉、哪一層只能等到期。

轉址回應的狀態碼與快取標頭

轉址回應有兩個獨立的設定：狀態碼決定轉址的語意，快取標頭決定各處快取把這個轉址當作新鮮多久。

狀態碼的語意由 RFC 9110 定義：

「永久」與「暫時」的差別在於轉址的對象會不會再變：RFC 9110 對永久轉址的說明是，能編輯連結的客戶端應該把指向原網址的引用改成新網址（RFC 9110 §15.4.2）。快取標頭則決定各處快取直接使用這個轉址多久；回應沒有快取標頭時，301 與 308 落入 12.2 新鮮度期限的計算：max-age、s-maxage、Expires 與啟發式期限 的啟發式期限，在 Chromium 上永不過期。實測時 Chrome 保存了一個沒有快取標頭的 301，之後 origin 改了目的地，Chrome 仍然直接去舊的目的地，沒有向 origin 送出請求；同一個 301 加上 Cache-Control: max-age=5 之後，過了 5 秒 Chrome 就回到 origin 取得新的目的地。

轉址回應的快取標頭由兩件事決定：共用快取可不可以保存（加不加 private），以及轉址設錯或要改時，願意等多久讓已經存下它的瀏覽器改過來（max-age 的長度）。轉址常見的三種情形如下，前兩種依目的地會不會變區分：

• 目的地確定不會再變（例如 HTTP 轉 HTTPS、網域搬遷後的舊網址；網域送了 HSTS 時，瀏覽器會在本機直接改用 HTTPS、不送出請求，之後要撤回 HTTPS 受的是 HSTS 的期限約束，HSTS 不在本模組範圍）：301 或 308，並明寫一個有限的 max-age。期限的長度以「這條轉址設錯時，願意花多久等它在所有瀏覽器上過期」來定：origin 沒有辦法讓所有使用者瀏覽器裡的副本一起失效：12.5 已保存副本的更新方式：失效、purge、版本化網址與等待到期 的〈各種更新手段的作用範圍〉裡，作用範圍涵蓋全部使用者瀏覽器的手段只有版本化網址與等待到期，而轉址的網址就是使用者手上的連結、換不掉，剩下的只有等待到期。不寫期限等於把這個時間交給各瀏覽器的啟發式規則。
• 目的地可能會改（例如可修改目的地的短網址、活動連結）：用 302 或 307 並明寫快取標頭（例如 Cache-Control: private, max-age=<秒數> 或 no-store），或用 301 並附上 Cache-Control: private, max-age=<秒數>。302 與 307 依規範不會被啟發式保存，但部分 CDN 的預設會替沒有快取標頭的轉址套用保存時間（12.2 新鮮度期限的計算：max-age、s-maxage、Expires 與啟發式期限），所以不論哪個狀態碼都明寫標頭。private 讓 CDN 與轉送代理不保存，<秒數> 填的是 origin 改了目的地之後，最慢多久要讓已經存下這個轉址的瀏覽器改去新的目的地。2026-10-02 對 bit.ly 與 t.co 的短網址各送一次請求，兩者的回應都是 301 加上 private 與很短的 max-age。
• 要統計每一次點擊：同樣用 302、307，或 301 加 private 與短 max-age；max-age 的長度同時決定同一個瀏覽器多久內的重複點擊不會送到 origin、也就不會被計入點擊數。

已經發出、沒有快取標頭的 301，在 Chromium 上永不過期，事後在 origin 補上 max-age 傳不到已經存下它的 Chromium 瀏覽器：它們不會再向 origin 送出這個網址的請求。剩下的處置都繞過這個副本：讓舊的目的地網址本身再轉址到新的目的地（前提是舊目的地還在自己手上），或在使用者之後造訪同一個主機的其他網址時，用 Clear-Site-Data 清掉，代價是這個主機在那個瀏覽器裡的快取條目會全部清掉（12.5 已保存副本的更新方式：失效、purge、版本化網址與等待到期 的〈Clear-Site-Data〉）。

短網址服務的轉址也照這組規則選標頭；短網址特有的取捨（撤回延遲、點擊計數、濫用處理，以及短網址服務保留 301 的理由）見 0.24 短網址服務的實作。

需登入的 API 回應的快取標頭

需要登入才能取得的 API 回應，內容只屬於發出請求的使用者。規範對帶 Authorization 的請求有保護規則：共用快取不能把回應拿去回應別人，除非回應明確允許（RFC 9111 §3.5）。這條規則在 12.4 快取鍵與副本共用：Vary、Cookie 與 Authorization 的實測裡，被預設設定的 nginx 1.27 proxy_cache 違反了：使用者甲的回應被發給了使用者乙與沒有登入的請求。而以 Cookie 識別使用者的服務，規範本來就沒有對應的保護規則。

所以需登入的 API 回應，由 origin 明寫快取標頭，不依賴快取對請求的判斷：

1Cache-Control: private, no-cache
2ETag: "<驗證子>"

• private：共用快取不保存，使用者自己的瀏覽器可以保存。前提是回應沒有另外帶 CDN-Cache-Control 或 Surrogate-Control，或這些欄位裡也寫了 private、no-store（Varnish 的 Surrogate-Control 只認 no-store）；實作那些欄位的共用快取會忽略 Cache-Control 裡的 private（12.1 HTTP 回應的保存位置：私有快取與共用快取 的〈把指令指定給特定快取：CDN-Cache-Control〉）。
• no-cache：瀏覽器每次使用前都送條件請求確認；內容沒變時 origin 回 304，省下傳輸內容的成本（12.3 過期副本的驗證：條件請求、304 回應、no-cache 與 no-store）。
• ETag：給條件請求比對用的驗證子，<驗證子> 換成這份內容的版本識別字串，例如內容的雜湊值或資料的更新版本號。

內容不能留在任何快取裡、包括使用者自己的裝置（共用電腦上的醫療或金融資料），改用 Cache-Control: no-store，代價是每次都要完整重抓。

個人化頁面的快取標頭

個人化的 HTML 頁面（帶使用者名稱的首頁、購物車頁面）和需登入的 API 回應用同一組標頭：private 加 no-cache 加 ETag。兩個額外的風險：

• 回應帶 Set-Cookie：規範不禁止保存帶 Set-Cookie 的回應（RFC 9111 §7.3）。一個沒有 private 的頁面同時設定了 session Cookie，規範允許共用快取把它連同 Cookie 一起發給下一個使用者。private 同時擋住了這個風險。
• 上一頁還原：瀏覽器的 back/forward cache 不受 Cache-Control 約束，登出之後按上一頁仍可能看到登出前的畫面（12.7 瀏覽器端的快取行為：重新整理、強制重新整理與上一頁）。這要由網頁程式在 pageshow 事件裡檢查 event.persisted（為 true 代表頁面是從 back/forward cache 還原的），再重新確認登入狀態，快取標頭處理不了。

靜態資源與引用它的頁面的快取標頭

JS、CSS、圖片這類靜態資源，和引用它們的 HTML 頁面要分開設定（12.5 已保存副本的更新方式：失效、purge、版本化網址與等待到期 的版本化網址）：

靜態資源那一列的 public 在多數情形是多餘的（12.1 HTTP 回應的保存位置：私有快取與共用快取），寫上它是為了讓意圖明確。31536000 是一年的秒數，是常見的取值，不是規範規定的上限。

HTML 頁面那一列放在共用快取後面時有一個代價：實測的 Varnish 與 nginx 預設不保存 no-cache 的回應，每個請求都會到 origin（12.3 過期副本的驗證：條件請求、304 回應、no-cache 與 no-store 的〈共用快取實作的驗證預設〉）。要讓 CDN 也保存 HTML，用只給 CDN 的期限，例如 CDN-Cache-Control: max-age=600，Cache-Control 維持 no-cache：實作 RFC 9213 的 CDN 依它保存並忽略 Cache-Control，其他快取照 no-cache（12.1 HTTP 回應的保存位置：私有快取與共用快取 的〈把指令指定給特定快取：CDN-Cache-Control〉）。s-maxage 不適合這個用途：它同時作用於清不掉的轉送代理，而且和 no-cache 並存時，共用快取每次使用前仍要驗證。改版時再用 purge 清掉 CDN 上的副本（12.5 已保存副本的更新方式：失效、purge、版本化網址與等待到期 的〈purge〉）。這組設定還有一個前提：網站沒有用 Service Worker 以快取優先的策略攔截頁面請求，否則 HTML 的 no-cache 不會生效。

公開且會變動的回應的快取標頭

不分使用者、但內容會變動的回應（文章列表、商品資訊、公開的讀取 API），可以讓每一層快取保存，期限由業務能容忍多久的舊資料決定，例如 Cache-Control: max-age=<秒數>, stale-while-revalidate=<秒數>, stale-if-error=<秒數>：max-age 是可以直接使用的時間，兩個 stale 窗口讓過期之後與 origin 出錯時仍有內容可給（12.6 過期副本的延用：stale-while-revalidate 與 stale-if-error）。舊資料會造成錯誤行為的回應（付款狀態、庫存數字）不加 stale 指令，改用 no-cache。

錯誤回應也要明寫標頭：404 屬於可啟發式快取的狀態碼，資源上線前被查過一次，沒有快取標頭的 404 就可能留在快取裡，上線之後仍回 404。實測的 Varnish 會把它保存 default_ttl 的時間，Chromium 與 Firefox 的啟發式規則對 404 不保存，CDN 查各家的預設。

檢查實際送出的快取標頭

設定寫在 origin 的程式或伺服器設定裡，但使用者實際拿到的標頭，可能被 CDN、反向代理或框架改過。檢查方式是從外部送請求，看回應：

 1# 只看標頭：-s 不顯示進度，-I 送 HEAD 請求並印出回應標頭
 2curl -sI https://<網域>/<路徑>
 3
 4# 送 GET、只印標頭：-D - 把回應標頭印到標準輸出，-o /dev/null 丟掉內容
 5curl -s -D - -o /dev/null https://<網域>/<路徑>
 6
 7# 帶身分送 GET，標頭與內容都印出來，再拿去和不帶身分的結果比對
 8curl -s -D - -H "Authorization: Bearer <token>" https://<網域>/<路徑>
 9
10# 以 Cookie 識別身分的服務，改帶 Cookie
11curl -s -D - -H "Cookie: <cookie>" https://<網域>/<路徑>
12
13# 繞過 CDN、直接連 origin，取得 origin 原本送出的標頭，再和上面經過 CDN 的結果比對
14curl -sI --resolve <網域>:443:<origin 的 IP> https://<網域>/<路徑>

<網域>/<路徑> 換成要檢查的網址；<token> 換成某個測試帳號登入後拿到的存取權杖，Bearer 是權杖類型，服務用的若是別種驗證方式就換成它要的格式；<cookie> 填那個測試帳號登入後的 Cookie 值；<origin 的 IP> 填 origin 伺服器自己的位址，也就是 CDN 設定裡的回源位址，--resolve 讓 curl 把這個網域直接連到那個位址、不經過 CDN。規範要求伺服器對 HEAD 回應的標頭應該（SHOULD）與 GET 相同，但允許省略只有產生內容時才決定的欄位，例如 Vary（RFC 9110 §9.3.2），所以檢查 Vary 時用送 GET、只印標頭的那條指令。

看回應時注意四件事：

• Cache-Control 是不是 origin 設定的那一組，有沒有被中間的 CDN、反向代理或框架改寫或附加。
• 有沒有 Age：有就代表這份回應來自某個快取，值是副本的年齡（12.2 新鮮度期限的計算：max-age、s-maxage、Expires 與啟發式期限）；沒有不代表一定來自 origin（實測的 nginx 1.27 proxy_cache 不送 Age）。
• CDN 自己加的命中標頭（名稱各家不同，查各家文件）：看這次是命中快取還是回到 origin。
• 先跑帶身分的那條，讓沿路的快取有機會存下這份回應；在共用快取保存這份回應的期限內（看 s-maxage、max-age、Expires、CDN-Cache-Control 或 CDN 設定的保存時間，都沒有就緊接著跑），再跑拿掉 -H 的同一條，兩次都連對外的網址（經過 CDN 與反向代理），比對兩份內容。不帶身分卻拿到測試帳號的內容，就是 12.4 快取鍵與副本共用：Vary、Cookie 與 Authorization 描述的外洩。兩份內容沒有差異，不能證明沒有外洩：兩次請求可能落在 CDN 的不同節點，要多跑幾次並對照命中標頭。順序顛倒時檢查的是另一件事：快取存下的匿名回應，會不會被發給登入的使用者。

推導源頭

本模組各章從同一個事實展開：回應離開 origin 之後，origin 能交給下游副本的指令只有回應當下附帶的標頭，而每個快取依自己的實作預設解讀這些指令。 由這個事實依序推出：

• 副本存放在哪些快取、各由誰經營（12.1）
• 副本在不詢問 origin 的情況下可以直接使用多久（12.2）
• 副本過期之後怎麼向 origin 確認是否仍然有效（12.3）
• 一個請求會拿到哪一份副本（12.4）
• origin 想改變已存副本時，各種更新手段的作用範圍（12.5）
• 在什麼條件下允許給出過期副本（12.6）
• 瀏覽器在重新整理與上一頁時怎麼使用它的副本（12.7）
• 把前述規則用在具體回應上（12.8）

讀者定位

讀者是寫過 HTTP 服務、知道狀態碼與標頭是什麼，但沒有系統讀過 HTTP 快取規範的後端工程師。他缺的是兩件事：標頭在各種快取上的精確語意，以及規範與實作之間的落差。

規範與實作預設的分界

本模組每一章都區分兩類行為：規範規定的行為（RFC 9111 HTTP Caching、RFC 9110 HTTP Semantics 與相關擴充），以及某個快取實作的預設。實測一次 Varnish 7.7、nginx 1.27 與 Chrome 154 的結果顯示，兩者落差很大：同一組標頭，實作的預設可能比規範保守、比規範寬鬆或違反規範，三類的界定寫在 12.1〈可以被保存的回應〉。文章寫出落差的形狀與該去哪個設定項查；預設數值只在說明落差形狀時引用，並標明讀取日期與版本；CDN 的預設行為各家不同，以各家文件為準。

章節列表

和其他模組的分工

• 5.9 邊緣分發與靜態資源 處理 CDN 的營運面（origin 保護、tag purge 的操作模型）；本模組處理標頭語意，5.9 快取分層表的瀏覽器與邊緣層兩列以本模組為準。
• Stale-While-Revalidate、Stale-If-Error 兩張卡直接沿用；Freshness Window 卡處理業務能容忍多久的舊資料，12.5 把它和新鮮度期限接上。
• 0.24 短網址服務的實作 的快取標頭一節是 12.8 快取設定的應用：轉址、需登入的 API 回應與個人化頁面 〈轉址回應的狀態碼與快取標頭〉一節的一個實例。

研究材料

規範條文取自 RFC 9111、RFC 9110、RFC 9213、RFC 5861、RFC 8246 原文（2026-10-02 取得）；瀏覽器實作對照 Chromium net/http/http_response_headers.cc 與 Firefox nsHttpResponseHead.cpp（同日 main 分支）；實測環境是 docker 上的 Python origin、Varnish 7.7.3、nginx 1.27.5 與 Chrome 154。實測腳本與設定不放進文章，文章只引用觀察結果。

Backlog

格式見 Backlog 段格式規範。目前沒有待辦項目。

概念位置

Cache-Control 位在 HTTP 快取的指令層，常用指令按職責分組：

• 保存位置：private 只讓使用者自己的瀏覽器保存，public 允許共用快取保存帶 Authorization 請求的回應，no-store 讓任何快取都不保存。
• 新鮮度期限：max-age 給所有快取，s-maxage 只給共用快取並取代 max-age。兩者都沒有、也沒有 Expires 時，快取改用 Heuristic Freshness 自己估。
• 過期後的處理：no-cache 要求每次使用前都先向 origin 驗證，must-revalidate 禁止過期之後不經驗證就給出舊版，Stale-If-Error 允許 origin 出錯時給出舊版。

哪些請求共用同一份保存的回應不由這個標頭管，那是快取鍵與 Vary 的職責。

可觀察訊號與例子

一個需要登入才拿得到的 API 回應寫 Cache-Control: private, no-cache 加上 ETag：CDN 不保存，使用者的瀏覽器可以保存，但每次使用前都送條件請求確認，內容沒變時 origin 回 304、省下傳輸內容。同一個網站的版本化靜態檔（檔名含內容雜湊）寫 public, max-age=31536000, immutable，每一層快取都可以在一年內直接使用。

回應完全沒有 Cache-Control、也沒有 Expires 時，它仍可能被保存：狀態碼屬於可啟發式快取的種類（例如 200、301、404）時，各快取依自己的規則估一個期限，同一個 301 在不同瀏覽器與代理上得到的期限可能差到從零到永不過期。

判讀方式

讀一個回應的 Cache-Control 時，依序問三件事：它能不能給別人（看 private／public；請求帶 Authorization 時規範禁止共用，但實作不一定遵守，需登入的回應明寫 private，見 12.4 快取鍵與副本共用：Vary、Cookie 與 Authorization）、內容會不會改（看期限指令，沒有期限就是交給各快取自己估）、origin 改了內容之後最慢多久要讓所有人看到（期限加上 stale 窗口，以及上游沒傳 Age 時各層期限相加，見 12.5 已保存副本的更新方式：失效、purge、版本化網址與等待到期）。

名稱與作用容易對不上的兩個指令：

• no-cache：可以保存，但每次使用前都要驗證；讓快取完全不保存的是 no-store。
• private：只規定保存位置（共用快取不存），不保護內容本身。另外，回應另外帶了有效的 CDN-Cache-Control（或該 CDN 認得的同類欄位）時，實作它的 CDN 會整個忽略這則回應的 Cache-Control，private 也跟著失效。

完整的規範與實作差異在 模組十二：HTTP 快取與回應保存規則：保存位置與各指令的對象見 12.1 HTTP 回應的保存位置：私有快取與共用快取，期限的取用順序見 12.2 新鮮度期限的計算：max-age、s-maxage、Expires 與啟發式期限，no-cache、no-store、must-revalidate 的差別見 12.3 過期副本的驗證：條件請求、304 回應、no-cache 與 no-store，具體回應的標頭選擇見 12.8 快取設定的應用：轉址、需登入的 API 回應與個人化頁面。