Cloudflare 推出快取回應規則：多餘的 Set-Cookie 害網站快取失效，現在不改後端也能修

一句話看懂：Cloudflare 新增「快取回應規則」，讓你在原站回應之後、存進快取之前，才去改標頭、決定能不能快取，所以不用改後端程式，也能修掉被多餘標頭拖垮的快取。

先用白話講：CDN 快取是怎麼回事？

想像你開一間網路商店，客人從世界各地下單。如果每次都要從遠方的倉庫（你的主機）出貨，會很慢也很貴；所以在各地放一間小倉庫，這就是 CDN 快取：常用的檔案先放在離客人近的地方，客人要的時候直接拿。

但倉庫有個規矩：只存「大家都能拿」的東西。如果倉庫收貨時發現包裹上貼了一張寫著「這是某位客人的專屬件」的標籤（Set-Cookie），就不敢放進共用貨架，每次都得退回遠方倉庫重拿。

問題是，這張標籤常常只是系統不小心貼上去的，例如程式框架預設替每個回應都帶一個 session cookie，連 JS、圖片這種靜態檔案也不例外。

發生什麼事

Cloudflare 在 7 月 23 日發布新功能 Cache Response Rules。它跟既有的 Cache Rules 差在「執行時機」：

以前遇到這類問題，官方列出三種做法：去改原站、寫一個 Worker 重新抓取並改寫回應，或是忍受比較差的快取命中率。現在多了第四種，直接在 Cloudflare 上設規則就好。

三種動作

• 清掉標頭：在 Cloudflare 判斷能不能快取之前，先把 Set-Cookie、ETag、Last-Modified 拿掉
• 管理快取標籤：新增、移除或設定用來「依標籤清除快取」的標籤，也能用運算式從原站的標頭轉換（換 CDN 時，把舊廠商的標籤格式轉成 Cloudflare 的很方便；官方說依標籤清除通常在 150 毫秒內全球生效）
• 改寫 Cache-Control：設定或移除 max-age、s-maxage、no-cache、immutable 等指令；加上 cloudflare_only 後，只改變 Cloudflare 的快取行為，瀏覽器收到的標頭不變

給開發者的技術細節

儀表板的路徑是 Cache > Cache Rules > Create rule > Cache Response Rule；API 的規則集放在這個階段：

/zones/{zone_id}/rulesets/phases/http_response_cache_settings/entrypoint

官方的範例之一：靜態副檔名的回應，清掉 Set-Cookie。

{
  "expression": "http.request.uri.path.extension in {\"js\" \"css\" \"woff2\" \"png\"}",
  "action": "set_cache_settings",
  "action_parameters": { "strip_set_cookie": true }
}

要留意的限制與取捨：

• 兩種規則衝突時，以快取回應規則為準
• 它不能改快取鍵，也不能把請求階段已判定不可快取的內容變成可快取
• 同時清掉 ETag 和 Last-Modified 會啟用 Smart Edge Revalidation；若之後又補上新的驗證標頭，就不會對瀏覽器的條件請求啟用這項功能
• immutable 只適合搭配有雜湊檔名的檔案，否則瀏覽器連手動重新整理都不會重新檢查
• 範例是用副檔名清掉 Set-Cookie，前提是這些檔案的 cookie 並非必要；如果網站靠 cookie 決定同一網址的內容變化，要改成更精準的比對

我的看法

接案時最常遇到的狀況是：網站慢，但後端是別人寫的，或是用了不好動的框架，只能在前面想辦法。這種時候「在 CDN 那一層修標頭」很實用，因為不用等後端排程、也不用冒著動到舊程式的風險。

但也要小心：規則一旦寫太寬，會把本來不該共用的內容放進共用快取，例如把某位使用者的頁面快取給所有人，這比快取命中率低嚴重得多。我會先只對確定是靜態、有雜湊檔名的資源開，並在上線後用快取命中率與抽樣檢查標頭的方式確認結果；官方自己也在每個範例後面附了注意事項，值得照著看一遍。

名詞小辭典

• CDN：在世界各地放置副本伺服器，讓使用者從最近的地方取得網站內容的服務。
• Cache-Control：網站用來告訴快取「能存多久、能不能存」的標頭。
• Set-Cookie：伺服器要求瀏覽器記住某些資料（常用來辨識登入狀態）的標頭。
• 快取標籤（Cache-Tag）：替快取內容貼上的分類標籤，可以一次依標籤清掉一批內容。

資料來源

• Cloudflare 部落格：Introducing Cache Response Rules（2026-07-23）