前言

在已經完成的CF系列教學"一"到"五"中，除了"一"到"三"的築基三部曲之外，後續的"四"和"五"我分別介紹了CF WAF和CF DDoS防護，因為我認為這2個功能是CF流量序列中最有價值的2個重點功能，值得我用單獨的篇幅來詳細介紹。

但是，由於每個人實際環境以及需求各不相同，CF流量序列中還有很多其他功能，對於需要的人來說都可以說是有價值的重點功能，例如Cache Rules。

其實，Cache Rules提供的CDN功能本來應該是CF最受歡迎的功能，只是，由於國內網路環境的特殊性，導致Free計畫的使用者使用了CF的CDN之後，不管是訪客被指派的存取位址還是回源請求發起的地點，大機率被分配到美國的CF資料中心(以美西的聖荷西資料中心最多)，這導致訪客體驗大機率不如不使用CF CDN直接存取來得快(畢竟往返都要跨太平洋)，所以才有對國內訪問」負優化」之稱。

不過，除了國內的訪客以及某幾個相似的特殊國家之外，全球其他地區的訪問體驗還是不錯的，所以CF的CDN功能還是有必要配置(特別是對於那些戰略著眼於全球而非僅僅是國內的人而言)。

另外，對於某些內容(比如圖床的圖片)而言，慢那麼一點其實感知也並不明顯，所以，CF的Cache Rules的確也是重要且最有價值的功能之一。

Cache Rules(快取規則)

Cache Rules介紹

預設(未配置任何快取規則時)，CF只會對部分副檔名的靜態資源生效(TTL一般都為2小時)，這些靜態資源包含但不限於：

1. 影像檔案：
   .jpg, .jpeg, .png, .gif, .ico, .svg 等
2. 字型文件：
   .woff, .woff2, .ttf, .otf, .eot 等
3. CSS文件：
   .css
4. JavaScript文件：
   .js
5. 多媒體檔案：
   .mp3, .mp4, .avi, .mkv, .webm, .ogg 等
6. 文件文件：
   .pdf, .doc 等

這樣是非常不方便的，我可能有其他正常的需求，例如：

• 我不想緩存.mkv擴展名的視頻文件，因為我網站上這格式的視頻文件很多且都很大，如果緩存並且訪問量還大的話，很可能導致我被CF封號
• 我想快取HTML文件，但預設的靜態資源裡並不包括HTML
• 預設的2小時太短，我想快取更長時間
• ……..

諸如以上的自訂需求太多也太普遍，為了解決用戶這些正常及普遍的對快取的自訂需求，CF推出了Cache Rules。

CF的Cache Rules功能可讓使用者根據特定的條件和需求自訂快取行為，從而控制CDN、瀏覽器快取的內容和生效時間，進而達到優化網站內容的載入速度和快取效率的效果。

Cache Rules的主要功能和特點如下：

1. 靈活的快取控制：使用者可以設定規則來定義哪些內容應被緩存，哪些內容不應緩存。例如，可以指定特定路徑、請求頭、查詢參數等，以控制快取行為。
2. 支援複雜條件：Cache Rules支援基於URL路徑、HTTP頭、查詢參數等多種條件進行匹配，使用者可以建立複雜的快取策略，如快取特定檔案類型、基於地理區域的快取策略等。
3. 優先管理：使用者可以為不同的快取規則設定優先權，確保高優先權的規則在快取控制中優先執行，幫助實現更精確的快取管理。
4. 動態和靜態內容的區分：使用者可以根據內容類型（靜態或動態）設定不同的快取策略，優化快取命中率和伺服器負載。
5. 即時生效和除錯：規則變更後可以即時生效，使用者可以透過Cloudflare的儀表板或API進行管理和偵錯，方便快速調整和測試快取策略。
6. 整合其他Cloudflare服務：Cache Rules與Cloudflare的其他服務（如WAF、Rate Limiting、Argo Smart Routing等）集成，提供更全面的安全性和效能最佳化功能。

Cache Rules上手指南

Cache Rules規則構成

一條Cache Rules的規則有2部分內容組成，請求傳入符合和快取資格。

請求傳入匹配

允許使用者設定傳入請求匹配的特定條件，以此作為後續是否進行快取的前置判定。
常用的匹配條件有以下幾種：

1. URL路徑
   • 基於URL路徑的匹配，如特定的資料夾或檔案副檔名。
   • 支援通配符和正規表示式比對。
2. 主機名稱
   • 根據要求的主機名稱進行比對。
3. 查詢參數
   • 根據請求的查詢參數進行匹配，允許對具有特定參數的請求進行快取控制。
4. HTTP請求方法
   • 依照GET、POST等HTTP請求方法進行比對。
5. HTTP請求頭
   • 基於特定的請求頭進行匹配，如User-Agent、Accept-Language等。
6. Cookie
   • 根據請求中包含的特定Cookie進行配對。

其他可選的判斷條件還有：引用方、SSL/HTTPS、用戶代理、X_Forwarded_For等。

快取資格

對滿足設定的傳入請求匹配的存取流選擇是繞過快取還是進行緩存，有以下2種選擇：

1. 繞過快取
   • 讓CF不要快取來源伺服器對滿足請求傳入符合的存取請求的回應內容，通常用於存取請求對動態內容或需要登入存取的內容的存取。
   • 唯一可選項的只有瀏覽器TTL
   
2. 符合快取條件
   • 讓CF快取來源伺服器對滿足請求傳入符合的存取要求的回應內容，通常用於存取要求對靜態內容的存取。
   • 有6個可選項，其中，以邊緣TTL和瀏覽器TTL最常用，本文中就以這2個選項為例進行演示：
   

註：邊緣TTL指靜態內容在CF邊緣快取的存在時間，瀏覽器TTL指靜態內容在瀏覽器本地的快取中的存在時間，一般來說，為了頁面內容顯示的一致性，瀏覽器TTL的時間應該小於邊緣TTL。

Cache Rules設定邏輯

Free計畫中，Cache Rules有10條的額度，足夠一般人使用了，不過，在配置邏輯上，有幾點要注意。

1.規則序號越小優先權越高，所以需要整理好快取規則的邏輯順序，將優先順序高的排在前面，一般是需要繞過快取的在前，如下圖：

2.動態網站的非動態內容部分也可以緩存，不過需要在優先順序較高的繞過快取部分的規則中先排除掉動態內容部分。
3.流量序列中，Cache Rules的優先權較高，所以如果需要存取請求被流量序列中優先權較低的節點功能處理(例如Workers)，對於快取規則而言，需要保證存取請求命中快取規則的”繞過快取”，而不是命中”符合快取條件”。
4.如果託管二級網域下有多個子網域網站，且動態、靜態內容都有，那麼創建快取規則的時候，最好能加上主機名稱作為限制條件，避免快取邏輯不清不楚。

Cache Rules設定範例

靜態網站

以我群站導航頁網址www.tangwudi.com為例，假設採用的圖床網址為image.tangwudi.com，所採用的API路徑為www.tangwudi.com/api*，按照前面說的快取規則的配置邏輯，應該如下設定：
1.API屬於動態內容，需要繞過快取

2、對於圖床的圖片進行緩存


註：邊緣TTL和瀏覽器TTL為可選項，預設不設定均為2小時。對於圖片之類的靜態內容，是否設定TTL或設定多久需要看網站的類型而定，主要是看圖片更新的頻率。對於我的群組導航首頁而言，圖片基本上不會動，所以完全可以有多長設定多長，例如邊緣TTL直接設定1年也沒毛病，至於瀏覽器TTL，理論上設定1年也可以，但沒必要，保險起見1個月就差不多了，靜態個人部落格類型的網站也是一樣的道理。
3.其他靜態內容的快取(主要是HTML)

邊緣TTL和瀏覽器TTL和圖片快取一樣：

最終完成效果：

---

註1：圖片快取和HTML快取在此例中的TTL(邊緣TTL和瀏覽器TTL)是一樣的，理論上可以將2條規則合為一條，但是，這只是由於此例的特殊性，一般來說，圖片快取的TTL和HTML的TTL一樣的可能性並不大，所以分開用2條」符合快取條件」的規則是合理的。不同TTL的快取內容需要用不同的規則來設置，至於最終需要多少條快取規則,則由網站內容在快取控制方面的精細程度決定。
註2：請依實際環境將主機名稱”blog.tangwudi.com「替換為自己的實際主機名稱。

---

動態網站

我的部落格是使用wordpress搭建，也算是動態部落格類型的代表，所以就以我的部落格網址blog.tangwudi.com為例，本例假定圖片是上傳到wordpress本身的媒體庫中，未使用外部圖床。由於wordpress網站的動態內容有其特點，例如特定URI( “/wp-admin”、”/wp-login”、”/wp-comment”等開頭的內容)以及包含特定cookie欄位(wp-、logged_in、 wordpress、comment_、woocommerce_)的請求皆不能緩存，所以為了確保準確性，採用分層規則匹配的方式，配置建議規則如下：

1.繞過存取連結中包含動態內容的特殊URI(從URI層面匹配)的存取請求的快取

注意規則的運算符，URI路徑的的運算符我這裡均為”包含”(這個是為了偷懶，當然也可以選擇運算符”開頭為”，那麼後面就要按格式寫，比如”開頭為”後面是”/wp-admin”)：

表達式為：

(http.host eq "blog.tangwudi.com" and http.request.uri.path contains "wp-admin") or (http.host eq "blog.tangwudi.com" and http.request.uri.path contains " wp-login") 或 (http.host eq "blog.tangwudi.com" and http.request.uri.path contains "wp-comment") 或 (http.host eq "blog.tangwudi.com" and http.request .uri.path contains "?s=") or (http.host eq "blog.tangwudi.com" and http.request.uri.path contains "xmlrpc") or (http.host eq "blog.tangwudi.com" and http.request.uri.path contains "preview=true")

2.繞過存取wordpress時cookie內包含特定字元的存取請求的快取

注意每條規則中”Cookie」的運算子均為包含：

表達式為：

(http.host eq "blog.tangwudi.com" and http.cookie contains "_logged_in_") or (http.host eq "blog.tangwudi.com" and http.cookie contains "wordpress") 或 (http.host eq " blog.tangwudi.com" and http.cookie contains "comment_") or (http.host eq "blog.tangwudi.com" and http.cookie contains "woocommerce_")

3.繞過以.php結尾的頁面

註：其實上面2條規則已經可以足以涵蓋動態內容了，這條只能算是打個補丁。

4、快取圖片內容

註：這部分的邊緣TTL以及瀏覽器TTL的設定參考文章前面部分描述。

5、快取HTML

表達式：

(http.host eq "blog.tangwudi.com" and ends_with(http.request.uri.path, ".html") and not http.cookie contains "_logged_in_" and not http.cookie contains "wordpress" and not http. cookie contains "comment_" and not http.cookie contains "woocommerce_") or (http.host eq "blog.tangwudi.com" and ends_with(http.request.uri.path, ".htm") and not http.cookie contains "_logged_in_" and not http.cookie contains "wordpress" and not http.cookie contains "comment_" and not http.cookie contains "woocommerce_")

註：這部分的邊緣TTL以及瀏覽器TTL的設定參考文章前面部分描述。

6、快取其他內容

這裡主要是針對除了HTML以外的其他內容，例如css檔案等。

註：這部分的邊緣TTL以及瀏覽器TTL的設定參考文章前面部分描述。

最終配置如下：

註1：其實第4,5,6條規則粗曠點可以只保留第6條，4,5都可以直接刪除，效果是一樣的，但是之所以分開還是為了降低風險以及讓邊緣TTL及瀏覽器TTL可以根據不同類型的快取設定各自適合的值。

註2：其實繞過快取規則的URI部分和cookie部分是互相覆蓋的關係，由於我對wordpress的細節不夠了解，為了保險寫成2條，主打一個保險。其實肯定有較多的重複規則，例如繞過cookie部分_logged_in_和wordpress這兩條就有點重複了，不過我看一些資料裡一會說wordpress_logged_in，一會說wp_loggen_in，我也懶得去深究了，乾脆2個都寫上去，最多重複，但是保險。

註3：使用wordpress建站的類型多種多樣，不同類型網站的動態內容可能有自己特有的URI或特有的cookie值，所以大家可能需要依照自己網站特性修改URI部分和cookie部分的內容。

註4：雖然上面的配置是以wordpress為例，但是其他動態部落格配置思路是一樣的，根據實際情況修改下就行了。

註5：請依實際環境將主機名稱”blog.tangwudi.com「替換為自己的實際主機名稱。

---

另：除了Cache Rules以外，還有另一個能設定CF快取行為的功能項目就是”頁面規則”，且頁面規則在流量序列中的處理優先權是高於Cache Rules的：

不過，一般不建議使用”頁面規則”來進行緩存，有以下幾點原因：

1.頁面規則只有3條額度(Free計劃)，太少了，而且頁面規則除了快取功能以外，還可以實現很多其他的功能，如下：

所以頁面規則應該用來實現更複雜的複合型需求，或者某些需要更高優先級處理的特殊流量的臨時處理上，僅僅用來實現Cache Rules都能完成的功能就太浪費了(畢竟Cache Rules有10條的額度，比頁面規則的3條寬鬆多了～)。

2.頁面規則的符合條件只能用URL，太簡陋了：

不像Cache Rules的」請求傳入符合」支援多種條件以及or和and的組合。

3.邊緣TTL最長只能一個月，Cache Rules可以設定為1年：

4.其實還有個原因就是不清除CF未來的態度，因為6月左右的時候，頁面規則其實已經公告被廢除，不過不知道後來怎麼又收回了廢除的通知，搞不清除以後會咋樣，所以能不用就不用吧，就算要用也盡量用在臨時性處理上，平時盡量使用流量序列上已有的節點功能來完成吧，這個最保險。

---

“快取”部分的其他可選項

在”快取”部分，有幾個選項大家可以依照自己的需求進行配置。

清除快取

清除快取檔案用來強制CF從您的Web 伺服器中提取這些檔案的最新版本。

可以選擇”自訂清除”以清除特定的URL(Free計劃只能清除完整匹配URL的資源，不支持*通配符)：

也可以選擇”清除所有內容”：

快取等級

快取等級決定CF應快取多少網站的靜態內容，CF的CDN 根據以下層級快取靜態內容：

• 沒有查詢字串
  當沒有查詢字串時，從快取交付資源。 範例URL：tangwudi.com/pic.jpg
• 忽略查詢字串
  向每個人提供相同的資源，與查詢字串無關。 範例URL：tangwudi.com/pic.jpg?ignore=this-query-string
• 標準(預設)
  每次改變查詢字串時都提供不同的資源。 範例URL：tangwudi.com/pic.jpg?with=query

除非有特殊要求，否則保持預設的」標準」即可。

瀏覽器TTL

這個其實就是預設的瀏覽器TTL值，如果存取請求沒有符合快取相關規則中設定的瀏覽器TTL值，或是來源伺服器設定的瀏覽器TTL值小於該值，就會使用此處的值，這個大家根據自己的需要設定即可。

Crawler Hints(爬蟲提示)

仔細研究了一下，發現這個功能比較有趣：當託管在CF上的網站內容發生變化的時候，該功能會記錄這些變化，然後向搜尋引擎和其他合法爬蟲程式提供有關內容變化頻率和重要性的提示，幫助爬蟲程式更聰明地安排抓取計劃，優先抓取變化頻繁或重要的內容，確保搜尋引擎索引的資訊是最新的，也因為爬取效率提高，減少了對來源站不必要的抓取，間接降低了來源站伺服器的負載。

另：怎麼感覺如果博客園當初使用CF並開啟了這個功能，百度蜘蛛爬蟲就不會把博客園爬得崩潰了？

該功能預設為關閉，沒什麼危險性，可以保持開啟。

Always Online™

簡單來說，就是當來源站發生故障的時候，如果用戶訪問連結頁面的內容在快取中，CF就會直接把這個內容回傳給用戶，並且在頁面頂部顯示一條訊息提示：來源站出問題了，這個只是快取內容。

關鍵問題在於這個功能主要是對能快取的靜態內容有效，動態內容和互動功能(如使用者登入、購物車等)在來源伺服器不可用時就無法正常運作。所以這個功能對於靜態類型的網站很好用，但是對於動態類型的網站就只能說聊勝於無了(我遇到過，wordpress來源站出問題時，有些頁面能打開，不過看起來佈局、顏色也不太正常，所以只能說聊勝於無)。

該功能沒啥危險性，可以保持開啟。

開發模式

此模式開啟後，所有請求都繞過CF的緩存，直接傳遞到來源伺服器。此功能在需要即時查看所做更改時非常有用。啟用後，如果未手動關閉，開發模式將持續三個小時，然後自動關閉。

Tiered Cache

簡單來說，如果不啟用該功能，那麼CF全球任何一個資料中心都可以直接向來源伺服器發起回源請求，即使這個資料中心離來源伺服器很遠。

而啟用此功能之後，CF會將全球資料中心分為上下2層，然後使用Argo 效能和路由資料為來源伺服器動態查找單一最佳上層(最佳上層離源伺服器最近，理論上回源效率最高) ，只有上層才能向來源伺服器發起回源請求，而下層只能向上層查詢。

該功能沒有危險性，可以保持開啟。

如何驗證快取狀態

靜態站點的驗證

一般的靜態類型的網站(以www.tangwudi.com為例)驗證快取狀態，可以依照下列流程進行驗證。

開啟chrome瀏覽器(或edge)，按”F12″進入開發者工具，點選”網頁”選項卡，類型選擇”全部”：

在瀏覽器網址列輸入www.tangwudi.com並回車，然後在”重新加載”按鈕上點右鍵並選擇”清空緩存並硬性重新加載”：

在左邊名稱處選擇www.tangwudi.com，在右邊”標頭”部分的”回應標頭”的”cf-cache-status”可以查看快取是否成功：

動態站點的驗證

以我的臨時測試站點blog.tangwudi.xyz為例：

註1：一般情況下，如果使用Cache Rules(或頁面規則)控制CDN完成緩存，cf-cache-status通常有3種結果：HIT(完全緩存)、DYNAMIC(部分緩存，一般是沒有配置專門的Cache Rules而只是觸發了CF預設的快取規則，或是動態網站登入後因為cookie裡的關鍵字匹配了」繞過快取」的策略，所以只是快取了一部分)、BYPASS(繞過，說明有快取規則設置繞過了該位址的快取)。

註2：以上驗證方式，只適合透過Cache Rules或頁面規則設定的常規快取策略實現的快取效果的驗證，不適合使用Workers或APO方式實現的智慧快取效果的驗證，智慧快取效果的驗證在後面相關教程中再講。

註3：對於動態網站(wordpress之類)，使用Cache Rules或頁面規則實現的常規緩存效果，類似於灌籃高手裡櫻木花道的”庶民投籃法”，效果一般，無法蹭到CF企業版用戶裡面的一些高級功能，所以只能說可以湊合著用，而要達到類似於」灌籃」的效果，就要依靠Workers或者APO了，這個留待後續的文章來寫。

後話

其實吧，這篇文章我本來是打算」Cache Rules、重定向、頁面規則」3個內容一起寫的，因為光是Cache Rules的內容我認為沒多少可寫的內容，幾句話就寫完了，但是，結果沒想到越寫越多。 。 。只能單獨用一篇文章來寫了。

不過仔細想來，這也是應該的：對於大部分人而言，WAF、DDoS、Cache Rules這3個功能加在一起，已經可以解決最常規的訪問和安全方面的問題了，所以，如果教程的一、二、三是」築基」三部曲的話，那麼四、五、六則可以稱之為」金丹」三部曲，會用了闖蕩江湖已經足以自保了～。