為什麼把自訂規則獨立託管：rule-providers 能解決什麼問題

如果你曾經在訂閱設定檔裡直接新增一長串網域規則，應該很熟悉這種維護困境：規則混在節點、策略群組與其他設定之間，更新時容易改錯位置；換用另一份訂閱後，手動新增的內容可能消失；想回頭查某條規則何時加入，也得在整份 YAML 裡搜尋。Mihomo 的 rule-providers 可以把規則清單放在獨立檔案，再由主設定檔引用。日後只要更新託管在 GitHub 的清單，客戶端便可依設定週期重新取得內容，主設定檔不必每次跟著大幅修改。

這種做法適合希望分開管理規則內容與代理策略的人。例如你可以將工作網站、開發工具或自家服務的網域放在一份規則清單裡，主設定檔則負責決定命中後走哪個策略群組。規則清單說明「哪些連線符合條件」，主設定檔的 RULE-SET 則說明「符合後要交給哪個策略」。兩者職責清楚分開，之後調整節點名稱或策略群組時，通常不必重寫整份網域清單。

先確認你使用的核心支援 rule-providers。Clash Verge、Clash Verge Rev 等圖形客戶端的功能取決於實際載入的核心與設定方式；使用不同版本、不同核心或受管理的遠端設定時，欄位支援可能不完全相同。下文以 Mihomo 常見的 HTTP 型規則提供者為例，示範 GitHub 公開儲存庫的使用方式。若你的用戶端使用自訂覆寫或訂閱合併功能，請先確認規則要加在哪一層，避免直接修改每次更新都會被覆蓋的訂閱原檔。

  • 主設定檔：保留核心設定、代理策略，以及引用規則提供者的順序。
  • GitHub 規則檔：集中保存需要維護的網域或完整規則，讓修改紀錄能透過提交歷史追蹤。
  • Mihomo 核心：依照 url 下載規則檔、按 interval 定期更新，並在規則鏈中套用它。

要特別分清楚「自動更新規則」與「自動切換節點」是兩回事。rule-providers 更新的是規則資料，不會自行替你選擇速度最快的代理，也不會改變訂閱中的節點內容。若更新後連線路徑不同，原因通常是規則清單變更、規則順序命中不同，或目標策略群組本身的設定改變。

建立 GitHub 規則檔：先選對格式與更新來源

開始前，先建立一個專用儲存庫或使用已有的規則儲存庫，並決定哪些檔案可以公開。規則檔通常不需要放入帳號密碼、訂閱網址、節點資訊或其他憑證；即使儲存庫目前設為私人，也不要把敏感資料當成一般規則內容提交。Mihomo 需要能讀取規則檔的 HTTP 或 HTTPS 網址，私人 GitHub 儲存庫的原始檔連結通常無法直接讓核心完成匿名下載，因此初次設定可使用公開儲存庫，或改用你已設定好存取方式的可信任託管服務。

以公開儲存庫為例，將規則檔放在容易辨識的路徑，例如 rules/my-services.yaml。在 GitHub 頁面打開該檔案後，使用「Raw」取得原始內容網址；網址通常會包含帳號、儲存庫、分支名稱與檔案路徑。不要把儲存庫首頁網址、檔案瀏覽頁網址或下載按鈕所在頁面當成規則 URL，否則核心取得的可能是 HTML 頁面，而不是 YAML 內容。將 Raw 網址貼入瀏覽器，確認顯示的是你預期的規則文字，再放進主設定檔。

選擇規則行為時，要依檔案內容決定 behavior，不要只看副檔名。若清單只列網域，使用 domain 行為；若每一行是 DOMAIN、DOMAIN-SUFFIX 或其他完整 Clash 規則，則應使用 classical。例如，簡單網域清單可以這樣寫：

payload:
  - '+.example.com'
  - '+.example.net'
  - 'api.service.example.org'

這個檔案最外層使用 payload，清單項目是網域或網域模式，不是完整的策略規則。若你需要精確區分單一主機、網域後綴、IP 網段或網域關鍵字，則可將檔案改成完整規則，並採用 classical 行為，例如：

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,example.net
  - DOMAIN-KEYWORD,dev-portal

domain 清單較適合只維護網域集合的情況，格式精簡，也不會把策略選擇混入規則檔；classical 則較適合需要多種規則類型或精細比對條件的情況。不要把兩種格式的項目混在同一份清單裡，再期待核心自動辨認。若你的核心版本要求特定格式欄位，應以該版本文件為準，並在載入前先驗證 YAML 縮排與規則語法。

在主設定檔引用規則：欄位用途與順序

規則檔準備好之後，在主設定檔的頂層加入 rule-providers，並在 rules 中使用同一個提供者名稱。下例假設 GitHub 儲存庫名稱為 my-clash-rules，規則檔位於 rules/my-services.yaml；請將帳號、儲存庫、分支與策略名稱換成自己的實際值。

rule-providers:
  my-services:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/your-name/my-clash-rules/main/rules/my-services.yaml"
    path: ./ruleset/my-services.yaml
    interval: 86400

rules:
  - RULE-SET,my-services,Proxy
  - MATCH,DIRECT

每個欄位都有不同用途，寫入前可以逐項核對：

欄位 用途 設定時要確認
my-services 提供者名稱，也是 RULE-SET 引用時使用的識別名稱。 兩處拼法必須完全一致；名稱可自行取用，但避免空格與難以辨識的縮寫。
type 指定規則提供者的取得方式；此處使用 HTTP 型來源下載遠端檔案。 URL 必須能從執行 Mihomo 的裝置連線，並回傳規則檔內容。
behavior 指定清單是網域清單或完整規則集合；例子中的 domain 對應網域格式。 須與檔案內的項目類型一致；完整規則清單應採用相符的行為。
format 說明來源檔案格式；範例使用 YAML。 檔案內容、格式宣告和核心版本的支援情況應一致。
url 規則檔的遠端下載位置。 應使用可直接取得原始文字的 HTTPS URL，並再次確認分支與路徑正確。
path 核心在本機保存下載規則的路徑。 依目前設定檔與核心的檔案存取方式指定；不要誤以為這是 GitHub 上的路徑。
interval 遠端規則的更新間隔，數值以秒為單位。 86400 代表 24 小時；頻率應符合規則更新需求與來源服務的合理使用方式。

rules 區塊中的 RULE-SET,my-services,Proxy 會讓命中這份規則的連線交給名為 Proxy 的策略或策略群組處理。策略名稱必須存在於你的設定中，且要與名稱完全相同。若你使用的是其他名稱，例如 自選節點，就要將規則第三個欄位一起改成該名稱。範例最後的 MATCH,DIRECT 只是表示未命中前面規則時的預設處理方式，實際配置應沿用你的既有策略。

規則的先後順序也很重要：Clash 會依序檢查規則，遇到第一條符合的規則就採取相應處理。因此，如果前面已有更廣泛的網域或地理位置規則，新增的 RULE-SET 可能永遠沒有機會命中。通常應把需要優先控制的自訂規則放在較寬泛規則之前，同時保留原有的最終匹配規則。完成後，檢查 YAML 縮排、冒號與清單破折號；縮排錯誤可能導致整份設定無法載入，而不是只有這個提供者失效。

部署與驗證：從 GitHub 提交到確認實際命中

建議採取「先驗證檔案，再更新客戶端，最後確認連線」的順序。先在 GitHub 上檢查變更內容，確定只有預期的規則被加入或移除，再提交到預定分支。之後使用 Raw 網址確認遠端檔案已反映最新內容；若剛提交但網址仍顯示舊版，先確認分支、檔案路徑與提交是否正確，也要留意快取造成的短暫延遲。不要在尚未確認 Raw 內容前，就把問題歸咎於 Clash 的更新功能。

  1. 確認格式：檢查規則檔是有效 YAML，並確認 payload 下的每個項目符合所選的 behavior。檔案應只放規則資料，不要把 GitHub 網頁的導覽文字或 HTML 一起複製進去。
  2. 檢查遠端可讀性：在瀏覽器開啟設定中的 url，確認網址使用 HTTPS，且回應內容與預期規則相符。若跳到登入頁、顯示 404 或回傳 HTML，先修正來源網址與儲存庫權限。
  3. 備份並修改主設定：編輯前保存目前可正常載入的設定檔副本，再新增提供者與對應的 RULE-SET。若使用訂閱覆寫機制，請依客戶端支援方式加入，不要直接修改會被訂閱更新覆蓋的原始檔。
  4. 重新載入設定：使用客戶端提供的設定檢查、重新載入或更新功能。若出現 YAML 解析錯誤，先恢復備份，再逐項檢查縮排、冒號、引號和欄位位置。
  5. 確認提供者狀態：查看客戶端的規則提供者、連線記錄或核心日誌，確認提供者已載入且最近更新成功。介面名稱會因版本不同而異，必要時搜尋「規則提供者」或 rule-providers。
  6. 測試實際流量：連線到清單中一個可辨識的網域，再查看連線記錄中的命中規則與策略名稱。單看設定檔沒有報錯，並不能證明實際流量一定命中了這份清單。

若你想驗證更新週期，可先在 GitHub 規則檔新增一個可安全測試的網域，確認遠端內容更新後，再觀察提供者是否取得新資料，以及連線紀錄是否顯示相應的規則。不要用會影響工作或安全性的重要網域做第一次測試，也不要在測試時一次更動大量規則，否則很難區分問題究竟來自更新、匹配條件還是策略本身。測試完成後，移除臨時項目並重新確認 GitHub 上的正式清單。

如果有多個裝置共用同一份規則，可以先在一台測試裝置上驗證，再部署到其他客戶端。不同裝置可能使用不同的 Mihomo 版本、核心設定與檔案路徑；即使 GitHub 來源一致，也不代表各端會以完全相同方式解析。把規則檔的變更內容、測試網域、提交時間與核心版本一併記錄，後續遇到差異時會比只記得「昨天改過設定」更容易追查。

更新失敗與日常維護：用症狀縮小排查範圍

規則沒有生效時，先判斷是哪一段出問題：核心是否成功下載、規則檔是否解析、規則是否命中，以及命中後策略是否正確。這四個環節彼此獨立，只重複按「更新訂閱」不一定能解決問題。以下表格可作為排查順序：

看到的狀況 優先檢查 建議處理方式
提供者下載失敗或逾時 核心所在裝置的網路、Raw URL、GitHub 連線，以及儲存庫是否公開。 從同一裝置測試 URL；確認沒有登入導向或 DNS、代理路由問題，再手動觸發更新。
回應成功但規則無法解析 檔案是否為預期內容、YAML 縮排、behavior 與規則格式是否相符。 檢查原始檔而非 GitHub 瀏覽頁；修正格式後先在測試設定中載入。
設定載入成功，但連線沒有命中 RULE-SET 名稱、目標網域是否在清單內，以及規則前方是否有更早命中的規則。 查看連線紀錄中的實際目的地與命中規則，確認測試的網域確實符合清單條件。
已命中，但流量走錯策略 RULE-SET 第三欄的策略名稱，以及該策略群組目前選擇的節點。 核對名稱拼字與群組狀態；區分「規則命中正確」和「代理出口符合預期」兩件事。
手動更新後正常，之後沒有自動更新 interval、客戶端是否持續執行、核心日誌與更新來源是否可用。 確認更新間隔以秒計算，並在客戶端保持啟動後觀察下一次更新狀態。
客戶端更新後自訂設定消失 是否直接修改訂閱產生的檔案，以及目前啟用的是哪份設定。 改用客戶端支援的覆寫、合併或自訂設定方式，並保留可復原的備份。

日常維護時，避免只在 GitHub 上覆寫一份不留紀錄的檔案。使用清楚的提交訊息，例如說明新增或移除哪個網域、調整原因與測試結果；如果新規則造成誤分流，便能透過提交歷史找回先前內容。若希望每次修改都經過檢查，可先在分支測試，再合併到客戶端使用的分支。這比直接在正式規則清單中一次更動大量項目更容易控制影響範圍。

也要定期清理不再使用的規則，並確認網域清單沒有過度擴張。過度寬泛的網域後綴可能讓原本應直連的服務也被送往代理；重複或相互矛盾的規則則會增加排錯難度。規則資料只應涵蓋有明確需求的網域，並依實際連線紀錄驗證。若其他人也能修改公開儲存庫，應將規則來源視為設定供應鏈的一部分：審查每次變更，限制不必要的寫入權限，並避免使用來源不明、無法確認維護者的清單。

與把所有規則手動塞進單一訂閱檔相比，GitHub 託管能保留清楚的修改紀錄、方便回復，也讓規則更新不必每次重寫整份 Clash 設定；與只靠固定網域清單的簡單代理工具相比，Mihomo 的規則提供者還能讓清單與策略群組分工，並透過連線記錄確認實際命中情況。如果你希望在桌面端更直覺地管理設定、檢查連線並逐步維護自訂規則，可以依自己的系統選擇合適的 Clash 客戶端。

立即免費下載 Clash，開啟流暢上網新體驗 →