Rule Provider 實戰：讓規則集自動更新，告別手動維護

為什麼要用 Rule Provider

直接把幾百條 DOMAIN-SUFFIX 平鋪在 rules 清單裡也能運作，但維護成本很高：規則集作者更新了內容，你就得手動同步；規則條數一多，配置檔案也會變得難以閱讀。Rule Provider 把這部分內容拆成獨立的遠端檔案，用戶端按設定的週期自動重新抓取，規則集本身的維護完全交給上游，你只需要在 rules 裡引用它的名稱。

三種 behavior，別選錯

定義 Rule Provider 時最容易出錯的就是 behavior 欄位，它告訴用戶端該怎麼解析這份規則集的內容：

• domain —— 規則集內容是純域名清單（每行一個域名，等同 DOMAIN-SUFFIX 語義）；
• ipcidr —— 規則集內容是 IP 段清單（每行一個 CIDR，等同 IP-CIDR 語義）；
• classical —— 規則集內容是完整規則（每行自帶規則型別，格式與 rules 裡手寫的一致，最靈活但檔案體積也最大）。

完整配置範例

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.txt
    interval: 86400

  cn-ip:
    type: http
    behavior: ipcidr
    url: "https://example.com/rules/cn-ip.txt"
    path: ./rules/cn-ip.txt
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,cn-ip,DIRECT
  - MATCH,PROXY

path 是規則集在本機的快取路徑，首次抓取後會寫入這個檔案，之後按 interval（單位秒）自動重新下載覆蓋；即使短暫斷網，用戶端也能先用本機快取的舊版本繼續運作，不會因為一次更新失敗就丟失全部規則。

多個規則集時，順序怎麼安排

規則依然是從上到下逐條比對、命中即停，這一點不會因為換成 Rule Provider 而改變。實務上比較穩妥的順序是：

• 先放廣告／惡意域名封鎖類規則集（如 reject），儘早擋掉不必要的請求；
• 接著放明確需要代理的規則集（如常見海外服務域名清單）；
• 再放本地／區域直連規則集（域名與 IP 段）；
• 最後用 MATCH 兜底，通常走代理，避免新出現的服務因為沒命中任何規則而直接失敗。

更新頻率怎麼定

規則集不需要像節點測速那樣頻繁刷新，多數場景下 interval 設在 12～24 小時（43200～86400 秒）之間即可；更新過於頻繁只會增加規則集伺服器的負擔，並不會帶來實際收益。如果是自己維護的私有規則集，且改動頻率很低，適當拉長到 2～3 天也沒問題。

常見問題排查

接入 Rule Provider 之後，如果發現規則「看起來配了但沒生效」，可以按下面幾個方向逐一排查：

• 規則集抓取失敗 —— 檢查 url 是否能直接在瀏覽器打開，部分規則集託管在特定平台上，在某些網路環境下本身就需要走代理才能存取，形成「先有雞還是先有蛋」的問題，這種情況建議把規則集換成有鄰近鏡像加速站的位址；
• behavior 與內容不匹配 —— 前面提到過，這是最常見的失效原因，一份 classical 格式的檔案如果被宣告成 domain，用戶端會按純域名格式解析，多出來的規則型別前綴反而會被當成域名的一部分，導致規則集整體失效；
• 本機快取過舊 —— 如果懷疑目前用的是很久之前快取的版本，可以直接刪除 path 指向的本機檔案，用戶端下次啟動時會重新觸發一次完整抓取；
• 規則順序被新規則集打亂 —— 新增一個規則集之後，記得確認它插入的位置是否符合「精確規則在前、兜底規則在後」的原則，插錯位置可能會讓後面原本正常運作的規則再也比對不到。

大多數「規則不生效」的問題，最終都能歸結到這四類原因之一，按順序排查一般都能很快定位。想系統性了解規則語法的所有型別，可以看進階配置文件裡的完整參考表。