為什麼要用 rule-providers 管理 GitHub 自訂規則

當 Clash 設定檔裡只有幾條簡單的 DOMAIN 或 DOMAIN-SUFFIX 規則時，直接寫在 rules: 底下並不困難；但隨著你開始分流 AI 服務、串流平台、工作工具、廣告網域與局域網路，規則很快就會膨脹成數百行。所有內容集中在同一份 YAML，不只難以閱讀，日後更新訂閱時也可能被覆蓋，想知道某條規則何時加入、由誰修改，更是不容易。

rule-providers 的核心概念，是把規則集合從主設定檔拆出來，交給獨立的遠端或本機檔案管理。主設定檔只負責宣告「這個規則集在哪裡、格式是什麼、多久更新一次」，再透過 RULE-SET 將它接回規則匹配流程。若規則檔託管在 GitHub，你可以利用 Commit 歷史、Pull Request、分支與標籤建立清楚的變更紀錄，遇到誤判時也能迅速回到上一個可用版本。

這種架構特別適合熟悉 YAML、需要在多台裝置同步設定，或希望把「程式設定」與「規則資料」分開維護的使用者。你可以讓 Clash Verge Rev、Mihomo 或 OpenClash 共用相同的規則來源，同時保留各平台獨立的策略群組與代理埠設定。需要注意的是，rule-providers 只管理規則資料，不會替你決定代理節點；實際流量要走哪個策略，仍由 rules: 中的最後動作決定。

  • 主設定檔：管理代理、策略群組、DNS、TUN 與規則提供者宣告。
  • GitHub 規則檔：專注維護網域、IP 或經典規則內容，方便審查與回溯。
  • RULE-SET：把已載入的 provider 接到規則順序中，指定命中的策略群組。
  • 連線紀錄：確認實際命中的網域、規則類型與最終使用的策略。

建立 GitHub 規則檔與 rule-providers 宣告

開始前先決定規則檔的責任邊界。不要把所有服務塞進一個名為 custom.yaml 的巨大檔案，否則拆分的好處會被抵消。較容易維護的做法，是依用途建立數個小型規則集，例如 ai.yaml、streaming.yaml、work.yaml 或 direct.yaml。每個檔案只處理一個明確目的，日後看到命中結果時，能快速判斷問題屬於哪一組。

GitHub 上的規則檔必須是 Clash 核心可以解析的格式。常見的經典格式會使用 payload: 陣列，每一行放一個規則；不同 Mihomo 版本對格式細節與規則類型的支援可能略有差異，因此不要只看檔名就假設一定相容。建立或修改後，建議先在測試設定檔中載入，確認核心沒有報 YAML 縮排、編碼或格式錯誤。

payload:
  - DOMAIN-SUFFIX,example-ai.com
  - DOMAIN,api.example-ai.com
  - DOMAIN-SUFFIX,cdn.example-ai.com

GitHub Raw 連結要指向檔案本身，而不是一般的程式碼瀏覽頁。一般頁面通常包含 HTML、導覽列與按鈕，Clash 下載後無法將它當成規則解析。若儲存庫位於 https://github.com/your-name/clash-rules，分支為 main，檔案為 rules/ai.yaml，實際 provider URL 應使用對應的 Raw 位址。公開儲存庫適合個人或團隊共用，但不要把訂閱連結、帳號資訊、私有網域清單或其他敏感資料直接提交到公開 Repo。

在主設定檔中，於 rule-providers: 宣告規則集。以下範例使用經典規則格式；behavior: classical 表示 provider 內容由傳統規則行組成。如果你使用的是只包含網域名稱的純文字清單，就應按照核心文件改用相應的 behavior，不要混用。

rule-providers:
  ai-services:
    type: http
    behavior: classical
    url: https://raw.githubusercontent.com/your-name/clash-rules/main/rules/ai.yaml
    path: ./ruleset/ai-services.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

  work-services:
    type: http
    behavior: classical
    url: https://raw.githubusercontent.com/your-name/clash-rules/main/rules/work.yaml
    path: ./ruleset/work-services.yaml
    interval: 86400

type: http 表示核心會從遠端下載；path 是快取到本機的檔案位置，名稱最好固定且具辨識度。interval 以秒計算，例如 86400 代表約每日檢查一次。更新週期不宜設定得過短，否則可能增加 GitHub 請求量，也讓網路暫時不穩時頻繁重新下載。health-check 主要用來確認遠端資源或相關連線是否可達，不等於檢查每一個規則都正確，不能取代實際命中測試。

小提示：GitHub 檔案更新後不一定會立即反映在 Clash。若你正在測試新規則，可先手動更新 provider，再清除或重新載入快取；正式環境則保留穩定的更新間隔，避免遠端短暫異常影響既有分流。

把 RULE-SET 接回規則鏈：順序比內容更重要

宣告 provider 只是第一半工作，還必須在 rules: 中引用它。規則匹配通常採用由上到下、先命中先停止的邏輯；一個網域一旦符合前面的規則，後面即使有更精準的條件，也不會再次改判。因此，rule-providers 的成功與否不能只看檔案有沒有下載，還要檢查它在整條規則鏈中的位置。

rules:
  - DOMAIN,router.local,DIRECT
  - RULE-SET,work-services,Work
  - RULE-SET,ai-services,Proxy
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

上例先處理明確的工作服務，再處理 AI 規則，最後才用 GEOIP 與 MATCH 收尾。若你把 GEOIP,CN,DIRECT、大型國家地區規則或某個寬泛的 DOMAIN-SUFFIX 放在 provider 前面，provider 可能永遠沒有機會命中。反過來，如果自訂 provider 放得太前面，也可能把本來應該直連的更新服務或局域網網域送進代理，造成登入、下載或內網存取異常。

規則位置 常見內容 設計重點
最前段 本機、路由器、公司內網與明確的 DIRECT 例外 避免區網服務被誤送到代理，必要時用 DOMAIN 或 IP 精確指定
中間段 GitHub 管理的 AI、工作、串流等 RULE-SET 依業務目的排序，越精準、越需要優先處理的規則越靠前
後段 GEOIP、MATCH 或其他廣泛兜底規則 只負責收尾，不要讓寬泛條件提前攔截自訂 provider

策略名稱也要保持一致。provider 的最後動作不是寫在規則檔裡，而是寫在主設定檔的 RULE-SET,provider-name,策略名稱 第三欄。若你的策略群組實際叫做 Proxy、AI 或 Singapore，規則中的文字必須完全相同，大小寫與空格都不要想當然修改。常見錯誤是 provider 名稱寫對了，但策略名稱仍沿用另一份設定檔的舊名稱，導致核心載入失敗或規則被忽略。

多個 provider 也可能同時命中同一個網域。例如某個 AI 網域既在 ai-services，又被較大的「海外服務」規則集涵蓋，最後採用哪個策略只取決於 rules: 的前後順序。建議把最想明確控制的規則放在上方，並在 GitHub Repo 的 README 中記錄每個規則集的用途、預期策略與例外項目，讓未來調整時不必重新猜測設計意圖。

更新失敗、規則不命中時的除錯流程

遇到「GitHub 規則似乎沒作用」時，不要立刻重寫整份 YAML。先將問題拆成四層：遠端檔案是否可取得、provider 是否成功解析、RULE-SET 是否出現在有效規則鏈中，以及實際連線是否使用了預期的目的地與策略。逐層確認，比反覆切換全域模式更容易找到根因。

  1. 先驗證 Raw URL：在瀏覽器或命令列開啟 Raw 連結，確認回應不是 404、登入頁、GitHub 限流提示或 HTML。若 Repo 改名、分支改成 master，原 URL 便會失效。
  2. 檢查核心日誌：在 Clash Verge Rev 或其他 Mihomo 用戶端查看 provider 更新結果，留意下載失敗、解析錯誤、TLS 錯誤、權限拒絕與檔案格式提示。
  3. 手動更新 provider：不要只等待 interval。先在規則提供者頁面執行更新，確認時間戳、檔案大小與狀態確實改變，再測試目標連線。
  4. 檢查規則鏈位置：搜尋所有可能提前命中的 DOMAIN、DOMAIN-SUFFIX、GEOIP 與 MATCH，確認自訂 RULE-SET 沒被寬泛規則遮蔽。
  5. 從連線紀錄反查：以實際出現的完整網域為準，不要只看瀏覽器網址列。API、登入、CDN、圖片與 WebSocket 可能使用不同子網域。

若 provider 能下載但沒有命中，先拿一個明確、容易測試的網域做最小規則集，暫時只放一條 DOMAIN，再用連線紀錄確認。這能排除規則檔內容過於寬泛、縮排錯誤或 behavior 不相容等因素。若精確網域可以命中，而 DOMAIN-SUFFIX 不行，檢查後綴是否真的位於請求的 hostname 結尾；若實際連線走的是 CNAME、IPv6 或硬編碼 IP，也可能與你預期的域名規則不同。

GitHub 維護方面，建議把每次變更拆成小型 Commit，提交訊息寫清楚「新增哪個服務」「移除哪個失效網域」以及「是否改變策略意圖」。正式使用前可透過 Pull Request 檢查 YAML 語法，並保留上一版可用檔案。若你要在多台裝置套用同一規則，固定檔名與穩定 URL 比頻繁建立帶日期的新檔案更實用；若需要不可變版本，則可在測試完成後再鎖定到 Git tag 或特定 Commit 的 Raw URL，降低主分支日後變動造成的意外。

另外，請把 rule-providers 的本機快取視為執行資料，不要只備份主設定檔。重新安裝客戶端或更換設備後，provider 可能尚未完成第一次下載，導致啟動初期規則數量不完整。最穩妥的做法是保留 GitHub Repo、主 YAML、策略群組命名與測試紀錄四項資料；恢復時先確認遠端規則成功載入，再進行完整的分流驗證。

相較於把數百條規則硬編進單一設定檔的做法，某些只提供固定清單、缺少版本歷史的工具在團隊協作與誤判回溯上較不方便；有些圖形客戶端也能匯入規則，卻未必清楚顯示 provider 更新狀態與實際命中來源。以 GitHub 搭配 Clash rule-providers，則能把規則審查、更新週期、快取與匹配順序拆開管理，並在連線紀錄中逐步驗證，讓自訂分流從一次性修改變成可維護、可回溯的工作流程；如果你正準備整理自己的規則庫，可先從一兩個用途明確的 provider 開始，再逐步擴充整套架構。

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