Clash rule-providers 自訂規則集：GitHub YAML 進階管理指南

為什麼要使用 rule-providers 管理規則集

當 Clash 設定檔中的規則愈來愈多，直接把所有 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 與 PROCESS-NAME 寫在同一份 YAML 中，短期內或許方便，但長期維護會變得非常困難。每次新增服務、修正網域或調整分流策略，都必須修改主設定檔；如果訂閱更新時覆蓋了手動內容，原本的自訂規則甚至可能完全消失。

rule-providers 的用途，就是把規則拆分成一個或多個獨立的規則集，再由主設定檔集中引用。您可以將串流媒體、人工智慧服務、工作網站、廣告網域或區域性網域分別管理，主設定檔只負責定義資料來源、更新週期與規則套用位置。這種做法不只讓 YAML 更容易閱讀，也能降低修改時影響其他分流邏輯的風險。

在 Clash Meta、Mihomo、Clash Verge Rev 等支援規則提供者的核心中，規則提供者通常包含兩個部分：第一是 rule-providers 區塊，用來描述規則檔案從哪裡取得；第二是在 rules 區塊使用 RULE-SET 引用對應名稱。前者像是「註冊資料來源」，後者則是「決定何時套用」。只有完成這兩個步驟，遠端 GitHub YAML 才會真正參與流量分流。

先建立正確觀念

rule-provider 不是策略組，也不是節點訂閱。它只提供一批可被規則引擎匹配的條件，最後要走哪個節點，仍由 rules 中的策略名稱或策略組決定。

第一步：建立 rule-providers 與 YAML 規則檔

建議先在本機建立一個簡單的規則檔，例如 ai.yaml。若採用傳統純規則格式，檔案可以只包含規則項目；若使用 Clash Meta 支援的 YAML 格式，則可在檔案中加入 payload 陣列。實際格式必須與您使用的核心版本相容，不能只依照其他客戶端的範例直接複製。

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

接著在主設定檔加入規則提供者。以下範例使用 GitHub raw 連結，並將遠端內容儲存在本機的 ./ruleset/ai.yaml。type 設為 http 代表核心會透過 HTTP 或 HTTPS 下載檔案；behavior 則用來告訴核心這份規則的內容類型。

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

interval: 86400 代表每 86400 秒，也就是約 24 小時更新一次。若規則內容很少、變更頻率不高，設定每日更新即可；若您正在測試規則，則可以先手動重新載入，避免把更新間隔設得過短而增加 GitHub 請求。path 是客戶端本機儲存位置，不同核心或用戶端的工作目錄可能不同，因此遇到「檔案已下載但讀取失敗」時，要先確認相對路徑是以哪個目錄為基準。

behavior 常見值包括 classical、domain 與 ipcidr。使用 classical 時，規則檔可包含完整的傳統規則，例如 DOMAIN-SUFFIX、DOMAIN-KEYWORD 或 IP-CIDR；domain 通常只適合網域名稱清單；ipcidr 則適合 IP 網段。類型與檔案內容不一致時，常見結果是設定檔可以載入，但規則集沒有命中。

注意格式差異

不要把帶有 payload: 的 YAML 檔案宣告成單純的 domain 清單，也不要把含有完整規則類型的檔案誤設為 behavior: domain。修改前先確認核心文件與目前用戶端支援的格式。

第二步：在 GitHub 上託管與更新規則集

GitHub 適合用來管理自訂規則，因為它提供版本歷史、差異比較與回復功能。您可以建立一個專用儲存庫，例如 clash-rules，再依用途建立 ai.yaml、streaming.yaml、work.yaml 等檔案。這樣做的好處是主設定檔不需要頻繁改動，日後只要提交新的規則檔，Clash 便能在下一次更新時取得內容。

GitHub 網頁上的檔案頁面網址通常不能直接給 Clash 使用，應使用「Raw」連結。例如一般檔案頁可能是 https://github.com/user/repo/blob/main/ai.yaml，實際下載網址則應改為 https://raw.githubusercontent.com/user/repo/main/ai.yaml。兩者雖然指向同一份內容，但前者回傳的是 HTML 頁面，後者才是規則檔本身。

建立 GitHub 儲存庫，建議設為私有或公開取決於您的管理需求。
在固定分支中建立規則檔，檔名使用小寫英文與短橫線，避免空格和特殊符號。
開啟檔案頁面，點選 Raw，複製純文字下載網址。
把 Raw URL 填入主設定檔的 url 欄位。
先用瀏覽器或命令列確認網址回傳的是 YAML，而不是 404 頁面或 GitHub 登入畫面。

分支管理也值得注意。若您在 URL 中使用 main，之後直接修改主分支內容，客戶端會在更新時取得最新版本；若您希望先測試再發布，可以使用 stable 與 develop 兩個分支，測試完成後再合併。對需要長期穩定運作的路由器或辦公室環境而言，固定版本或標籤通常比直接追蹤快速變動的分支更容易排錯。

GitHub 公開儲存庫並不代表可以任意忽略安全性。規則檔內不要放入訂閱連結、節點密碼、私人網域清單或其他敏感資料。若儲存庫由多人維護，建議透過 Pull Request 審查變更，並在提交訊息中說明新增網域的原因。規則越精確，未來越容易找出誤判來源。

管理項目	建議做法	常見風險
檔案命名	依用途分組，例如 `ai.yaml`、`media.yaml`	名稱含空格或大小寫混用，導致路徑難以維護
下載網址	使用 GitHub Raw URL 並固定分支	誤用 `/blob/` 網頁網址，核心下載到 HTML
版本控制	透過 Commit 或 Tag 保留可回復版本	錯誤規則直接推送到主分支，所有客戶端同時受影響
敏感資訊	只放公開且必要的規則內容	把私人網域、訂閱或帳號資訊提交到公開儲存庫

第三步：在 rules 中引用，並處理規則優先順序

完成 rule-providers 後，還要在 rules 區塊引用它。語法通常是 RULE-SET,提供者名稱,策略，例如：

rules:
  - RULE-SET,ai-services,AI
  - RULE-SET,streaming,Media
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

這裡的 ai-services 必須與 rule-providers 下的名稱完全一致，AI 則必須是設定檔中已存在的策略組或代理名稱。名稱拼寫錯誤時，部分用戶端只會在日誌中留下模糊訊息，不一定直接指出是哪一行有問題，因此命名時建議只使用英數字、底線或短橫線。

Clash 規則採用由上而下的匹配方式，命中第一條符合條件的規則後就會停止往下搜尋。因此，自訂規則集應放在過於寬泛的規則之前。例如您希望 example.com 走代理，但前面已經有一條涵蓋大範圍的 GEOSITE,cn,DIRECT，或某個關鍵字規則先命中，後面的 RULE-SET 就不會有機會生效。

實務上可以採用「由特殊到一般」的排序原則：先放單一服務的精準規則，再放分類規則，接著放區域性規則，最後才是 GEOIP、MATCH 或其他兜底條件。不同規則提供者之間也要避免重疊過多，否則當同一網域同時出現在兩個規則集時，排在前面的提供者會決定最終結果。

建議的測試順序

先確認策略組名稱存在，而且能正常選擇節點。
在用戶端重新載入設定檔與規則提供者。
開啟 Logs 或 Connections，找到實際存取的網域。
確認命中的規則類型是否為 RULE-SET，以及最後使用的策略是否符合預期。
一次只調整一條規則，重新測試後再進行下一項修改。

常見錯誤與排查方法

最常見的問題是規則提供者顯示下載失敗。此時不要先修改規則內容，應先把 url 複製到瀏覽器中測試。若瀏覽器也無法開啟，可能是 GitHub 網域解析失敗、目前網路封鎖 Raw 服務，或儲存庫與檔案路徑已經改名。若瀏覽器能開啟但 Clash 下載失敗，則要檢查核心是否需要透過代理下載，以及 proxy: DIRECT 是否適合目前環境。

第二類問題是 HTTP 狀態碼錯誤。404 通常代表使用者名稱、儲存庫名稱、分支或檔案路徑不正確；403 可能與請求頻率、權限或服務限制有關；如果取得的是 GitHub 登入頁，通常表示您使用了網頁 URL，或私有儲存庫沒有提供可被核心驗證的存取方式。公開規則可放在公開儲存庫，私有規則則應確認客戶端是否支援必要的 Header 或驗證方式。

第三類問題是 YAML 語法錯誤。YAML 對縮排非常敏感，Tab 與空格不能混用，冒號後通常需要空格，網址最好放在雙引號中。GitHub 頁面可以協助保存版本，但不會自動保證內容符合 Clash 核心要求。提交前可先用 YAML 編輯器檢查格式，再在測試設定檔中驗證。

rule-providers:
  media:
    type: http
    behavior: domain
    url: "https://raw.githubusercontent.com/example-user/clash-rules/main/media.txt"
    path: ./ruleset/media.txt
    interval: 86400

rules:
  - RULE-SET,media,Media
  - MATCH,Proxy

若規則提供者載入成功但始終沒有命中，請檢查三件事：第一，behavior 是否符合檔案內容；第二，規則檔內的域名是否包含實際使用的完整網域；第三，RULE-SET 是否排在更寬泛規則之後。以串流服務為例，只加入主網域不一定足夠，登入、圖片、API 與授權服務可能使用不同的子網域，應從 Connections 或日誌找出實際請求，再決定是否補充 DOMAIN-SUFFIX 規則。

不要用放寬安全性的方式掩蓋錯誤

遇到 GitHub TLS 或憑證錯誤時，不建議長期開啟忽略憑證驗證。先確認系統時間、CA 憑證、代理路徑與核心版本，避免把中間人攻擊或錯誤下載內容當成正常更新。

長期維護：讓規則集穩定而不失控

自訂規則集最容易忽略的是「更新後驗證」。GitHub 檔案一旦被修改，所有設定了自動更新的 Clash 實例都可能在下一個週期取得新內容。因此，建議每次提交後至少測試幾個代表性網域，確認直連、代理與拒絕規則都符合預期。對影響範圍較大的規則，可先在測試分支驗證，再合併到穩定分支。

更新間隔不宜盲目設得很短。頻繁更新未必能提升準確度，反而可能增加遠端服務負載，或在 GitHub 暫時無法使用時留下不必要的錯誤。一般個人使用可以採用 12 至 24 小時；固定不變的內部網域清單甚至可以只在手動更新時下載。若您管理多台裝置，還應讓它們共用同一份規則來源，避免每台電腦各自維護不同副本。

命名與文件說明同樣重要。每個規則檔建議在 GitHub README 中記錄用途、更新者、最後測試日期與預期策略，例如「只處理 AI 服務網域，命中後交給 AI 策略組」。當數月後需要排查某個網站為何走代理時，這些說明能快速幫您理解設計背景，而不必重新閱讀所有 YAML。

相較於部分只能在圖形介面中逐條新增規則的代理工具，Clash 的 rule-providers 能把規則、版本與分流策略分開管理，既適合個人進階設定，也方便網路管理者透過 Git 進行審查與回復。其他工具若缺少遠端規則集、版本控制或自動更新機制，面對多裝置同步時往往需要重複匯入和手動檢查；Clash 則能以清晰的 YAML 結構、可追蹤的 GitHub 變更與完整的規則日誌降低維護成本。如果您希望把本文的做法實際套用到自己的用戶端，不妨下載 Clash，再從一份小型 GitHub 規則集開始逐步驗證。