Rule Provider 實戰：用規則集告別手寫幾百條分流規則

Rule Provider 解決了什麼問題

規則本質上就是一份「網域/IP 到動作」的對照表，社群裡早就有人把常見分類（廣告網域、常用網站、各家串流平台）整理成了公開維護、持續更新的規則檔案。

rule-providers 讓 Clash 可以直接從一個遠端 URL 下載這份規則檔案，並按設定的週期自動更新，你的設定裡只需要引用一次，不需要自己維護成百上千條規則。

三種規則集類型

此外還有 format 欄位決定檔案格式，常見的是 yaml 和體積更小、解析更快的 mrs（mihomo 規則集二進位格式）。

實際設定寫法

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

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - MATCH,PROXY

幾個關鍵欄位：

• interval：自動更新週期（秒），規則集內容會變化，建議設定為一天（86400）左右，不需要太頻繁
• path：本機快取路徑，下載後的規則集會先存到本機，客戶端重啟不需要重新下載
• RULE-SET,名稱,動作：在 rules 裡透過名稱引用某個規則集，動作可以是 DIRECT、REJECT，也可以是某個代理群組名

規則集從哪裡來

規則集不需要自己動手寫，社群裡已經有不少長期維護、按分類整理好的公開專案，涵蓋常用網站直連、廣告攔截、常見串流平台、常見 AI 服務等分類，幾乎是搭建設定檔時的「標配依賴」。選擇規則集來源時，重點看兩點：

• 更新是否活躍：網域和 IP 段一直在變化，幾個月不更新的規則集會逐漸「失準」，可以看倉庫的最近提交時間判斷。
• 分類是否夠細：有的規則集把「常用網站直連」和「廣告攔截」分開維護，方便你按需引用，而不是被迫全部下載一個大而全的規則檔案。

自動更新與手動強制刷新

interval 控制的是 Clash 核心在背景執行期間按週期檢查更新，但它不會在你剛改完設定、重啟客戶端的第一時間強制刷新——如果本機已經快取了規則集檔案（path 指向的那份），核心預設會先用本機快取，等到 interval 週期到了才重新下載。

這在兩種情境下需要特別注意：

1. 剛把規則集位址從 A 換成 B，但 path 沒有跟著改，核心可能還在用舊檔案對應的快取路徑，導致「改了設定卻沒生效」的假象。
2. 規則集維護者剛修復了一個明顯的誤攔截問題，你想立刻用上最新版本，這時候可以直接刪除 path 指向的本機快取檔案，重啟客戶端觸發一次強制重新下載。

大部分帶 Dashboard 面板的客戶端也提供「更新規則」的按鈕，效果等同於手動刪除快取後重啟，日常使用更方便。

規則集 vs 手寫規則：效能怎麼樣

有人會擔心「下載幾萬條規則會不會拖慢比對速度」，實際上核心在載入規則集時會做預處理（比如把網域規則組織成前綴樹結構），單條規則的比對開銷並不會隨著規則集條數線性增加，幾千到幾萬條規則對現代裝置來說幾乎沒有可感知的延遲差異。

真正影響體感速度的，反而是規則的排列順序——命中率高的規則放得越靠前，平均比對次數就越少。這也是為什麼建議把常用的直連規則集放在前面，而不是隨手放在規則列表末尾。

實戰建議

1. 不要同時疊加太多來源不同的規則集，容易出現同一個網域被不同規則集重複判斷、行為不一致的情況，一類需求選一份維護活躍的規則集即可。
2. 規則集出問題（比如誤攔截了正常網站）時，先確認是不是規則集本身的問題，而不是先懷疑自己的設定——可以暫時把某條 RULE-SET 註解掉做排查。
3. 串流解鎖類規則集更新最頻繁（因為平台會不斷調整 IP 段和網域），interval 可以適當設定更短，比如 43200（12 小時）。
4. 定期回顧自己引用的規則集清單，刪掉不再需要的分類，設定檔越精簡，排查問題時越容易定位。

更完整的規則語法和優先權說明，可以回頭看進階手冊的規則引擎章節。