Clash 自訂規則集怎麼做？用 GitHub 託管 rule-providers 並驗證 YAML

一、先認識 rule-providers：把規則資料與設定分開管理

rule-providers 是由核心載入外部規則清單的設定機制。它適合放置多條可重複使用的網域或 IP 規則，讓主設定檔只負責指定「使用哪份規則」以及「命中後交給哪個策略」。日後更新清單時，不必逐條複製貼上，也能讓多份設定共用相同的規則來源。

這裡要分清三個部分：GitHub 儲存庫保存規則檔；rule-providers 宣告規則檔的下載位置、格式與更新方式；rules 中的 RULE-SET 則將已載入的規則集連接到代理群組、DIRECT 或其他策略。建立 provider 並不會自動決定流量出口，規則仍須引用它，且對應的策略名稱必須存在。

規則檔可使用公開 GitHub 儲存庫託管，再透過 HTTPS 讓核心下載。公開規則不宜包含訂閱網址、存取權杖、私人主機名稱或其他敏感資料；GitHub 上的公開檔案可被任何人讀取。若規則內容不適合公開，請改用具備適當存取控制的託管方式，並確認核心確實能取得該資源。

二、建立規則檔：依 behavior 選擇 YAML 內容

規則提供者的 behavior 必須與檔案內的項目種類一致。網域清單使用 domain，IP 網段清單使用 ipcidr，完整的 Clash 規則則使用 classical。不要把完整規則行放進 domain 清單，也不要把網域字串誤當成 IP 網段。

以下示範一份網域型規則檔。YAML 根層使用 payload，清單項目各自以連字號開頭；網域後綴前的 +. 表示可匹配該網域及其子網域。請替換成自己有權維護、且確實需要納入同一策略的網域。

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

如果需求是依 IP 網段比對，可另建一份 ipcidr 規則檔，並在 payload 清單中放入有效的 CIDR 網段，例如 203.0.113.0/24。範例網段僅供說明格式，不是可直接用來分類真實服務的資料。若使用 classical，項目則是完整規則，例如 DOMAIN-SUFFIX,example.net 或 IP-CIDR,203.0.113.0/24,no-resolve；這種格式應依所用核心的規則語法檢查。

behavior	payload 內容	適合用途
`domain`	網域或網域後綴	管理一組按網域比對的服務
`ipcidr`	IPv4 或 IPv6 CIDR 網段	管理按目標 IP 比對的範圍
`classical`	完整的規則項目	需要混合網域、IP 或其他支援規則類型時

在 GitHub 儲存庫中，建議將檔案放在用途明確的目錄，例如 rules/custom-services.yaml。檔名保持簡短、固定，並避免在路徑中使用空格或容易混淆的大小寫。確認儲存庫與檔案可公開讀取後，再使用原始檔案的 HTTPS 位址；一般的儲存庫頁面網址是 HTML 頁面，不是供核心直接解析的 YAML 資源。

三、在設定檔宣告 provider，並加入 RULE-SET

以下是 mihomo 設定片段。網址中的 OWNER、REPOSITORY 與分支名稱必須換成實際值；路徑也要與 GitHub 儲存庫中的檔案位置一致。path 是核心下載後在本機保存規則資料的位置，請依用戶端的設定檔管理方式選擇可寫入的路徑。

rule-providers:
  custom-services:
    type: http
    behavior: domain
    format: yaml
    url: https://raw.githubusercontent.com/OWNER/REPOSITORY/main/rules/custom-services.yaml
    path: ./rules/custom-services.yaml
    interval: 86400

rules:
  - RULE-SET,custom-services,海外代理
  - MATCH,DIRECT

interval: 86400 代表以秒計算的更新週期，即一天。它不是「每天固定時刻更新」的保證；核心何時發起首次下載與後續更新，仍可能受啟動狀態、用戶端行為及核心實作影響。測試時可在用戶端手動更新設定或重載核心，並查看執行記錄是否成功取得規則檔。

type: http：表示由核心透過 HTTP 或 HTTPS 取得規則資料；託管網址應可直接回傳規則檔內容。
behavior 與 format：應和檔案內容相符。本文網域清單使用 domain 與 yaml；若改用其他 behavior，清單內容及規則語法也要一起調整。
path：是本機快取位置，不是 GitHub 網址。相對路徑的解析位置可能依核心或用戶端而異；遇到找不到檔案或無法寫入時，先檢查執行目錄與權限。
RULE-SET：第二個參數必須與 provider 名稱 custom-services 完全相同；第三個參數必須是現有策略名稱。範例中的「海外代理」須換成自己的策略，或改為 DIRECT 等有效出站策略。

規則清單由上而下比對，命中後便採用該條規則指定的策略。因此，provider 的引用位置會影響結果。若有比它更早命中的網域或 IP 規則，這份規則集不會再改變該連線的出站方式；兜底用的 MATCH 通常放在所有具體規則之後。

四、選擇更新週期，管理 GitHub 規則變更

更新週期應配合規則變動頻率，而不是越短越好。個人維護、每週才調整一次的清單，通常不需要設定很短的間隔；改動頻繁且希望較快套用的清單，才考慮縮短週期。過於頻繁的請求會增加託管端流量，也可能遇到網路不穩、服務限制或核心反覆下載等問題。

維護情境	週期考量	建議檢查方式
個人少量維護	可採用一天或更長的間隔	變更後手動更新一次，確認新項目能命中
多人共同維護	依提交與審核流程設定，不必每次提交都立即縮短週期	保留變更紀錄，確認修改只影響預期規則
短期測試	先手動重載或更新，不要把測試用的短間隔永久留在正式設定	測試完成後還原正式週期並再次檢查設定

使用 main 等可變分支的原始網址，核心每次更新時會取得該分支目前的檔案內容，適合持續維護的清單，但也代表一次錯誤提交可能快速影響使用者。可將變更先放在測試分支，確認 YAML 與規則效果後再合併。若改為固定提交版本的網址，內容較穩定，但日後必須更新網址或其他引用，才能取得新版本。

每次修改後，都應檢查 GitHub 上的檔案是否仍位於原路徑、是否意外變成登入頁或錯誤頁，以及原始網址回傳的是預期文字內容。若 provider 更新失敗，核心可能繼續使用本機已有資料，也可能在初次下載時沒有可用規則；請以執行記錄為準，不要把「主設定檔載入成功」誤當成遠端規則已成功更新。

為規則檔加入簡短註解或在儲存庫說明用途，記錄每類網域或網段的維護理由。
刪除不再需要的項目時，先確認它是否被其他應用程式或規則依賴，避免一次移除範圍過大。
避免同一網域同時出現在互相衝突的規則集，或在其他規則中更早命中；重複條目會使結果難以判讀。
更新後保留可回復的版本或提交紀錄，出現誤分流時能迅速還原到最後一份已驗證內容。

五、驗證 YAML 與實際命中結果

檢查規則集時，應分成三層：先確認 YAML 結構與縮排，再確認核心能解析 provider 設定，最後確認測試連線實際命中預期規則。只通過一般 YAML 語法檢查，並不能證明 behavior、規則項目及核心欄位都符合要求；同樣地，設定檔能載入也不保證遠端檔案可下載。

檢查原始檔內容：確認根層包含預期的 payload，項目縮排一致，字串沒有多餘的逗號、冒號或不可見字元。網域清單應放網域，CIDR 清單應是合法網段。
檢查引用關係：核對 provider 名稱、RULE-SET 參數及策略名稱是否完全一致，並確認 MATCH 等兜底規則沒有排在規則集之前。
使用實際核心測試：若核心提供設定檢查命令，可使用該核心文件所列的測試方式檢查合併後設定；命令參數會依核心版本而異。圖形用戶端也可透過設定檔檢查、重新載入或執行記錄確認解析結果。
確認遠端更新：手動更新 provider 或重新載入核心，檢查執行記錄中的下載狀態、HTTP 回應與解析訊息。遇到 404 時檢查路徑和分支名稱；遇到 403 或 429 時檢查存取權限與請求頻率。
驗證一條實際連線：選擇規則集中的測試網域，建立新的連線，再查看連線記錄中的匹配規則與出站策略。若應用程式保留 DNS 或連線快取，先重新連線，必要時再清除該應用程式的快取。

若使用通用 YAML 檢查器，請只提交不含訂閱網址、節點密碼或其他私密資訊的規則檔。一般解析器能找出部分縮排與語法錯誤，但無法代替 mihomo 或其他實際核心的欄位驗證。不要將整份含有憑證的設定檔貼到不可信任的線上檢查服務。

常見錯誤可按症狀縮小範圍：設定解析失敗時先查縮排、重複頂層欄位及核心支援；provider 下載失敗時檢查原始網址、網路連線與 HTTP 狀態；下載成功但規則未命中時，檢查 behavior、payload 格式、規則順序、網域是否真的出現在清單，以及目前模式是否為 rule。完成測試後，確認用戶端仍選取正確設定檔與預期代理策略，並將暫時的診斷設定還原。