Clash rule-providers 規則集進階設定與 GitHub 維護實戰

rule-providers 是什麼？為什麼值得拆分規則

在 Clash、Clash Verge Rev、Mihomo 等用戶端中，規則通常直接寫在主設定檔的 rules 區塊內。當規則只有幾十條時，這種方式相當直觀；但隨著您加入 AI 服務、GitHub、Google、串流平台、廣告過濾、局域網與地區網站等規則，單一 YAML 檔案很快就會變得難以閱讀。任何一個域名需要調整時，都要在長長的清單裡搜尋，還可能因為縮進或規則順序錯誤，造成整份設定檔無法載入。

rule-providers 的用途，就是把規則內容獨立成一個或多個規則集，再由主設定檔引用。主設定檔只保留「規則集名稱、下載位置、格式與快取方式」，實際的域名與 IP 規則則放在獨立的 YAML 或純文字檔案中。這種做法類似把程式碼拆成模組：主設定檔負責組織流量決策，GitHub 檔案負責保存和更新規則內容。

拆分後的好處不只是檔案變短。您可以為不同用途建立獨立規則集，例如 ai-services 管理 ChatGPT、Claude 與 Gemini，developer-tools 管理 GitHub、Docker Hub 與 npm，streaming 管理 YouTube、Netflix 或其他影音服務。每個規則集都能單獨更新、測試、回滾，也能讓多台裝置共用同一份公開規則來源。

先規劃規則集結構與命名

開始建立 GitHub 儲存庫前，先決定規則要如何分類。好的分類應該反映實際的分流策略，而不是單純按照網站名稱堆疊。以日常使用為例，AI 服務通常需要較穩定的代理出口；開發工具可能需要存取海外套件與程式碼服務；串流平台則可能依地區選擇不同節點。這三類流量的出口需求不同，分開後才容易維護。

命名時建議只使用小寫英文字母、數字與連字號，避免空格、中文或特殊符號。名稱要能直接表達規則用途，例如 ai-services、developer-tools、streaming 與 local-direct。名稱一旦被主設定檔引用，就不宜頻繁修改，否則每一台裝置都必須同步調整。

clash-rules/
├── README.md
├── rules/
│   ├── ai-services.yaml
│   ├── developer-tools.yaml
│   ├── streaming.yaml
│   └── local-direct.yaml
└── LICENSE

規則檔案的內容可以使用 Clash 常見的純規則陣列格式。若採用 YAML，通常以 payload 作為根節點；若使用純文字格式，則要在提供者設定中標示正確的格式。不要把完整的 Clash 設定檔誤放進 rule provider，因為規則提供者只需要保存規則項目，不需要包含 proxies、proxy-groups 或 dns 等主設定內容。

payload:
  - DOMAIN-SUFFIX,openai.com
  - DOMAIN-SUFFIX,chatgpt.com
  - DOMAIN-SUFFIX,anthropic.com
  - DOMAIN-SUFFIX,claude.ai

同一規則集內應盡量保持單一目的。不要把 AI 網域、廣告網域和局域網 IP 混在一起，否則日後想把 AI 流量切換到另一個策略組時，會連帶影響完全無關的網站。規則數量非常大時，也可以按服務拆成更細的集合，但不建議為每一個域名建立一個檔案，否則更新與除錯的成本會反而上升。

在 GitHub 建立可維護的規則來源

建立 GitHub 儲存庫後，先將規則檔案放在固定路徑，再確認該檔案能透過公開 Raw URL 取得。Clash 讀取的是檔案內容，不是 GitHub 的網頁預覽頁面，因此不能把一般的 github.com/user/repository/blob/main/... 網址直接當成下載來源。正確做法是使用 raw.githubusercontent.com 對應的 Raw 連結。

https://raw.githubusercontent.com/your-name/clash-rules/main/rules/ai-services.yaml

GitHub 的優勢在於每次提交都有版本紀錄。修改規則前，可以先在分支中測試；確認格式與分流結果正常後，再合併到 main。如果更新後出現錯誤，也能透過提交歷史找出是哪一批變更造成問題。對於多人維護的規則集，README 應該記錄檔案用途、命名規則、修改流程與測試方式，避免不同維護者使用互相衝突的格式。

公開儲存庫不代表可以忽略安全性。不要把訂閱連結、節點密碼、私有伺服器網址或個人識別資訊提交到 GitHub。規則集本身通常可以公開，但主設定檔與節點資料應該分開管理。若儲存庫包含不適合公開的內容，請使用私有儲存庫或其他需要驗證的檔案服務，並確認目前使用的 Clash 核心是否支援該存取方式。

每次提交前，至少檢查三件事：第一，YAML 縮進是否使用一致的空格；第二，域名是否確實需要加入，避免把無關網站誤導向代理；第三，Raw URL 是否能在瀏覽器中直接取得檔案內容。如果瀏覽器顯示 GitHub HTML 頁面、404 或權限錯誤，Clash 也無法正常更新。

在 Clash 設定檔中引用 rule-providers

主設定檔通常需要兩個部分：先在 rule-providers 中宣告來源，再在 rules 中透過 RULE-SET 引用。兩者缺一不可。只宣告 provider 而沒有加入規則，規則集不會實際參與分流；只寫 RULE-SET 而沒有對應 provider，則會出現找不到規則集或設定檔驗證失敗的問題。

rule-providers:
  ai-services:
    type: http
    behavior: classical
    format: yaml
    url: https://raw.githubusercontent.com/your-name/clash-rules/main/rules/ai-services.yaml
    path: ./ruleset/ai-services.yaml
    interval: 86400
    proxy: DIRECT

  developer-tools:
    type: http
    behavior: classical
    format: yaml
    url: https://raw.githubusercontent.com/your-name/clash-rules/main/rules/developer-tools.yaml
    path: ./ruleset/developer-tools.yaml
    interval: 86400
    proxy: DIRECT

rules:
  - RULE-SET,ai-services,AI
  - RULE-SET,developer-tools,Developer
  - MATCH,Final

type: http 表示由遠端網址下載規則；behavior: classical 適合上述包含 DOMAIN、DOMAIN-SUFFIX 或 IP-CIDR 等傳統規則的集合。若規則內容使用特定的域名集合格式，必須依核心文件選用相應的 behavior。format: yaml 則表示檔案是 YAML 格式；如果您提供的是純文字規則，應改用對應格式，不能只看副檔名猜測。

path 是下載後保存在本機的快取位置。不同客戶端對相對路徑的實際資料夾可能略有差異，因此建議使用簡單、沒有特殊字元的路徑。interval: 86400 代表大約每 24 小時檢查一次更新。規則變動頻率不高時，沒有必要每幾分鐘請求 GitHub，否則可能增加遠端請求量，也讓問題排查變得更複雜。

proxy: DIRECT 表示下載規則時直接連線；如果您所在的網路無法直接存取 GitHub，可以改成可用的策略組，例如 Proxy。但要留意啟動初期可能尚未建立完整代理狀態，若 provider 的下載依賴自身代理，可能形成循環。實務上應先測試 Raw URL 在目前網路是否可達，再決定下載流量是否需要經過代理。

規則順序、更新與故障排查

Clash 規則是由上而下匹配，命中第一條後就不會繼續往下判斷。因此，使用 RULE-SET 時，應把更具體、需要特殊處理的規則放在較前面。例如您想讓某個 AI 網域走指定策略組，就應把 AI 規則集放在一般的海外規則或 GEOIP 規則之前；最後才使用 MATCH 作為兜底。若把 MATCH,Final 放在前面，後面的 provider 規則將永遠不會被執行。

排查時不要一次修改多個區塊。先在瀏覽器打開 Raw URL，確認遠端內容正常；接著在用戶端的設定檔頁面或日誌中確認 provider 已下載；最後查看 Connections 或 Logs，檢查目標域名命中了哪個 RULE-SET 與哪個策略組。若 provider 下載成功但網站仍走錯路徑，問題通常在規則內容、規則順序或策略組本身，而不是 GitHub 連線。

對於重要規則集，建議在本機先用 YAML 檢查工具驗證縮進與語法，再讓測試裝置更新 provider。測試裝置可以使用獨立設定檔，避免規則錯誤影響日常連線。確認 AI、開發工具和串流服務都命中預期策略後，再讓其他裝置按照固定更新週期同步。若 GitHub 暫時不可用，已下載的本地快取通常仍可在短時間內使用，但不應把快取當成永久備份，最好在儲存庫和本機都保留可回退版本。

建立長期可用的規則管理流程

rule-providers 的核心價值不在於把設定檔拆成更多檔案，而在於建立可預期的維護流程。可以先為每個規則集指定負責範圍，再規定新增域名時必須附上用途，刪除域名時說明原因。對於同時支援桌面與行動裝置的使用者，還應記錄最低核心版本，因為不同 Clash 分支對格式與 provider 行為的支援程度可能不完全相同。

也不要把所有網域都加入代理規則。規則越大，下載、解析與匹配成本越高，錯誤命中的機會也會增加。對於沒有實際使用的服務，應定期清理；對於經常變更網域的服務，則應評估是否需要使用更合適的官方域名集合或維護方式。規則集的目標是讓分流更清楚，而不是追求檔案數量或規則條數。

如果您從其他人手上取得規則集，先閱讀來源的 README、授權條款與更新紀錄，再將其納入自己的設定。第三方規則可能包含過時網域、過度寬鬆的匹配範圍，甚至把正常網站導向拒絕策略。把外部規則直接放入生產環境前，應先在測試設定檔中觀察一段時間，確認它沒有影響銀行、公司內網、套件下載或局域網裝置。

相較於某些只提供圖形化勾選、但不方便追蹤規則版本的工具，GitHub 加上 rule-providers 可以清楚保留變更紀錄、集中管理與跨裝置同步；而只靠單一大型設定檔的方式，雖然初期快速，長期卻容易出現重複規則、順序混亂與更新遺漏。Clash 能以可讀的 YAML、彈性的策略組和本地快取，把這些維護工作拆成可檢查的步驟。如果您希望以更低成本管理 AI、開發工具與串流分流，不妨先從一個 GitHub 規則集開始，下載 Clash 並逐步建立自己的配置流程。