Clash 自訂規則集實戰：用 rule-providers 管理 YAML 分流

先理解 rule-providers：把規則清單與主設定分開

當 Clash 設定裡只有幾條自訂規則時，直接把它們寫在 rules 底下通常最快；但網域清單逐漸增加、需要在多台裝置重複使用，或想把工作與影音分流規則分開更新時，主 YAML 就容易變得難以閱讀。rule-providers 的用途，是讓主設定引用獨立的規則檔：主設定負責指定規則集來源、更新週期與套用順序，規則檔則保存實際比對項目。日後調整清單時，不必每次都在訂閱設定或主檔裡逐行編輯。

可以把它想成「規則清單的管理方式」，而不是新的代理模式。Provider 本身不會替你選擇節點，也不會自動決定流量走代理還是直連；它提供可引用的規則內容，最後仍要由 rules 中的 RULE-SET 指定對應的策略群組。舉例來說，工作網域可以命中工作規則集並送往「工作代理」，影音網域則命中影音規則集，其他流量再交給後面的通用規則處理。

開始前先確認目前使用的核心支援 rule-providers。不同 Clash 分支和核心版本的設定能力可能不完全相同；若你使用 Mihomo 核心，應以該核心版本支援的設定格式為準。圖形介面可以協助匯入設定檔，但實際載入與更新規則的仍是核心，因此看到介面沒有明顯錯誤，不代表 YAML 一定已生效。修改後要重新載入設定，並透過連線紀錄確認目的網域實際命中了哪條規則。

先選行為類型：domain、ipcidr 或 classical

Provider 的 behavior 必須與規則檔內容相符。選錯類型時，檔案即使能下載，也可能無法依預期解析或比對。一般整理網域清單時，domain 最直觀；需要按 IP 網段判斷時才用 ipcidr；若清單內必須混合不同規則語法，則採用 classical，並明確寫出每一行的規則型別。

另一個需要先決定的是檔案格式。常見的 YAML 規則檔會以 payload 作為清單欄位；純文字格式則通常是一行一條規則。Provider 宣告中的 format 應與遠端或本機檔案的實際格式一致，不能因為網址以 .yaml 結尾，就假設內容必定是有效 YAML。首次建立時，建議先只放少量規則測試載入，再逐步補齊清單，排錯會容易很多。

建立可重複使用的 YAML 規則集

以下是一個簡化的 Mihomo 設定範例：Provider 以 HTTP 方式取得 YAML 規則檔，下載到本機快取路徑，並每隔一天檢查是否有更新。請依照實際使用的核心版本確認支援的欄位；如果核心不認得 format 或其他選項，應先查看該版本文件，不要直接複製不同分支的設定。

rule-providers:
  work-sites:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/your-name/clash-rules/main/work-sites.yaml"
    path: ./ruleset/work-sites.yaml
    interval: 86400

  media-sites:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/your-name/clash-rules/main/media-sites.yaml"
    path: ./ruleset/media-sites.yaml
    interval: 86400

rules:
  - RULE-SET,work-sites,工作代理
  - RULE-SET,media-sites,影音代理
  - MATCH,一般代理

範例中的 your-name、倉庫名稱及策略群組名稱都要換成你自己的實際資料。path 是核心使用的本機儲存位置，宜放在不會被清理或每次匯入都覆蓋的設定目錄中；不同用戶端對相對路徑的工作目錄處理可能不同，若啟動時出現找不到檔案的錯誤，就要檢查核心實際讀取的位置。遠端 Provider 第一次啟用時需要能連線到檔案網址；若網路尚未通、網址回傳的是錯誤頁面，規則可能無法正常載入。

網域型 YAML 檔可以採用以下結構：

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

這裡的項目代表要交由網域規則比對的內容；新增網域前，先確認它確實出現在應用程式的連線紀錄中，避免只憑服務名稱猜測網域。若想使用不同的網域匹配方式，例如只匹配特定主機或匹配網域後綴，應依核心支援的格式撰寫並以實際請求測試。不要把每個服務的所有可能子網域一股腦加入清單，過寬的後綴規則容易把原本應直連的服務也一併送進代理。

如果要建立混合規則清單，可將 Provider 設為 classical，並在檔案中逐行列出規則。這種方式彈性較大，但維護者需要理解每條規則的匹配範圍。無論採用哪種格式，都建議在檔案開頭或倉庫說明中記錄清單用途、維護人與變更原則；規則集一旦被多份設定共用，清楚的命名和變更紀錄比縮短檔名更重要。

用 GitHub 管理規則與更新流程

將規則檔放進 GitHub 儲存庫，可以利用版本控制追蹤每次變更，也方便在不同裝置的設定中引用同一份清單。建立公開倉庫時，可先新增規則檔並提交，再使用該檔案的原始內容網址；網址應直接回傳檔案內容，而不是 GitHub 的檔案瀏覽頁面。建立完成後，先在瀏覽器開啟網址，確認看到的是 YAML 文字，而不是登入頁、404 頁或 HTML 錯誤頁，再把網址放進 Provider。

1. 建立專用倉庫，依用途新增檔案，例如 work-sites.yaml 和 media-sites.yaml。
2. 先用少量、可驗證的網域建立清單，檢查縮排、引號與欄位名稱，再提交變更。
3. 取得檔案的原始內容網址，貼到設定中的 url，並為每個 Provider 設定不同的 path。
4. 重新載入 Clash 設定，確認 Provider 已取得資料，並檢查連線紀錄中的規則命中結果。
5. 每次更新規則後，記錄變更目的；若造成誤分流，可透過 Git 回復到前一個可用版本。

設定 interval 時，應按照清單變動頻率選擇合理的更新週期。每幾分鐘就檢查一次通常沒有必要，還可能增加請求量；個人維護的清單每天或更久更新一次，往往已足以應付日常變更。另一方面，較長的週期代表更新不會即時套用，若剛修正一條錯誤規則，應在用戶端手動更新 Provider 或重新載入設定，並確認新內容確實已載入。

公開倉庫的內容任何人都能讀取，因此不要把訂閱連結、代理節點、帳號資訊、內部網域清單或其他敏感資料放進規則檔。若倉庫必須保持私有，需確認核心或使用方式支援所需的授權流程；不要把存取 Token 直接寫在公開 YAML、截圖或可分享的設定檔中。規則清單最好只保存一般匹配條件，與節點憑證及私人設定分開管理。

規則排序、驗證與常見錯誤排查

Provider 定義好之後，仍要把對應的 RULE-SET 放進 rules。Clash 會依照規則排列順序逐條比對，遇到第一條符合的規則就採用其策略；因此，特定服務的規則集應放在可能先匹配它的廣泛規則之前。若前面已經有把大量網域送往直連或代理的通用規則，後面的 Provider 即使寫得正確，也可能永遠沒有機會命中。通常將較具體的自訂規則放前面，把兜底用的 MATCH 放在最後。

測試時不要只看「設定檔已成功載入」。先選定一個確定在清單內的網域，實際開啟對應服務，再從用戶端的連線紀錄檢查目的網域、命中規則及採用策略。接著測試一個不在清單中的網域，確認它落到預期的後續規則。這組正反向測試可以分辨問題是在 Provider 沒載入、規則沒有命中，還是策略群組或代理節點本身不可用。

如果規則不如預期，建議一次只改一個變因：先確認遠端檔案內容，再確認本機快取更新，接著確認規則集被引用，最後才檢查順序與策略群組。一次同時修改 Provider 名稱、清單格式和節點策略，會讓結果很難判斷。排錯完成後，把實際命中的網域與預期策略記錄下來；未來服務更換網域或訂閱更新時，這份簡短紀錄會比重新猜測規則有效得多。

把規則逐條寫在主 YAML，初期看似省事，但清單一多就容易在訂閱更新時遺失修改，也不利於追蹤誰在何時改了哪個網域；單純依賴圖形用戶端的臨時覆寫，則常受裝置差異與備份習慣影響。使用 rule-providers 搭配 GitHub，能把規則內容、載入方式與版本紀錄分開管理，再透過連線紀錄驗證實際分流，讓設定更容易重用與回復。若你也想先準備合適的 Clash 用戶端，再逐步整理自己的 YAML 設定，可以前往下載頁查看可用版本。

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