觀點 · 資訊分享
Cloudflare 快取看得懂 Vary 了：同一個網址能同時存好幾個語言或格式的版本，所有方案都能用
Cloudflare 的快取規則（Cache Rules）現在會依源站回傳的 Vary 標頭，為同一個網址存多個版本。以前為了不出錯只好繞過快取的內容，現在也能放進快取。
- 發布
- 2026-07-03
- 篇幅
- 約 3 分鐘 · 1,540 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：Cloudflare 的快取規則現在看得懂 Vary 標頭，同一個網址可以同時存好幾個版本，每個請求都會拿到對的那一份。
先用白話講：Vary 是什麼？
想像一間便利商店，同一款飲料有中文包裝和英文包裝，都放在同一個貨架位置。店員（快取）如果只記得「這個位置有一瓶飲料」，就可能把英文包裝發給想要中文的客人。
Vary 就是源站（你的網站主機）貼在貨架上的標籤：「這個位置的商品，要看客人的語言偏好才能決定給哪一瓶。」有了標籤，快取就知道要分開存多個版本，再依每位客人的請求挑對的給。
問題是，過去如果網站的內容會依語言或格式變動，為了不發錯內容，常常只好乾脆「不快取」，每次都回源站拿。
發生什麼事
Cloudflare 在 2026 年 7 月 2 日的更新日誌宣布：Cache Rules 現在會直接遵守 Vary 標頭。
- 同一個網址可以存多個版本，依請求標頭挑對應的版本
- 以前為了正確而必須繞過快取的內容，現在可以放進快取
- 計算快取鍵的方式依 RFC 9111 的標準；
Vary: *依 RFC 9110 仍然會繞過快取 - Free、Pro、Business、Enterprise 所有方案都能用
三種處理動作
啟用後，源站回應的 Vary 所列出的每個請求標頭，都會成為快取鍵的一部分，你要為每個標頭選一個動作：
| 動作 | 做什麼 | 適合 |
|---|---|---|
| normalize | 把意思相同的標頭值轉成同一個快取鍵再比對，合併重複版本 | 大多數 Accept、Accept-Language、Accept-Encoding 的情況 |
| passthrough | 用原始標頭值選版本，並原樣轉給源站 | 標頭值差一個位元組就該分版本時 |
| bypass | 只要源站的 Vary 出現這個標頭，就繞過快取 | 每人不同的值，或可能值太多、不適合快取的標頭 |
官方舉的例子：Accept-Language: en-US, fr;q=0.8 和 Accept-Language: fr;q=0.8, en-GB 經過 normalize 會對應到同一個快取鍵，所以更多請求能直接從快取回應，不用跑回源站。
給開發者的技術細節
源站先回 Vary 標頭，例如：
Vary: Accept-Language, Accept
接著到 Cloudflare 控制台的「Caching > Cache Rules」設定 Vary，也可以用 Rulesets API。如果是 Workers 的子請求（subrequest），官方提供 cf.vary 屬性做逐次控制。不需要改源站程式或 Worker，只要源站本來就有送 Vary 就行。
我的看法
做多語言網站時，常見做法有兩種：用網址路徑分語言（例如 /zh、/en），或同一個網址依瀏覽器的語言偏好回不同內容。前者對快取很友善；後者以前最麻煩，因為快取不知道怎麼分版本。這次更新讓第二種做法也有了正式的解法。
不過我會建議先用 normalize 開始，並且只對真的會影響內容的標頭啟用。每多一個要分版本的標頭，快取就多一個維度，命中率可能反而下降。啟用後記得觀察一陣子的快取命中率與回源流量，確認真的有變好，再決定要不要擴大套用。
名詞小辭典
- 快取（Cache）：把內容先存在離使用者近的地方，下次直接給，不用每次回源站拿。
- 源站（Origin）：真正放網站內容的主機。
- 快取鍵（Cache Key）：快取用來判斷「這是不是同一份內容」的依據。
- RFC 9111：HTTP 快取的官方標準文件。