Clash rule-providers 進階設定：用 GitHub 維護自訂規則集

NT-06.1rule-providers 是什麼,為什麼值得獨立管理

Clash 的 rules 欄位可以直接寫入規則,例如 DOMAIN-SUFFIX,example.com,Proxy 或 IP-CIDR,192.0.2.0/24,DIRECT。規則數量少時,直接放在主設定檔裡最容易理解;但當規則增加到數十條、數百條,主設定檔會變得難以閱讀,每次調整也容易誤改其他區段。rule-providers 的用途,就是把一批相關規則拆成獨立檔案,再從主設定檔引用。

外部規則集不會自行決定流量要走哪個節點。它只負責提供一組規則,真正的分流結果仍由主設定檔中的 rules 順序和最後指定的策略組決定。這個區分很重要:規則集描述「哪些網域或 IP 屬於某一類」,主設定檔則描述「這一類流量要交給誰處理」。

以 mihomo 為例,常見的 provider 類型包括 http 與 file。http 用於從遠端網址取得規則檔,適合託管在 GitHub 的原始檔案服務或其他靜態檔案伺服器; file 則讀取本機路徑,適合測試、離線環境或需要完全掌控更新內容的場景。

NT-06.2YAML 欄位怎麼寫:從規則檔到主設定檔

建立規則集時,建議先按用途拆分,例如把常用服務、開發工具、公司內網和廣告網域分成不同檔案。每個檔案只處理一種匹配邏輯,後續查錯時比較容易判斷是哪一組規則造成影響。若規則檔使用純網域清單,可選擇 domain;若內容是 IP 網段,使用 ipcidr;若需要混合 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等完整 Clash 規則格式,則使用 classical。

以下是一份以 YAML 儲存的網域型規則檔。它只包含規則內容,不需要再包一層 payload:

payload:
  - '+.developer.example'
  - '+.packages.example'
  - 'docs.example.com'

在 mihomo 中,規則 provider 的實際檔案格式會依 behavior 與 format 而定。為了讓不同版本的核心更容易識別,建議在使用 domain、ipcidr 時採用含 payload 的 YAML 結構;若使用 classical,則可寫成完整規則行:

payload:
  - DOMAIN-SUFFIX,developer.example
  - DOMAIN-SUFFIX,packages.example
  - IP-CIDR,192.0.2.0/24,no-resolve

接著在主設定檔中宣告 provider。下面的網址以示範網域代替實際託管位址,部署時應換成 GitHub 儲存庫提供的穩定原始檔案網址。path 是核心保存下載檔案的位置,同一個 provider 的 path 不應和其他規則集重複。

rule-providers:
  developer-rules:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/developer.yaml"
    path: ./ruleset/developer.yaml
    interval: 86400

  office-rules:
    type: http
    behavior: classical
    format: yaml
    url: "https://example.com/rules/office.yaml"
    path: ./ruleset/office.yaml
    interval: 21600

rules:
  - RULE-SET,developer-rules,Proxy
  - RULE-SET,office-rules,DIRECT
  - MATCH,Proxy

RULE-SET 後面的第一個參數必須與 rule-providers 下的名稱完全一致,第二個參數則是策略組或內建策略,例如 Proxy、DIRECT 或 REJECT。名稱區分大小寫,連字號、底線和空格也要逐字一致。若 provider 名稱寫錯,核心通常會在啟動日誌中報告找不到規則集,而不是替你自動修正。

NT-06.3用 GitHub 維護規則集:目錄、提交與發布方式

把規則集放到 GitHub 的價值不只是「有一個遠端網址」,更重要的是每次變更都能留下提交紀錄,可以知道誰在什麼時間加入或刪除了哪一條規則。對團隊環境而言,這比直接在客戶端內編輯一份快取檔案更容易審核,也能在規則誤判時快速回到上一個可用版本。

建議為規則集建立清楚的目錄,並讓檔名直接反映用途。不要把所有內容都放在一個名稱含糊的 rules.yaml 裡,否則長期維護時難以確認它影響哪些流量。可以採用以下結構:

rules/
  developer.yaml
  office.yaml
  streaming.yaml
  direct-domains.yaml
README.md

每次修改前,先在本機檢查 YAML 縮排、引號和規則格式,再提交到儲存庫。提交訊息應說明變更目的,例如「加入套件鏡像網域」或「移除已停用的內網網段」,不要只寫「update」。如果規則由多人共同維護,可要求修改者在提交說明中補充測試範圍,例如測試了哪些網域、預期走哪個策略組。

1. 先建立規則檔和簡短的說明文件,記錄每個 provider 的用途、格式與預期策略。
2. 在本機用 YAML 語法檢查工具確認縮排,並逐條檢查網域、CIDR 和規則類型是否符合宣告的 behavior。
3. 提交變更後,確認遠端檔案能以純文字方式取得,而不是導向儲存庫網頁、登入頁或下載錯誤頁面。
4. 在 Clash 客戶端中手動更新一次 provider,觀察日誌是否顯示下載成功、解析成功和規則數量載入完成。
5. 先在測試設定檔中啟用,確認實際連線符合預期後,再套用到日常使用的 Profile。

NT-06.4規則優先順序與自動更新後的排查

Clash 規則通常採用由上到下的首次匹配邏輯。流量一旦符合某一條規則,就會使用該規則指定的策略,不會繼續往下尋找更精確的條目。因此 RULE-SET 的排列順序和 provider 內部的規則內容同樣重要。過於寬泛的規則放在前面,可能會提前攔截原本想交給其他策略的流量。

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - RULE-SET,developer-rules,Proxy
  - DOMAIN-SUFFIX,example,Proxy
  - MATCH,DIRECT

上例中,內網網域先於較大的開發者規則集處理,因此 internal.example 不會因為同時符合其他規則而被送到代理。MATCH 通常放在最後作為兜底規則;如果把它放在 RULE-SET 前面,後面的規則就沒有被執行的機會。

規則集不是越大越好。網域規則過度寬泛,例如直接加入一個大型頂級網域,容易把不應代理的服務一併導入節點;IP 規則過多則可能增加維護成本,也可能與 CDN、雲端服務的動態位址變更產生衝突。拆分 provider 時,應以實際管理責任和分流目的為單位,而不是只按檔案大小切割。

更新失敗時,不少核心會繼續使用上一份已快取的規則,所以「沒有立刻斷線」不代表遠端檔案已經成功載入。排查時應打開客戶端的規則集或核心日誌,確認最近一次更新時間、HTTP 回應狀態與解析結果。若遠端檔案被刪除、網址改名或暫時無法連線,不要急著刪除本機 path 下的快取檔,先保留最後一份可用版本,待遠端修復後再重新更新。