一年前，我們推出了 Cache Rules，這是一種在 Cloudflare 上自訂快取設定的新方法。Cache Rules 為使用者快取內容的方式提供了更大的靈活性，提供了精確的控制、使用者友好的 API 和無縫 Terraform 整合。自 2022 年 9 月底發佈以來，已有超過 10 萬個網站使用 Cache Rules 來微調快取設定。
今天，我們很高興地宣佈，Cache Rules 以及其他幾種規則產品已正式上市 (GA)。但這還不是全部——我們還為 Cache Rules 引入了新的設定選項，提供了更多選項來自訂您在 Cloudflare 上的快取方式。其中包括定義哪些資源可以使用 Cache Reserve、從來源伺服器接收資料時應遵守哪些逾時值、快取內容時應使用哪些自訂連接埠，以及在沒有 cache-control 標頭的情況下是否應繞過 Cloudflare 的快取。
Cache Rules 為使用者提供了完全的控制能力，使其無需編寫程式碼即可針對幾乎任何用例定制內容交付策略。隨著 Cache Rules 正式上市，我們非常期待能夠看到客戶快速實現其完美的快取策略。
Cloudflare 自訂快取的歷史
Cloudflare 上的快取自訂之旅始於十多年前，也就是公司成立之初。從一開始，我們的客戶最常見的要求之一就是簡化他們的設定。客戶希望為其網站上的任何頁面輕鬆實作精確的快取策略、套用強大的安全措施、操作標頭、設定重新導向等。使用 Cloudflare 設定這些控制對於使用來源伺服器的客戶尤其重要，因為這些伺服器僅提供複雜的設定選項來向回應新增標頭或原則，而 CDN 隨後會將其套用到下游。
為了滿足這一需求，我們推出了 Page Rules，自推出以來，該產品的受歡迎程度和功能都取得了顯著的增長。對於尋求對 Cloudflare 快取內容方式進行精細控制的客戶來說，Page Rules 成為首選。目前，有超過 500 萬條與快取相關的作用中 Page Rules，可協助網站定制其內容交付策略。
然而，在幕後，Page Rules 遇到了可擴展性問題。
每當 Cloudflare 遇到一個 Page Rule 時，我們必須將客戶的所有規則條件轉換為單個 regex 模式。然後將此模式套用至對網站的請求以實現所需的快取設定。當考慮如何將來自所有客戶的所有 regex 與跨越全球 300 多個資料中心的每秒數千萬個請求進行比較時，很容易看出套用 Page Rules 的運算需求可能是巨大的。這種壓力與我們能夠為使用者提供的規則數量直接相關。例如，Page Rules 僅允許在給定網站上部署 125 條規則。
為了應對這一挑戰，我們在新的規則集引擎上重建了所有 Page Rule 功能。基於規則集引擎的產品不僅為使用者提供了更多可以使用的規則，而且還為這些規則的執行時間提供了更大的靈活性。規則集引擎的神奇之處在於，規則邏輯可以根據條件進行評估，而不是將頁面的所有規則組合到單個規則運算式中。例如，如果子網域 A 和 B 具有不同的快取原則，則可以使用特定於 A 的規則運算式邏輯來評估來自子網域 A 的請求（同時忽略適用於 B 的任何邏輯）。這將大大提高效能，並減少了跨 Cloudflare 網路套用 Page Rules 的運算需求。
在過去的一年裡，Cache Rules、Origin Rules、Configuration Rules 和 Single Redirect Rules 一直處於測試階段。感謝早期採用者的寶貴支援，我們成功地對我們的產品進行了微調，達到了從測試版過渡到正式版的階段。這些產品現在能夠完成 Page Rules 可以完成的所有任務，甚至更多。這也標誌著 Page Rules EOL 流程的開始。在接下來的幾個月中，我們將公佈有關客戶如何使用特定規則產品替換其 Page Rules 的時間表和資訊。我們將盡可能自動化此過程，並提供簡單的步驟，以確保每個人都能從 Page Rules 順利遷移。
如何使用 Cache Rules 以及新功能推出
使用過 Cache Rules 的人都知道，它們很直觀，並且與我們的其他規則集引擎產品類似。評估使用者定義的條件（例如 URL 或請求標頭），如果匹配指定值，則遵守 Cloudflare 快取設定。每個 Cache Rule 都取決於欄位、運算子和值。如需所有可用的不同選項，請查看我們的 Cache Rules 文件。
以下是如何部署不同策略來自訂快取的兩個範例。這些範例僅展示了 Cache Rules 的冰山一角，因此我們鼓勵您嘗試這些規則，並告知我們您的看法。
範例：快取內容定期更新
舉個例子，假設 Acme Corp 想要更新他們的快取策略。他們希望自訂快取以利用某些請求標頭，並使用這些請求標頭的存在作為決定何時套用不同快取規則的條件。他們需要決定的第一件事是應該使用哪些資訊來觸發特定規則。這是在運算式中定義的。
定義觸發準則後，Acme Corp 接下來就應該確定如何自訂快取。
內容快速變更
最常見的快取策略是更新邊緣快取 TTL。如果 Acme Corp 認為其網站上的特定內容可能會快速變更，他們可以將 Cloudflare 認為有資格從快取提供服務的資源的時間縮短。這樣，Cloudflare 就會更頻繁地返回來源以重新驗證和更新內容。在邊緣快取 TTL 部分，Acme Corp 還可以根據 Cloudflare 從其來源返回的狀態碼定義資源的 TTL，以及在 Acme 來源伺服器沒有傳送任何快取控制指令的情況下 Cloudflare 應快取的內容。
內容變更緩慢
另一方面，如果 Acme Corp 有很多不經常變更的內容（例如網站圖示或標誌），並且他們更願意從 Cloudflare 的快取而不是其來源提供這些內容，那麼他們可以使用新的 Cache Rule 來定義哪些內容有資格從 Cache Reserve 提供。Cache Reserve 透過將資產長期儲存在 Cloudflare 的快取中來降低輸出費用。
傳統上，當使用者啟用 Cache Reserve 時，他們的整個區域將有資格寫入 Cache Reserve。對於希望節省其網站上所有資源的來源輸出費用的客戶來說，這仍然是最佳選擇。但是，對於希望精確控制哪些資產應成為其 Cache Reserve 的一部分，甚至哪些規模的資產應符合條件的客戶來說，Cache Reserve 資格規則提供了額外的選項，使客戶可以精確地增加其快取命中率，並以自訂的方式減少來源輸出。請注意，該規則要求 Cache Reserve 訂閱。
範例：來源速度緩慢
讓我們考慮一個假設的範例。最近，Acme Corp 發現其 Cloudflare 記錄中的錯誤有所增加。這些錯誤與 Acme 根據其專有資料向使用者提供的新報告有關。該報告要求其來源存取多個資料庫，執行一些計算並根據這些計算產生報告。產生此報告的來源需要等到所有這些背景工作完成才能做出回應。Acme 的報告非常成功，吸引了大量遊客前來觀看。但他們的來源卻在奮力追趕。他們看到許多 524 錯誤，表明 Cloudflare 並未看到來源回應，直到逾時。
Acme 計劃透過擴展其來源基礎架構來改進這一點，但部署需要很長時間。與此同時，他們可以求助於 Cache Rules 來設定更長的逾時。一直以來，Cloudflare 與兩次連續來源讀取之間的逾時值為 100 秒，這意味著如果來源在超過 100 秒的時間內未成功傳送回應，則可能會導致 524 錯誤。透過使用 Cache Rule 來延長此逾時，Acme Corp 可以更加依賴 Cloudflare 的快取。
上述快取策略重點關注來源上資源變更的頻率以及來源的效能。但還有許多其他規則允許其他策略，例如自訂快取鍵（允許客戶確定如何在 Cloudflare 上定義其快取）、遵守強 ETag（協助客戶確定 Cloudflare 何時應重新驗證特定快取資產）以及自訂連接埠（允許客戶定義 Cloudflare 在做出有關內容的快取決策時應使用的非標準連接埠）。
可在此處找到 Cache Rules 的完整列表。
立即試用 Cache Rules 吧！
我們將繼續構建和發佈更多規則，為使用 Cloudflare 快取的任何人提供強大、易於啟用的控制。如果您有其他 Cache Rules 功能請求，請在 Cloudflare 社群告訴我們。
立即前往儀表板並試用 Cache Rules 吧！