用規則集(Rule Provider)管理分流規則,告別手動維護

如果你打開過機場訂閱產生的設定檔,大概見過動輒幾百行的 rules 清單。這些規則大多不是機場自己寫的,而是引用了社群維護的公開規則集(比較知名的有 ACL4SSR、blackmatrix7 系列),規則集本身託管在遠端,設定檔裡只是「宣告引用了哪些規則集」。

規則集解決了什麼問題

沒有規則集之前,想精細控制某個 App 或網站的分流,只能一條條手寫 DOMAIN-SUFFIX / DOMAIN-KEYWORD,而且規則庫需要持續維護(網域會變化、新增服務需要跟進)。規則集把這部分工作轉移給了維護規則庫的社群,你只需要引用,規則內容由遠端檔案自動更新。

三個關鍵欄位

一個完整的例子

rule-providers:
  reject:
    type: http
    behavior: domain
    url: https://example.com/reject.txt
    path: ./ruleset/reject.yaml
    interval: 86400
  direct:
    type: http
    behavior: classical
    url: https://example.com/direct.txt
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  # 引用規則集,寫法固定是 RULE-SET,規則集名稱,策略
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

path 指定本機快取路徑,核心首次拉取規則集後會存一份在本機,之後按 interval 週期性檢查更新,即使暫時斷網也能用本機快取正常工作,不會因為拉取失敗導致規則整體失效。

常見的坑

• behavior 和實際內容不匹配:如果規則集內容其實是完整語法行(如 DOMAIN-SUFFIX,example.com),但 behavior 填成了 domain(只期望純網域),會導致解析失敗或規則不生效。引用規則集之前最好先看一眼來源檔案的實際格式。
• 規則順序放錯位置:規則是按從上到下順序比對的,如果把範圍很寬的規則集(比如一個幾乎符合所有網站的大清單)放在最前面,後面更精細的規則可能永遠不會被比對到。一般建議:攔截規則最先、精細的例外規則次之、寬泛的兜底規則放最後。
• interval 設定得太短:規則集一般不會頻繁變化,沒必要設定成幾分鐘更新一次,那樣只會增加不必要的網路請求,12~24 小時是比較合理的區間。
• 本機檔案路徑衝突:多個規則集如果 path 指向了同一個檔案,會互相覆蓋,建議養成命名規範,比如用規則集名稱本身作為檔案名。

要不要自己維護規則集

對絕大多數使用者來說,直接引用社群維護的公開規則集就足夠了,沒有必要重新造輪子。只有當你有非常具體的個人化需求——比如公司內部系統的網域清單、只有自己在用的一批特殊網站——才值得用 type: file 建一份本機規則集,和公開規則集搭配使用,各自負責不同的部分。

規則集要解決的是「維護成本」問題,不是「功能」問題——普通規則寫法能做的事情,規則集全都能做,只是把維護工作外包了出去。

規則集之間怎麼排列組合

實際使用中,一份設定裡往往會同時引用好幾個規則集,各自負責不同的分類。比較常見的分層方式是:先放攔截類(廣告、追蹤),再放需要走代理的應用分類(比如常見的海外流媒體、社交軟體),然後是國內直連的大清單,最後用 MATCH 兜底。每一層職責單一,出問題時也更容易定位是哪一層規則集導致的。

如果引用的規則集之間出現規則重疊(比如兩個規則集都包含同一個網域,但指向了不同策略),實際生效的永遠是排在前面、先被比對到的那一條。所以規則集的引用順序本身也是一種優先級宣告,調整順序有時候比修改規則集內容更快能解決問題。

怎麼驗證規則集是否生效

設定好規則集後,不需要靠猜測判斷有沒有生效。前面文章提到的控制面板裡,「連線」視圖會顯示每條連線實際命中的規則名稱——如果顯示的是某個規則集的名字而不是「未匹配」,就說明規則集已經正常工作。這是排查規則問題時最直接、最省時間的方法,比反覆修改設定再測試要有效率得多。