Clash rule-providers 是什麼，為何適合放在 GitHub 管理

當分流規則只有幾條時，直接把 DOMAIN-SUFFIX 寫進主設定檔最簡單；但清單一旦持續增加，主設定檔就容易變得難讀、難審查，也不方便在不同裝置間同步。rule-providers 讓你把規則內容獨立成一份檔案，再由 Clash 核心依照設定的網址與更新週期讀取。主設定檔負責指定「載入哪份規則、命中後走哪個策略」，GitHub 上的規則檔則負責維護網域或 IP 清單，兩者分工清楚，日後新增、刪除或回退規則都比較容易追蹤。

這種做法特別適合管理個人常用服務、工作工具、特定影音網站或需要在多台裝置共用的網域清單。你可以在 GitHub repository 裡保存 YAML 檔，透過公開原始檔網址提供給核心讀取；規則變更會保留在 Git 提交紀錄裡，需要時能比較差異或退回先前版本。相較於把長串規則直接貼進訂閱設定，這種拆分方式也更容易分辨問題究竟出在「規則檔沒有更新」、「規則格式無法解析」，還是「命中後指定的策略組不存在」。

不過，rule-providers 不是所有舊版 Clash 核心都支援的通用 YAML 欄位。下文以支援規則提供者的 Mihomo 核心為主要範例；不同客戶端可能使用不同版本核心，匯入前請先確認核心文件與版本。若核心不認得 rule-providers 或回報未知欄位，先不要反覆修改縮排，應先核對目前實際運行的核心，而不是只看客戶端名稱。

ℹ 先記住三個角色：rule-providers 定義遠端規則來源，RULE-SET 在 rules 中引用該來源，最後一欄指定命中後採用的策略組。

先在 GitHub 建立可供 Clash 讀取的規則檔

建議為規則集建立一個專用的公開 repository，或放在已有公開 repository 的獨立資料夾。檔名和路徑可採用容易辨識的英文，例如 rules/work-domains.yaml；避免在網址中使用空格、中文檔名或頻繁改動的臨時目錄。GitHub repository 必須允許匿名讀取，否則 Clash 核心無法取得需要登入才能查看的檔案。規則檔也不應包含訂閱連結、API token、帳號資訊或其他憑證，因為公開 repository 的內容任何人都可能讀取。

先決定規則集的 behavior，也就是檔案裡的規則類型。domain 適合只放網域名稱或網域後綴；ipcidr 用於 IPv4／IPv6 網段；classical 則可容納完整的傳統規則格式，例如 DOMAIN、DOMAIN-SUFFIX 或特定埠條件。不要把不同類型的內容混在一份規則集裡，再期待核心自動猜測；規則集的 behavior 和檔案實際內容對不上，可能導致載入錯誤或規則無法如預期比對。

對初次設定者來說，從純網域清單開始最容易驗證。建立檔案後，在 GitHub 開啟該檔案，使用「Raw」取得原始內容網址。網址應直接指向檔案內容，而不是 repository 首頁、檔案預覽頁或搜尋結果頁。常見形式會包含 raw.githubusercontent.com、擁有者名稱、repository 名稱、分支名稱與檔案路徑。複製網址時請檢查大小寫和完整路徑；GitHub 路徑大小寫不一致時，可能回傳找不到檔案。

若希望一般提交後自動更新，可使用 main 分支上的 Raw URL；這種方式維護方便，但規則內容也會隨分支最新提交改變。若你更重視可重現性，可以使用固定的 commit 版本網址，更新時再明確切換到新的提交。前者適合持續維護的個人清單，後者較適合需要變更審查或穩定回溯的環境。無論採用哪一種，請保留一份本機或 GitHub 歷史版本，避免錯誤提交後只能臨時刪除整條 provider 設定。

網域型規則檔範例

以下檔案使用 Mihomo 可讀取的 YAML 結構，清單中的項目是網域匹配內容，不是完整 Clash 主設定檔。+.example.com 用來涵蓋該網域及其子網域；單一主機名則可用來限定範圍。請將示例網域換成你實際需要管理、且確認應由同一策略處理的網域。 

payload:
  - "+.example.com"
  - "api.example.net"
  - "+.static.example.org"

如需維護傳統規則，則可採用 classical behavior，並在規則檔中放入 Clash 規則字串。這適合清單裡包含多種匹配條件的情況，但也代表每一行的規則類型、參數與逗號都必須正確。初期不妨先用較單純的 domain provider；等確認網址、更新及命中流程都正常，再把確實需要的條件移到 classical 清單，減少一次引入太多變數。

在主設定檔加入 provider 與 RULE-SET

主設定檔需要有兩個相互對應的區塊：一處定義 provider，另一處在 rules 中引用它。以下示範以名為 work-domains 的網域規則集，命中後交給名為 Work 的策略組。請替換擁有者、repository、分支與檔案路徑，並確認 Work 確實存在於你設定檔的 proxy-groups 中；策略名稱必須完全一致，包含大小寫與符號。 

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

rules:
  - RULE-SET,work-domains,Work
  - MATCH,PROXY

欄位各自負責不同工作：type: http 表示透過 HTTP 或 HTTPS 取得遠端內容；behavior 指定規則內容的種類；format: yaml 表示以 YAML 格式解析規則檔；url 是 GitHub 原始檔網址；path 是核心在本機保存規則資料的位置；interval 以秒為單位，示例的 86400 約為一天。請確保本機路徑可由核心建立或寫入，並避免讓多份規則集不必要地共用同一個快取檔名。

規則順序是另一個容易忽略的重點。Clash 會依序比對 rules，找到第一條符合的規則後就採用該行策略。因此，若在 RULE-SET 前面已有範圍過大的 DOMAIN-SUFFIX、GEOSITE 或其他規則，流量可能先被前面的條目攔截，後面的 provider 看起來就像完全沒有作用。通常應把需要優先處理的自訂規則放在寬泛規則之前，並把 MATCH 放在整個規則清單末端。若你的既有設定有特殊順序，請先確認前面的規則是否會覆蓋自訂清單，而不是單純把 provider 放到任意位置。

interval 也不等於每次啟動都保證立即抓到最新版。核心可能會依本機快取、設定載入狀態與更新機制決定何時重新請求；不同版本與客戶端介面也可能提供手動更新 provider 的入口。若 GitHub 已有新提交而客戶端仍使用舊規則，先查看核心或客戶端是否能手動更新該 provider，再檢查本機快取檔的時間與內容。修改主設定檔後，則要確認正在運行的設定檔已重新載入，避免只保存文字卻仍沿用舊的記憶體設定。

⚠ 不要把整份網址當作可公開的秘密管理方案：公開 GitHub repository 任何人都能讀取；若改用私人 repository，則要確認核心實際支援相應的認證方式，不能只把帶 token 的網址硬寫進公開設定檔。

驗證規則載入、比對結果與常見故障

設定完成後，先檢查 YAML 是否能被目前核心解析，再驗證網路取得與規則命中。若客戶端有設定檔檢查功能，先執行檢查並讀完整錯誤訊息；若核心日誌指出 provider 載入失敗，從網址能否匿名開啟、HTTP 狀態碼、檔案格式與本機寫入路徑逐項檢查。不要在錯誤訊息仍指向 YAML 解析失敗時，先去調整節點或策略組，因為那兩者不會修復格式錯誤。

若要確認一個實際連線走哪條規則，可開啟客戶端的連線紀錄，在測試該網域時查看請求的主機名、命中的規則類型與最終策略。用主機名測試比只看網站首頁更可靠，因為頁面可能同時連到登入、API、圖片或 CDN 子網域；你列入規則集的網域未必是瀏覽器當下真正使用的那一個。測試時也應避免同時改動 DNS、TUN、模式和策略組，否則即使結果變好，也難以判斷是哪項變更造成差異。

長期維護時，建議每次提交都附上簡短說明，記錄新增網域的原因、預期策略與測試結果；也可先在測試分支驗證，再合併到正式分支。不要因為某項服務偶爾失敗，就把一整個大型網域後綴加入代理清單；過寬的匹配可能把不相關網站、登入服務或本地化 CDN 一併改道。若不同服務需要不同策略，應拆成多份 provider，或以範圍更精確的規則明確管理，並確保每份清單的命名、用途與更新責任都容易辨識。

相較於把所有規則混在訂閱檔中的做法，GitHub rule-providers 更容易追蹤改動、共用清單並回復錯誤提交；但手動維護每個客戶端的網址與策略名稱，也比只按更新訂閱多一道檢查。使用不同 Clash 圖形客戶端時，介面位置、核心版本與 provider 更新按鈕可能不一樣，最終仍應以實際載入的核心與日誌為準。若你希望在同一個流程中管理設定、查看規則命中並快速驗證自訂分流，Clash V.CORE 可提供更集中的使用體驗；你可以前往下載頁，再依自己的平台選擇合適版本。