Rule Providers 解決了什麼問題？
在 Clash 系核心（含 Mihomo／前身 Clash Meta）裡，rules 區段決定每一筆連線要直連、走哪個代理策略組，或拒絕。當你想依網域、關鍵字、IP 區段做細緻分流時，規則條目很容易膨脹到數千甚至數萬行；全部塞進單一 config.yaml 不僅難以閱讀，也不利於與社群維護的規則集同步更新。
Rule Provider（規則提供者）的本質，是把某一類規則打包成「具名資源」：核心會依你指定的來源（常見為 HTTP／HTTPS 網址或本機路徑）載入內容，快取在本地，並可按 interval 自動重新整理。接著在 rules 裡用 RULE-SET 一行的方式引用整包規則，就能維持主設定檔精簡，同時享受社群或專案方持續更新的網域清單。
若你剛開始接觸 Clash 的欄位結構，建議先搭配站內使用文件把 proxies、proxy-groups 與基礎 rules 跑通，再進入本文的 Provider 進階段落，學習曲線會平順許多。
rule-providers 區段：必要欄位與行為型別
在設定檔頂層新增 rule-providers，其下每一個鍵名即為一個提供者 ID，之後在 rules 中會用到這個名字。典型寫法如下（網址為示意，請替換為你信任且可長期存取的來源）：
rule-providers:
community-classical:
type: http
behavior: classical
url: "https://example.com/rules/classical.yaml"
path: ./ruleset/community-classical.yaml
interval: 86400
ads-domain:
type: http
behavior: domain
url: "https://example.com/rules/ads.txt"
path: ./ruleset/ads-domain.yaml
interval: 43200
cn-ip:
type: http
behavior: ipcidr
url: "https://example.com/rules/cn.txt"
path: ./ruleset/cn-ip.yaml
interval: 86400幾個必須釐清的觀念如下。type 為 http 時，核心會下載遠端內容並寫入 path 所指的本地檔案路徑（相對於設定檔目錄或程式工作目錄，依用戶端實作為準）。interval 以秒為單位，代表自動更新的間隔；若設為 0 或省略，行為可能變成僅手動觸發更新，實際細節請以你所用的核心版本說明為準。
behavior 決定該規則集內每一行要如何解讀，也影響比對效能與可讀性：
- classical：檔案內容格式接近一般
rules清單，可混合DOMAIN、DOMAIN-SUFFIX、IP-CIDR等條件（實際支援集合仍以核心文件為準）。適合需要與手寫規則一致語意的情境。 - domain：每一行通常視為網域或後綴清單，由核心建構網域類資料結構以加速查找，適合廣告攔截、CDN 或大型網域表。
- ipcidr：以 IP 區段為主，適合處理地理或機房匯總的 CIDR 清單，常與「國內直連／其餘代理」這類策略並用。
選錯 behavior 是最常見的設定錯誤之一：例如把實際為「純網域清單」的檔案標成 classical 卻未使用對應語法，或把含前綴規則的檔案誤設為 domain，都可能造成載入失敗或規則完全不生效。下載後若用戶端提供「規則預覽」或除錯日誌，務必確認第一版載入是否成功。
在 rules 裡引用：RULE-SET 與策略名稱
定義好 rule-providers 後，在 rules 區段以 RULE-SET 將整包規則對應到某個策略（代理組名稱或 DIRECT／REJECT 等）。列舉順序與一般規則相同：由上而下，先命中者優先。
rules:
- RULE-SET,ads-domain,REJECT
- RULE-SET,cn-ip,DIRECT
- RULE-SET,community-classical,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY上述範例展示一種常見的意圖：先擋廣告網域、再讓特定 IP 區段直連、其餘由社群規則集決定是否納入代理，最後以 GEOIP 與 MATCH 收尾。實務上你應依自己的訂閱節點名稱調整 PROXY 為實際策略組（例如 Auto、Proxy），並避免與訂閱自動產生的同名規則互相衝突。
若同時使用內建 GEOSITE／GEOIP 與外部 RULE-SET，請記住：兩者都是「規則列表中的一行」，並沒有誰天生比較優先，完全取決於你在 rules 中的排列順序。想把某批網域固定直連，就把對應的 RULE-SET,...,DIRECT 放在較上方；希望訂閱商附帶的特殊規則先生效，就要理解訂閱合併後實際插入的位置——許多 GUI 會提供「規則編輯器」或「訂閱／自訂規則先後」選項，錯一步就會出現「明明寫了直連卻仍走代理」的現象。
精準分流的實務組合思路
「精準分流」不是單一開關，而是資料來源（哪些網域／IP 屬於哪一類）與策略選擇（直連、代理、拒絕、不同節點組）兩件事的乘積。Rule Providers 負責讓前者可更新、可模組化；後者則仍仰賴你對 proxy-groups 的設計，例如自動測速、容錯切換、依用途分組（串流、工作、遊戲）等。
實務上可採用「由嚴到鬆」的分層：先處理確定要拒絕或確定要直連的集合，再處理需要特定出口的媒體或金融網域，最後才用較寬鬆的 GEOIP 或 MATCH 收斂。這樣即使某個第三方規則集偶爾誤判，影響範圍也較容易侷限在你刻意留出的「兜底」層級之前。
另一個常見需求是與 DNS 模式協調。當你使用 fake-ip 或細緻的 dns 分流時，規則命中與解析路徑會互相牽連；若出現「網站打得開但影片無法播放」或「解析到錯誤地區 CDN」，不一定是規則集壞掉，而可能是 DNS 與規則先後不一致。此時可延伸閱讀本站DNS 防洩漏與設定指南，對照調整會省很多試錯時間。
更新節奏、來源信任與風險控管
Rule Providers 的便利之處在於自動更新，但這也代表：你的用戶端會定期從外部 URL 取得內容並套用。若來源遭竄改、導向惡意重新導向，或規則誤把大量正常流量導向不當策略，影響面可能很大。建議至少做到以下幾點：
- 只使用你可稽核來源：優先選擇有公開版本控管、更新紀錄清楚的專案；避免在設定檔中硬寫來路不明的短網址。
- 分段測試再縮短 interval：新加入的規則集先以較長間隔或手動更新觀察一日，確認無誤再調整自動更新頻率。
- 保留本地備份：對關鍵的
path檔案定期備份；當遠端暫時不可用時，至少仍能載入上一份可用版本。 - 留意合規：請依所在地法律與服務條款使用網路與代理工具；技術教學僅供合法用途下的網路設定參考。
與「下載用戶端」相同，取得安裝包請以可信賴的官方或本站發行頁為主；若需查核開源授權或上游專案動態，可另行前往 GitHub 等頁面，但不宜與日常「一鍵安裝」混為同一入口。本站下載頁提供依平台整理的用戶端取得方式，較利於一般使用者維持版本一致。
常見問題與除錯順序
規則集載入後完全沒效果？
先確認 path 對應檔案是否已實際產生、檔案大小是否合理；再確認 behavior 與檔案內容格式是否相符；最後在 rules 中檢查 RULE-SET 名稱是否與 rule-providers 鍵名完全一致（大小寫敏感）。若前面已有 MATCH 或其他寬規則先命中，後面的 RULE-SET 永遠不會執行到。
更新後某網站突然異常？
以「最近是否更換規則集版本／縮短 interval」為線索，暫停自動更新或還原上一版檔案比對；必要時把該網域暫時寫入手動規則置於較前段，待釐清後再移除。也可檢查是否與訂閱內建的規則重疊，造成策略被覆蓋。
效能變差或記憶體升高？
規則條目過多會增加比對成本；可評估合併重複集合、改選更適合的 behavior，或刪減不再使用的 Provider。若同時啟用多個巨型規則集，建議觀察用戶端提供的效能相關說明，必要時改以較精簡的清單達成同樣策略目標。想從整體設定角度提速，可一併參考Clash 提速實用技巧一文。
寫在最後
學會 Rule Providers 之後，你等於把 Clash／Mihomo 的分流能力從「手抄規則」升級成「模組化維護」：主設定檔保留節點、策略與排序邏輯，細碎的網域與 IP 清單交給可信來源迭代。這種結構不僅較容易除錯，也更適合在不同裝置之間同步同一套策略骨架。
相較於手動拼湊零散教學，使用經過相容性驗證、內建較新核心與合理預設的用戶端，通常能減少 YAML 版本差異與 GUI 行為不一致帶來的挫折。若你希望在桌機與行動裝置之間維持相近的分流體驗，不妨從本站下載頁取得對應平台版本，先以預設規則跑穩，再逐步導入本文章的 Provider 模組。