· 訂閱與設定 · 閱讀時間約 9 分鐘

Clash 分流規則怎麼維護？用 GitHub 管理 rule-providers 並自動更新

想讓 Clash 分流規則更容易共用、回溯與維護？本篇以 rule-providers 為主軸，帶你用 YAML 建立規則集、放到 GitHub，並設定 behavior、format、path 與 interval 定期更新。另整理規則順序、私有儲存庫存取及更新失敗的檢查方式，適合想把代理設定納入版本管理的開發者。

先分清主設定檔與規則提供者

Clash 設定中的 rules 通常直接列出網域、IP 位址及策略群組等比對項目。規則不多時，放在主設定檔裡較容易檢視；但當自訂清單逐漸增加，或需要多人協作、追蹤修改來源時，直接編輯同一份 YAML 會讓主設定檔變得冗長，也不容易判斷哪些規則已過時。

rule-providers 可以將規則清單拆成獨立檔案，再由主設定檔透過 RULE-SET 引用。規則清單可以由遠端 HTTP 位址取得，也可以放在本機檔案，或直接寫成內嵌內容。GitHub 等程式碼代管服務可用來協作、審查和保存規則版本；實際下載規則的工作則由 mihomo 核心依設定執行，不是由 GitHub 自動替用戶端更新。

規則提供者不是一份完整的 Clash 設定。提供者檔案只放規則項目，主設定檔仍須建立策略群組、宣告提供者並寫入引用規則。若把規則提供者 YAML 當成完整設定匯入，或在主設定檔只有提供者宣告卻沒有 RULE-SET，都不會得到預期的分流結果。

設定 rule-providers 與規則檔格式

以下範例展示遠端 YAML 規則清單的基本結構。示例網址使用保留用途的 example.net，無法直接下載；實際使用時，請換成能由用戶端所在網路存取的原始檔網址。路徑是核心存放下載檔案的位置，更新間隔以秒計算。

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

rules:
  - RULE-SET,work-sites,Proxy
  - MATCH,DIRECT

主設定檔中的 Proxy 必須是已定義的策略群組名稱，並非固定關鍵字。若策略群組實際名稱是「手動選擇」，便應在 RULE-SET 第三個欄位使用完全相同的名稱。引用名稱 work-sites 也必須與 rule-providers 底下的鍵名一致。

domain 類清單通常放網域項目，ipcidr 類清單放 IP 或網段項目；classical 則用於完整規則項目，內容可依規則語法包含類型、匹配值及附加參數。檔案格式與 behavior 必須彼此相符：不能只把副檔名改成 YAML，就讓純文字清單自動變成另一種規則行為。

以 YAML 形式提供網域清單時，檔案常見結構如下；此內容是規則提供者資料，不是主設定檔：

payload:
  - "example.org"
  - "+.service.example"
  - "shop.example.net"

不同 behavior 所接受的項目寫法並不相同。建立正式清單前，應以目前 mihomo 核心支援的規則語法為準，先用少量項目測試載入，再擴大清單。若來源採用純文字格式，也要確認每行是該類型所需的內容，而不是帶有額外標頭、註解格式或網頁錯誤訊息。

用 GitHub 建立可審查的規則維護流程

將規則放進 Git 儲存庫的價值，在於每次變更都能留下差異、提交時間和審查紀錄。建議將規則檔與說明文件分開整理，並以清楚的檔名區分用途，例如工作網域、廣告網域或特定地區網段。名稱應說明清單內容，避免使用「新規則」「測試版」等難以長期辨認的名稱。

  1. 先確認內容來源。為每組規則記錄維護者、上游來源、用途與授權條件。第三方清單可能包含過期項目，也可能有不同的收錄標準，不宜不經檢查就合併。
  2. 小批次修改。每次提交盡量只處理一類變更，並在說明中交代新增、刪除或修正的原因。如此較容易在連線受影響時找出造成差異的提交。
  3. 先檢查格式，再檢查效果。確認 YAML 縮排、欄位及清單項目符合目標格式；再使用正在執行的 mihomo 核心載入測試，避免只依文字編輯器沒有標紅就判定設定有效。
  4. 發布穩定版本或固定分支。提供者網址應指向可預期的原始檔內容，不要使用會隨意改名或刪除的臨時檔案。若追求變更可控，可使用經審查的固定分支或版本標籤；要讓最新提交自動生效，則需接受上游更新會改變用戶端所取得的內容。
  5. 將網址放入主設定檔。把遠端原始檔網址、相對應的本機 path 與更新週期寫入 rule-providers，再在 rules 中引用。公開清單不需要帳戶憑證；若下載必須帶秘密權杖，應重新評估是否適合交給用戶端持續存取。
  6. 更新後保留回退方式。記錄上次可用的規則版本或提交識別資訊。若新清單導致服務誤分流，可以回到前一版，並確認核心已重新取得或載入該版本。

遠端更新依賴用戶端可連線至規則網址。核心通常會在載入設定時取得提供者內容，之後依 interval 檢查更新；實際刷新時機、快取位置與錯誤處理方式，可能受核心版本和圖形用戶端管理方式影響。若本機使用的用戶端會產生或合併設定，請把自訂內容放在該用戶端支援的覆寫位置，避免直接修改更新後會被重新生成的檔案。

規則優先順序：提供者內與主設定檔各有順序

規則通常依主設定檔中的順序由上而下比對，命中較前面的規則後，就會採用該規則指定的策略。RULE-SET 是一條引用規則；它會依序檢查所引用的提供者內容。這表示維護分流時，不能只檢查規則檔本身，也要確認引用規則在整份 rules 中的位置。

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - RULE-SET,work-sites,Proxy
  - GEOIP,LAN,DIRECT
  - MATCH,手動選擇

上述排列會先處理明確的內部網域，再檢查工作網域清單，之後才套用區域網路 IP 規則，最後由 MATCH 接收其餘流量。若把廣泛的網域清單放在特定例外之前，例外可能永遠沒有機會命中；若把 MATCH 放在中段，後面的規則通常就失去作用。

規則提供者只負責提供匹配內容，不會自行決定所有流量的最終出口。真正的出站策略仍由主設定檔的規則和策略群組控制；即使規則集命中，若第三個欄位填入不存在或拼寫不同的群組名稱，核心仍可能報錯，或無法按預期建立設定。

更新與排錯：從下載、解析到命中逐層確認

出現規則沒有更新、規則數量為零，或流量走錯策略時，應一次只檢查一個環節。先看核心記錄和用戶端目前載入的設定，再分辨問題發生在遠端取得、檔案解析、規則引用還是實際連線判斷。單看介面顯示「已更新」不一定足以證明某一條目已被命中。

  1. 確認核心與設定版本。記下用戶端版本及實際執行的 mihomo 版本。若設定欄位在目前核心中不受支援，應先處理解析錯誤，不要直接改動整份規則清單。
  2. 檢查遠端取得結果。確認網址可從目前網路存取，並檢查回應是否為規則檔，而不是登入頁、拒絕存取頁或服務錯誤頁。HTTP 請求成功不代表回傳內容一定是有效規則。
  3. 確認快取路徑與寫入權限。檢查 path 是否可用、目錄是否存在或可建立，以及執行核心的帳戶是否有權寫入。相對路徑的實際基準位置可能由用戶端的工作目錄決定，不能假設一定相對於 YAML 檔所在資料夾。
  4. 檢查格式與行為是否一致。核對 behavior、format 和檔案內容。縮排錯誤、錯誤的 payload 結構、純文字中混入網頁標記，都可能讓提供者無法解析。
  5. 核對引用名稱和策略名稱。比較 RULE-SET 中的提供者名稱與鍵名，並確認出站策略或策略群組存在。名稱大小寫、空格及標點都應保持一致。
  6. 確認規則排序與實際命中。在用戶端連線頁面或核心記錄中查看目標連線的命中規則和出站策略。若有更早的規則先匹配，應調整順序或縮小前置規則的範圍，而不是不斷重複下載同一份清單。

若遠端檔案已修正，但用戶端仍顯示舊結果，可先在應用程式中手動更新規則提供者，再依用戶端的設定重新載入或重啟核心。手動操作完成後，查看核心記錄是否顯示更新成功及解析錯誤。不要在尚未備份的情況下直接刪除所有快取；若核心離線期間規則檔不存在，設定可能暫時無法取得所需內容。

維護規則集的重點不是追求最短更新間隔，而是確保來源可信、內容可審查、格式可解析，且引用順序符合分流意圖。把主設定檔與可重用規則清單分開管理後，更新範圍更清楚，也更容易比較變更及回退。每次修改都應以實際命中結果驗證，尤其要確認重要網域、直連例外和最終兜底策略。

Clash Mac版安裝檔