一、rule-providers 在做什麼？與 proxy-providers 分別
在 Clash Meta 系譜（含桌面端的 Mihomo 核心與多數標榜 Meta 相容的用戶端）裡，設定檔頂層常見兩種「遠端資料來源」：proxy-providers 負責拉節點清單（訂閱內容多半是代理伺服器描述），而 rule-providers 負責拉規則資料——可能是網域名單、IP 段、或經過轉換器整理過的規則片段。兩者語意不同：換節點無法代替換規則集；若你把規則集的 raw 連結塞進節點訂閱，解析器會期待另一種格式，結果往往是列表為空或報錯，這類情境可對照本站 訂閱解析與 Provider 快取 專文。
rule-providers 的典型用途，是把社群維護、頻繁更新的網域／GEOIP 規則與你自己寫的精簡規則拆開：本地只保留策略組、少數自訂規則與對 provider 的引用；大宗匹配改由遠端規則檔提供。這樣做的好處是維護成本低，且能用 interval 控制自動重新整理頻率；代價是你必須信任規則來源並留意下載失敗時的行為（例如沿用上次快取）。
proxy-providers 餵給「節點池」；rule-providers 餵給「規則引擎」。規則鏈裡出現的 RULE-SET，指向的是後者的鍵名，而不是訂閱 URL 本身。
二、撰寫 rule-providers 區塊（type、behavior、url）
在設定檔 Root 層級新增 rule-providers:（與 proxies:、rules: 同層），其下每一個鍵名（例如 reject-ad:）都是你日後在 rules: 裡 RULE-SET 要指到的識別碼。每個 provider 物件至少需要讓核心知道：資料從哪來（常見為 type: http 搭配 url:）、以及規則語意對應哪種解析方式——這由 behavior 描述（例如 classical、domain、ipcidr 等，實際可用取值請以你所使用核心版本文件為準，避免複製過舊論壇片段）。
下列為結構示意，網址與檔名請替換成你要使用的規則集；註解一律為英文以利版本控制工具閱讀。
rule-providers:
community-domains:
type: http
behavior: classical
url: "https://example.com/rules/classical.yaml"
path: ./ruleset/community-domains.yaml
interval: 86400重點有三：第一，behavior 必須與遠端檔案的規則型別相符，錯配時可能載入成功但匹配異常或開機報警告。第二，url 必須回傳核心支援的規則集格式（多數社群規則會註明適用 Clash／Meta／Mihomo）。第三，鍵名請用ASCII、有意義且不重複的字串，避免與策略組或其他區塊同名造成閱讀混亂。
rule-providers 鍵，後載入者可能覆蓋前者；建議在編輯器全域搜尋鍵名，並以「單一真相來源」整理 patch。
三、path 本地路徑與 interval 自動更新
path 指定規則集快取檔在設定檔工作目錄底下的相對位置（實際基準目錄依用戶端而異：可能是設定檔所在資料夾、應用程式支援目錄或沙盒容器內路徑）。填寫 path 的實務好處包括：你能直接在檔案管理員或終端機確認是否真的下載成功、檔案大小是否異常、必要时也可暫時用手動覆蓋做 A／B 測試。若未指定，部分環境仍會自動命名快取，但除錯時較難對應「現在生效的是哪一份」。
interval 以秒為單位，描述核心自動重新抓取該規則集的間隔。設定過短會造成對上游伺服器的頻繁請求，某些公開規則倉庫會對過度抓取限速或直接拒絕；設定過長則在你需要跟上新網域／新 CDN 時顯得遲鈍。實務上一天一次（86400）是常見起點；若規則維護者建議更新頻率，優先遵循官方說明。若你常在行動網路或計費網路下更新，也可拉長間隔並改以手動「更新規則／重新載入」為主。
| 你的情境 | path／interval 怎麼取捨 |
|---|---|
| 只想穩定分流、規則變動不急 | interval 偏長（例如 86400 以上）；path 固定檔名以便備份 |
| 規則來源更新非常頻繁且可信 | 可縮短間隔，但請確認上游允許頻率；並留意用戶端是否在休眠時仍會喚醒更新 |
| 常遇到規則 raw 偶發 403／timeout | 保留可用快取比盲目縮短間隔更重要；同時檢查是否需要鏡像 URL 或替換為本地鏡像檔 |
與 GEOIP 或國別分流搭配時，請記得規則資料與 GEOIP 資料庫版本是兩條線：前者多在 rule-providers 或內建資料更新流程裡處理；後者涉及 geodata-mode、資料檔路徑與是否使用路由規則中的 GEOIP 類型。若你正在調境內網站走直連這類策略，可延伸閱讀 GEOIP 與直連規則 一文，避免只更新規則集卻忽略資料庫落後。
四、在 rules 以 RULE-SET 引用並對齊順序
載入 rule-providers 後，規則並不會自動生效——你必須在 rules: 陣列中加入對應條目。Meta 系譜使用 RULE-SET 關鍵字時，第一個參數通常是 provider 的鍵名，第二個參數是匹配後要採用的策略（例如某個 proxy-groups 名稱、DIRECT、REJECT 等）。規則鏈由上而下評估，先命中先結束；若你把大包規則集放在太下方，可能被前面的 GEOIP、MATCH 或較寬鬆規則提早截斷。
rules:
- RULE-SET,community-domains,YourProxyGroup
- GEOIP,CN,DIRECT
- MATCH,YourProxyGroup上述片段僅示意思考順序：社群規則集優先於國別預設直連，最後才落入全域匹配。實務上你可能會在規則集之前插入區域網、本機或特定進程相關條目；請依自身網路拓扑調整。也要確認 YourProxyGroup 確實存在於 proxy-groups:，且組內有可用的 proxies，否則會出現策略指向空組或連線失敗——這與「規則集是否載入」是不同層次的問題。
五、載入後驗證與常見錯誤
- 套用並重新載入：在桌面或行動端用戶端執行「套用」「重啟核心」或等同操作；若使用外部控制器觸發 reload，請確認回應為成功而非部分套用。
- 檢查本地 path：觀察
path對應檔案是否生成、時間戳是否更新；若檔案為空或大小異常，先對url做瀏覽器或curl測試是否在該網路可得。 - 閱讀日誌：搜尋規則 provider 鍵名或下載錯誤關鍵字（timeout、TLS、certificate 等）；TLS 與時間錯誤常見於企業網路中介憑證環境。
- 規則命中對照：使用客戶端提供的連線紀錄／規則命中面板（若有），對同一目標網域或 IP 觀察是否符合預期策略；若始終走到兜底，回到上一節檢查順序與鍵名。
- 漸進式修改：一次只改一個 provider 或一條規則位置，保留上一份可用設定備份，避免多變因數疊加後難以回溯。
若你同時在調整 DNS、fake-ip 或 TUN 模式，請記住：規則命中與解析鏈路透上是不同子系統；規則集寫對了，仍可能因 DNS 回傳或模式設定看起來「像沒分流」。需要時可並行閱讀 DNS nameserver 與 fallback 設定文，把兩邊變因拆開驗證。
六、常見問題
rule-providers 的 path 一定要填嗎？
強烈建議填寫。path 讓快取檔位置可預期，有利除錯、備份與比對版本；也方便你在離線或上游故障時暫時放入已知良好的規則檔。
interval 設多少比較合適？
常見從數小時到一天不等；重點是平衡規則新鮮度與對上游禮貌。若你不確定，採規則來源文件的建議值，或先用較長間隔配合手動更新。
RULE-SET 寫了卻像沒生效？
依序檢查：鍵名是否一致、behavior 是否與檔案格式相符、規則順序是否被更早的規則截斷、策略標籤是否存在且有可用節點。必要時暫時把可疑規則前移做對照實驗。
可以用本地檔案而不走 http 嗎？
部分版本支援以檔案型 provider 或等價欄位載入本地規則（依核心文件為準）。若環境允許，將規則檔納入你可控的目錄並由設定引用，可減少對第三方 raw 連線的依賴。
七、小結與延伸閱讀
Clash Meta／Mihomo 的 rule-providers 把「規則資料」從主設定檔中拆出來，靠 url 與 interval 維持更新，並用 path 讓快取可見、可備份；真正讓分流發生的是 rules: 裡的 RULE-SET 與整條規則鏈的順序與策略標籤。把這幾件事分開理解後，多數「規則載入了但體驗不變」的案例都能收斂到：鍵名錯置、behavior 錯配、順序被截斷，或策略組本身無可用出口。
相較僅依賴單機手刻規則或零散複製片段的做法，成熟的規則集生態能顯著降低維護成本；但若工具本身對Meta 語法、provider 快取與圖形化除錯支援不足，使用者仍會在 YAML 與日誌之間來回耗時。這也是許多人最終仍偏好跨平台一致、規則與訂閱模型清楚的 Clash 系用戶端的原因——同一套概念從桌面延伸到行動裝置，減少每次換機都要重新摸索供應商自訂格式的摩擦。