前言：為什麼使用 rule-providers？
當規則數量不多時，直接把 DOMAIN-SUFFIX、DOMAIN 等規則寫在主設定檔的 rules 區塊，簡單又直觀。但隨著服務與例外情況增加，主設定檔很容易變得冗長：規則難以分類，更新時可能誤改其他內容，也不方便在多個設定檔之間共用。
Mihomo 的 rule-providers 可以把一組規則獨立存放，再由主設定檔引用。你可以將工作網站、影音服務、廣告網域或自訂 IP 網段分開管理，並選擇從本機檔案載入，或透過網址定期更新。規則集只負責描述「哪些流量符合條件」，主設定檔則負責將符合條件的流量交給哪個代理群組，兩者分工清楚，也更容易排查問題。
本文會完成什麼
建立可重複使用的 YAML 規則集，連結到代理群組，設定遠端更新，並示範如何用 Git 保留修改紀錄及定位常見錯誤。
先確認核心版本
rule-providers 的支援與可用欄位會依核心而異。請確認客戶端實際使用的是 Mihomo 核心，而不只是看到「Clash」名稱；若設定載入失敗，先查看核心版本與啟動日誌，再檢查 YAML 格式。
1理解規則集類型與資料格式
一個規則提供者通常由名稱、來源類型、匹配行為、檔案路徑，以及遠端更新選項組成。主設定檔中的名稱會被 RULE-SET 規則引用，因此命名時建議使用容易辨認的英文或短字串，例如 work-sites、media-domains，避免同一名稱在多處拼寫不一致。
先選擇 behavior
domain：規則集內容是網域名稱，例如example.com。適合集中管理完整網域或子網域匹配資料。classical：內容是傳統規則項目，例如DOMAIN-SUFFIX,example.com。適合使用多種規則類型，或希望沿用熟悉的規則寫法。ipcidr：內容是 IP 或 CIDR 網段，例如192.0.2.0/24。適合管理 IP 範圍；請確認資料確實是有效網段，而不是網域清單。
behavior 必須與規則集內容相符。把帶有 DOMAIN-SUFFIX 前綴的項目放進 domain 清單，或把純網域名稱當成 classical 規則，都可能造成載入錯誤或匹配結果不如預期。
選擇 YAML 或純文字格式
規則集的 format 常用 yaml；如果規則集採用 Mihomo 支援的二進位格式，也可以依來源格式設定相應值。不要只因副檔名是 .yaml 就認定內容正確：檔案必須符合所選的 behavior，而縮排、列表符號和標點也都要遵循 YAML 語法。
小撇步
初次建立時先使用 classical，可以在每一行清楚看見規則類型和參數；等格式與匹配方式確認無誤，再依需求拆成 domain 或 IP 規則集。
2建立 rule-providers 並連結代理群組
以下範例把工作網站規則放在獨立的遠端 YAML 檔案，定期從 GitHub Raw 位址更新，並讓符合條件的流量交給名為「工作代理」的策略組。請把示範網址中的帳號與儲存庫名稱，替換成你自己實際發布的規則檔網址；同時確認該網址能直接回傳檔案內容，而不是 GitHub 網頁或登入頁面。
這段設定各自負責不同工作：type: http 表示從網路取得規則，url 是來源位址，path 是 Mihomo 儲存或讀取規則的本機位置，interval: 86400 表示以秒為單位安排更新週期，亦即一天。遠端來源無法連線時，先前已下載的檔案是否可用，仍取決於檔案狀態與核心處理情況，因此不要把遠端更新當成備份。
RULE-SET,work-sites,工作代理 中的第二個欄位必須與 rule-providers 下的名稱完全一致，第三個欄位則必須對應一個有效策略或代理組名稱。範例中的 自動選擇 也必須已在設定檔中定義；如果你的設定沒有這個群組，請改成現有群組名稱。MATCH 是兜底規則，應放在需要處理的具體規則之後，因為規則會依序匹配，過早命中兜底規則會讓後續規則沒有機會生效。
撰寫規則集檔案內容
由於範例的 behavior 是 classical，遠端檔案可以使用 YAML 列表保存傳統規則。列表中每個項目各占一行，縮排保持一致：
若改用 behavior: domain，清單應改放該類型要求的網域資料，不要保留傳統規則前綴；若選擇 ipcidr，則應提供對應格式的網段資料。完成後先檢查規則檔本身是否能被正常取得，再把 provider 加入主設定檔。若需要離線使用或不想依賴遠端服務，也可採用本機檔案提供者，並將規則檔放在核心能讀取的位置；本機檔案變更後，仍需要依客戶端功能重新載入設定或規則。
更新週期怎麼選？
不常變動的個人規則可設定較長週期；頻繁維護的清單可縮短更新間隔。過度頻繁的更新不會讓規則匹配更快，反而增加來源伺服器負載，也可能讓網路不穩時更容易遇到更新失敗。
3用 Git 維護規則並快速排錯
把規則檔放進 Git 儲存庫，能保留每次調整的差異與時間點。建議將規則、說明文件和測試記錄分開管理，並在提交訊息中簡述變更原因，例如「新增會議服務網域」或「移除已停用的舊網域」。若某次更新後流量走錯方向，可以透過 Git 比較前後版本，迅速確認是哪一條規則造成影響。
- 建立規則目錄：在儲存庫中建立例如
rules/的資料夾，將不同用途的清單拆成獨立檔案。 - 先在本機驗證：檢查 YAML 縮排、列表結構、規則類型與內容是否吻合，再提交變更。
- 發布並確認網址：取得原始檔案的直連網址，在瀏覽器中確認回應內容是規則檔，而非錯誤頁面。
- 重新載入並觀察：在 Clash Verge Rev 等使用 Mihomo 的客戶端中重新載入設定，查看核心日誌是否成功下載和解析 provider。
使用公開儲存庫時，請勿把訂閱連結、帳號密碼、私人網域清單或其他敏感資訊提交到 Git。即使之後刪除檔案，過往提交紀錄仍可能留下內容。若規則不適合公開，請採用可信任且有存取控制的託管方式，並確認 Mihomo 能取得相應資源。
規則未生效時的檢查順序
- 先看解析錯誤：若設定檔無法載入，檢查錯誤訊息指向的行號與欄位，特別留意冒號、引號、縮排和列表的
-。YAML 只能用空格縮排，不要混用 Tab。 - 核對 provider 名稱：
RULE-SET引用的名稱必須和rule-providers中的鍵完全一致，包括連字號及大小寫。 - 確認策略組存在：目標群組名稱必須出現在代理群組定義中；如果名稱不存在，規則即使匹配成功，也無法交由預期策略處理。
- 檢查規則順序：確認規則集引用出現在兜底規則之前，也沒有被前面的廣泛規則先行匹配。
- 確認來源與格式：測試
url能否直接存取，查看下載日誌，並確認遠端檔案的資料格式符合behavior。 - 分辨規則匹配和節點問題：在客戶端連線或日誌頁面查看實際命中的規則與策略。若已命中正確規則但連線仍失敗，接著檢查群組選擇、節點狀態和 DNS，而不是反覆改寫規則集。
修改後沒有立即變化
遠端檔案更新、provider 載入與主設定檔重新載入是不同步驟。確認檔案已發布後，查看更新時間與核心日誌；必要時手動更新規則集或重新載入設定，不要只以瀏覽器快取中的舊內容判斷。
常見問題
rule-providers 和直接寫 rules 有什麼差別？
直接寫在 rules 中的規則容易閱讀，適合少量且不常變動的項目；rule-providers 則把規則資料與主設定檔分離，方便共用、分類和獨立更新。兩者並非只能擇一，通常可讓固定的少量規則留在主檔，把數量較多或需要定期維護的清單放進 provider。
一定要用 HTTP 遠端規則集嗎？
不一定。遠端來源方便跨裝置維護與定期更新，但需要網路可達，也要管理網址與來源可信度。本機規則集適合自行管理、較少變動或不希望公開的內容。使用本機方式時，請確認檔案路徑相對於實際核心工作目錄的解析位置，並在修改後重新載入。
設定成功，為什麼仍然沒有命中規則？
常見原因包括網域不在清單內、provider 尚未成功載入、引用名稱或代理組名稱不一致，以及規則被前面的項目先匹配。請先在客戶端查看連線記錄中的命中規則，再依序檢查規則順序、實際訪問的網域和 provider 更新狀態。
interval 設得越短，更新就越即時嗎？
interval 控制的是遠端規則集的檢查週期，不會改變每個連線的匹配速度。若規則來源不是頻繁更新，設定過短通常沒有實際好處。選擇與清單更新頻率相符的間隔，並在緊急修改後透過客戶端手動更新或重新載入。
將規則資料、更新來源與流量策略分開管理，是維護自訂規則集最重要的習慣。從少量規則開始，確認 provider 可正常載入、命中結果符合預期，再逐步擴充清單；搭配 Git 留下修改紀錄，日後維護和回退都會容易許多。