Clash 自訂規則集實戰：GitHub 託管與 rule-providers 維護

為什麼要把規則拆成 rule-providers？

當分流規則只有幾條時，直接把規則寫在主設定檔的 rules 區塊，通常最容易理解。但隨著規則增加，主檔會混在一起放入節點、策略群組、DNS 與大量域名條目，修改時不易確認影響範圍，也容易在匯入訂閱或調整設定時不小心覆蓋自訂內容。Mihomo 的 rule-providers 可以將一組規則存放在獨立檔案，再由主設定檔引用，讓「規則內容」與「流量要交給哪個策略組」分開管理。

對管理 AI 服務、開發工具或團隊內部網域的使用者來說，這種拆分特別實用。您可以為 AI 網站建立一份規則集，為程式碼託管平台建立另一份，再在主設定檔中統一決定它們要走哪個策略組。日後新增域名時，通常只需修改對應的規則檔，不必反覆編輯整份主設定檔；多人協作時，也能透過 GitHub 的提交紀錄查看改動內容與時間。

需要先釐清的是，規則集只負責「哪些連線符合條件」，並不會自行建立代理節點或策略群組。RULE-SET 命中後，Mihomo 仍會把流量交給規則行尾指定的策略組。因此，完整設定至少包含三個彼此配合的部分：遠端或本機規則檔、主設定檔中的 rule-providers 宣告，以及 rules 中引用規則集的條目。

先建立清楚的分工

建議讓每個 provider 對應一個用途，例如 ai-services、developer-tools 或 work-domains。一開始不必把所有網域塞進單一巨大清單；分類明確，日後才能判斷問題是規則內容、更新來源，還是策略組選擇錯誤。

先整理規則檔與 GitHub 託管方式

建立規則檔前，先決定規則提供者的 behavior。常用的 domain 適合放純網域或網域後綴；ipcidr 用於 IP 位址與網段；classical 則可放入完整的傳統規則，例如 DOMAIN-SUFFIX、DOMAIN-KEYWORD 或 IP-CIDR。同一份 provider 應維持一致且符合所選類型，否則可能出現載入失敗，或規則語法被錯誤解讀的情況。

以需要混合多種域名匹配方式的情境為例，可以使用 classical，並把內容存成 YAML。規則清單放在 payload 之下，每一條都是字串；縮排要一致，冒號、逗號與引號也要使用有效的 YAML 格式。

payload:
  - DOMAIN-SUFFIX,openai.com
  - DOMAIN-SUFFIX,chatgpt.com
  - DOMAIN,api.example.dev
  - DOMAIN-KEYWORD,developer-portal

接著在 GitHub 建立一個專門存放規則的 repository，例如使用 rules/ai-services.yaml 作為檔案路徑。repository 可以設為公開，讓 Mihomo 透過 HTTPS 讀取；提交前請檢查檔案內容，而不是只確認 GitHub 頁面能正常顯示。對公開規則而言，任何人都可能讀取內容，因此不應放入訂閱連結、帳號識別資訊、內部主機名稱或其他機密資料。

原始檔網址一般採用 raw.githubusercontent.com 的格式，網址中需要包含擁有者、repository、分支名稱與檔案路徑。分支名稱用 main 等實際存在的名稱，路徑大小寫也必須與 GitHub 中的檔案完全一致。若直接追蹤主要分支，提交新版本後，Mihomo 下次更新會取得最新內容，適合需要持續維護的規則；若要降低上游變動帶來的意外，可改用特定 commit 對應的固定網址，並在測試後再更新引用。

不要把「網址可開啟」當成規則已生效

瀏覽器能看到 GitHub 檔案，只能證明該網址目前可讀取，不能保證核心能解析格式、provider 已成功載入，或規則已被實際命中。後續仍須在 Mihomo 日誌與連線記錄中確認更新結果和匹配路徑。

在 Mihomo 設定 rule-providers 與自動更新

在主設定檔加入 provider 宣告。以下示例以 classical 規則集為例；請將網址、快取路徑與策略組名稱替換成自己的值。path 是核心儲存規則檔的本機位置，使用相對路徑時會相對於 Mihomo 的工作目錄；若客戶端會管理設定檔或核心資料目錄，請確認該路徑所在位置可寫入，而且設定檔更新後不會被客戶端清除。

rule-providers:
  ai-services:
    type: http
    behavior: classical
    url: "https://raw.githubusercontent.com/OWNER/REPOSITORY/main/rules/ai-services.yaml"
    path: ./rules/ai-services.yaml
    interval: 86400

rules:
  - RULE-SET,ai-services,AI-Proxy
  - MATCH,Final

interval: 86400 代表以秒為單位的更新間隔，也就是約一天一次。更新間隔不宜設得過短：頻繁請求不會讓規則匹配得更精準，反而增加外部來源的請求次數，也可能在網路不穩時反覆產生更新錯誤。若規則變更不頻繁，一天或數天更新一次通常較易維護；重要規則剛完成修改時，則可在客戶端手動更新 provider，無須等待下一個週期。

上例的 AI-Proxy 必須是已存在的策略組名稱，且拼字、大小寫與主設定檔完全一致。若您的設定使用不同名稱，例如 AI服務 或 Proxy，就要同步修改 RULE-SET 行尾的目標。provider 名稱 ai-services 則是主設定檔內的識別名稱，必須與 RULE-SET 引用的名稱相同；它不必與 GitHub 檔名相同，但採用容易辨認的命名方式會更方便檢查。

規則通常由上而下匹配，命中後便採用該條指定的策略。因此，特定用途的 RULE-SET 應放在可能攔截相同流量的寬泛規則之前。例如，若前面已經有涵蓋大量網域的規則，AI 網域可能先被那條規則送往其他策略，後面的 AI provider 就不會發揮作用。也請檢查最後的 MATCH 等兜底規則：它應位於一般規則之後，而不是排在自訂 provider 前面。

套用前的檢查順序

確認 YAML 的層級縮排正確，rule-providers 和 rules 都位於設定檔根層級。
確認 type、behavior、url、path 與 interval 位於同一個 provider 區塊內。
確認 provider 的名稱與 RULE-SET 第一個參數完全一致。
確認規則行指定的策略組存在，且該策略組內有可用的節點或其他有效選項。
先檢查設定檔，再重新載入核心；不要同時修改 DNS、代理模式等無關設定。

驗證命中結果並維護規則集

設定載入後，先查看 Mihomo 核心日誌或客戶端的設定檔與規則頁面，確認 provider 已成功取得並解析。若日誌提到 HTTP 狀態碼、逾時或無法解析網址，優先檢查原始網址、GitHub repository 的可見性、檔案路徑與本機網路；若錯誤指向 YAML 或規則格式，則回到規則檔確認 payload 結構、縮排及 behavior 是否相符。不同客戶端的更新按鈕名稱可能不同，可尋找「更新規則集」或「更新 provider」一類功能。

接著用一個明確屬於該規則集的網域做測試。開啟連線記錄，查看目標網域命中的規則名稱與最後使用的策略組；若結果不是預期路徑，依序確認：網域是否真的符合規則、較前面的規則是否先命中、策略組是否指向預期出口，以及目前載入的 provider 是否為最新版本。只看網站能否開啟並不足以證明規則正確，因為網站可能透過快取、其他網域或既有連線正常載入。

GitHub 上的規則應使用一般版本管理流程維護。修改前先確認變更目的，提交時寫清楚新增或刪除哪些域名；更新後可先在測試設定檔手動刷新，再觀察代表性網域的匹配結果。若維護者不只一人，建議透過 pull request 審閱變更，避免單一提交意外加入過寬的關鍵字或網段。對可能影響大量流量的修改，保留上一版內容或 commit 連結，發現誤判時便能快速回復。

若 GitHub 暫時無法連線，provider 更新可能失敗；實際行為會受到核心版本、客戶端處理方式與本機快取狀態影響。不要因為短暫更新失敗，就立刻刪除 provider 或把規則全部搬回主設定檔。先確認舊規則是否仍被載入、設定檔是否保留快取，再測試來源網址與網路可達性。對工作環境中的關鍵分流，還可準備可控的備援託管來源，但要確保備援檔案與主要來源版本一致，避免兩邊規則不同造成排查困難。

相較於把所有條目堆在一份大型設定檔、依賴人工逐行尋找的做法，Mihomo 的 rule-providers 能把來源、更新週期與流量策略分層管理，GitHub 則提供清楚的版本紀錄與協作流程。只要定期核對來源可信度、更新結果與實際命中策略，便能讓 AI 與開發工具的分流更容易維護；若您也想在熟悉的客戶端中管理 Mihomo 設定，可以前往下載 Clash 客戶端並依本文方式開始測試。