Cloudflare 推出可設定的 HTTP Vary 支援，解決內容協商與快取碎裂困境
HTTP 快取是現代網站效能的重要基石，而 Vary 回應標頭（response header）是其中一個關鍵但常被忽略的機制。當伺服器要根據客戶端的不同請求條件，回傳不同版本的內容時，就會透過 Vary 告訴下游的快取伺服器：「這個回應是根據哪些請求標頭產生的」。例如，伺服器可能根據 Accept-Language 回傳不同語言的網頁，或是根據 Accept 回傳不同格式的圖片。然而，這個看似單純的機制，在內容傳遞網路（CDN，Content Delivery Network）的實際運作中，卻可能引發嚴重的快取碎裂問題。
問題的根源在於客戶端請求標頭的多樣性。瀏覽器或應用程式發送的請求標頭，其內容格式並非絕對標準化，可能包含不同的空白字元、大小寫差異，或是語言優先順序的排列變化。如果 CDN 原封不動地依照 Vary 指示進行快取，這些微小的差異就會讓同一個資源被拆分成數十種不同的快取版本。Cloudflare 在對約五萬個頂級網域、超過一億兩千萬個 HTTP 回應的實證調查中發現，將近三千個來源伺服器會根據四個以上的請求標頭產生不同回應，極端案例甚至會依據數十個欄位進行區分。這種失控的標頭變異，導致快取命中率大幅下降、來源伺服器負載飆升，也就是所謂的快取抖動（cache thrashing）現象。
為了解決這個正確性與快取效率之間的矛盾，Cloudflare 將內容協商的過程拆解為兩個階段。首先，來源伺服器依然負責宣告哪些請求標頭會影響回應的產生。接著，Cloudflare 的 Cache Rules 機制則接管了後續的處理，決定邊緣節點在計算快取鍵（cache key）之前，要如何處理、正規化或忽略這些標頭的值。這個兩階段架構的關鍵在於，快取規則會動態觸發，只有當來源伺服器實際回應了 Vary 標頭時才會介入，避免了過去需要事先猜測標頭、對所有請求都套用複雜規則的困境。
在 Cache Rules 中設定 Vary 處理方式時，操作者可針對單一標頭定義行為，或對未列出的欄位套用預設策略。系統提供三種不同的動作：正規化（normalise）、直接傳遞（pass through）與略過（bypass）。正規化會將 Accept 或 Accept-Language 這類複雜的協商標頭，轉換為標準化的等效類別，消除客戶端之間無關緊要的差異，是提升快取命中率的主要手段。直接傳遞則會儲存完全比對、區分大小寫的原始字串，適用於來源應用程式高度依賴精確 token 比對的場景。至於略過，則是針對高變異性或高基數（high-cardinality）的標頭，直接跳過邊緣快取，確保不確定的內容變體不會佔用快取空間。
底層運作上，Cloudflare 會將來源伺服器宣告的 Vary 欄位，與由 scheme、host、path 組成的基礎快取鍵一起記錄。後續請求抵達時，邊緣節點會先執行基礎快取鍵的查詢。若該鍵已註冊了變體，就會提取對應的請求標頭，依照設定的 Cache Rule 動作進行評估，並提供相符的變體。若沒有符合正規化條件的快取變體，請求便會轉發至來源伺服器，回應內容則會被索引並加入變體池中。
Cloudflare 的產品經理 Alex Krivit 與系統工程師 Zaidoon Abd Al Hadi 指出，這套兩步驟架構解決了過去手動因應方案的長期限制。以往團隊只能在停用快取、依賴 Cloudflare Workers 自訂邏輯、維護脆弱的自訂快取鍵，或使用像是 Vary for Images 這類特殊擴充功能之間做選擇。其中，自訂快取鍵是在請求進來時就預先評估規則，即使來源伺服器回傳的是靜態、不變的回應，也會套用規則，導致不必要的鍵空間膨脹。相比之下，新的 Vary 規則只有在來源伺服器真的回應了 Vary 標頭時才會觸發，對於不會變動的回應，完全不會增加額外的快取鍵。
儘管這項新機制大幅降低了內容協商的實作門檻，操作者仍需謹慎評估快取鍵的基數。當啟用直接傳遞模式處理包含任意 token 或 session 識別碼的高熵標頭時，每個不同的客戶端字串都會建立獨立的邊緣快取項目，這將縮短快取的有效壽命，並增加快取汰換的頻率。目前，Vary 支援已於 Cloudflare 所有方案（Free、Pro、Business、Enterprise）中啟用，讓各規模的開發者都能更精細地控制內容快取策略，在回應正確性與邊緣效能之間取得更好的平衡。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。