Clash 自訂 rule-providers 教學：用 GitHub 管理規則並定時更新

為什麼把規則拆成 rule-providers

當分流規則只有幾條時，直接寫在設定檔的 rules 裡最簡單；但隨著服務、裝置與例外條件增加，主設定檔會逐漸變成難以檢查的大型清單。每次增刪規則都要修改整份 YAML，容易不小心改錯縮排、重複加入項目，或在更新訂閱時被遠端設定覆蓋。rule-providers 的用途，就是把一組規則放到獨立檔案，再由主設定檔載入並套用。主檔負責宣告規則集來源、快取位置與更新週期；規則集檔案則負責保存具體的網域、IP 或傳統規則。

對使用 Mihomo 核心的 Clash Verge Rev、Mihomo Party 等用戶來說，這種拆分方式也讓維護工作更清楚：主設定檔可以保持精簡，規則集則能獨立檢視、回復版本與測試變更。若一份規則集專門處理影音網站，另一份處理工作服務，就可以分別調整及更新，不必每次都動到無關的策略組設定。不過，provider 並不是自動判斷「哪條規則比較正確」的機制；規則仍會依主設定檔中的排列順序逐條比對，這個順序必須由你設計。

理解 type、behavior、url、path 與 interval

建立 provider 時，最重要的是讓「規則檔案的內容」與「宣告的行為」相符。type 指定來源類型；常見的 http 代表由核心透過 URL 取得檔案，file 則代表直接讀取本機檔案。behavior 說明規則集包含哪一類規則，常見值有 domain、ipcidr 與 classical。若檔案是以 DOMAIN-SUFFIX、IP-CIDR 等完整規則行組成，通常使用 classical；不要僅因檔案裡有網域，就把含有多種規則類型的清單宣告成 domain。

url 是遠端來源位址，path 是核心下載並快取規則集的位置，interval 則以秒為單位設定檢查更新的時間間隔。path 應使用客戶端與核心有權限讀寫的位置，名稱最好能辨認用途，也避免兩份 provider 共用同一個檔案路徑。使用 HTTP 類來源時，核心通常會依更新週期重新取得內容；這不代表每次儲存主設定檔都必然立即完成遠端抓取，仍應查看核心日誌及 provider 狀態確認結果。

以下是以 GitHub 公開儲存庫提供 classical 規則集的基本結構。請替換使用者名稱、儲存庫名稱、分支及檔案路徑，並確認填入的 URL 能直接回傳規則檔案內容，而不是 GitHub 的網頁介面：

rule-providers:
  MY-SERVICE:
    type: http
    behavior: classical
    url: "https://raw.githubusercontent.com/your-name/your-rules/main/my-service.yaml"
    path: ./ruleset/my-service.yaml
    interval: 86400

rules:
  - RULE-SET,MY-SERVICE,MyProxy
  - MATCH,DIRECT

這裡的 MY-SERVICE 是 provider 名稱，稍後必須在 RULE-SET 規則中完全一致地引用；MyProxy 則是已存在於 proxy-groups 或可用出站中的策略名稱。名稱大小寫、空格與標點都要核對。範例中的 86400 是一天的秒數，適合更新頻率不高的清單；若來源每天變動多次，可依需求縮短間隔，但不宜無故設定成幾分鐘一次，以免造成不必要的下載、伺服器負載或日誌雜訊。

在 GitHub 建立可維護的規則集

建議為規則集建立獨立的公開儲存庫，或在現有設定儲存庫中安排清楚的目錄，例如以服務或用途命名檔案。新增檔案後，先在 GitHub 檢查檔案內容、分支名稱與提交紀錄，再從檔案的 Raw 檢視取得可直接下載的位址。一般網頁網址常以 github.com 開頭並呈現程式碼瀏覽介面；規則 provider 需要的是回傳原始文字內容的 Raw URL。使用錯誤網址時，核心可能下載到 HTML 頁面，最後報出解析失敗，看起來卻像是 YAML 格式有問題。

規則檔本身應遵循所選 behavior 的格式。以 classical 為例，每個項目都是一條有效規則，並指定適當的匹配條件；以下示意只表示檔案結構，實際網域與策略須依你的使用情境確認：

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,api.example.net
  - IP-CIDR,192.0.2.0/24,no-resolve

不要把整份 Clash 設定檔直接當成規則集上傳。provider 檔案應只包含與其行為相容的規則資料，不應混入 proxy-groups、dns 或另一層 rule-providers 等主設定區段。提交前，可以先以純文字檢查縮排與標點，再使用目前核心支援的檢查方式驗證格式；若新增規則後核心無法啟動，先回復最後一次提交或還原本機備份，確認規則檔可解析後再逐項加入。

Git 的版本紀錄是自行託管規則集的重要優勢：每次變更都能留下原因，發現新規則誤傷登入、更新或區域服務時，可以回到先前版本，而不必猜測是哪次手動編輯造成問題。建議在提交說明中記錄新增網域的用途、測試情況及預期策略；不要只寫「更新規則」。此外，公開儲存庫中的規則會對所有人可見，請勿把訂閱連結、存取令牌、帳號識別資料或私人網域清單一併提交。若使用私有儲存庫，核心能否以安全方式取得內容取決於認證設定；不要把長期有效的存取令牌直接寫進可公開分享的 YAML。

規則優先順序與更新後的驗證方法

RULE-SET 不是會自動插到最合適位置的捷徑。Clash 會依 rules 的排列順序比對流量，通常在前面的規則先命中；因此，範圍較窄、優先性較高的例外應放在可能涵蓋它的寬泛規則之前，而 MATCH 這類兜底規則應放在清單末端。若 provider 放在兜底規則之後，它就沒有機會匹配一般流量；若太寬泛的規則集排在前面，後方更精細的規則也可能形同虛設。

可以把「規則集內容」、「RULE-SET 引用位置」及「目標策略名稱」分開檢查。先確認 provider 已成功載入且檔案不是空的，再查看一個已知網域的連線紀錄，確認命中的規則名稱與預期策略一致。如果連線仍走錯出口，不要立刻把更多網域塞進同一份清單：先確認請求實際連到的主機名、是否由 DNS 或 IP 規則處理，以及前面是否有其他規則先命中。這種由日誌回推匹配路徑的方法，比只看瀏覽器能否開啟網站更可靠。

測試更新時，也要區分「核心沒有抓到新檔案」與「新檔案抓到了但規則未命中」。前者應從網路可達性、HTTP 回應、URL 分支與更新間隔排查；後者則回到規則本身的匹配條件、排列順序及實際請求主機名。若剛修改 GitHub 檔案，可在客戶端提供的 provider 更新或重載功能中手動觸發一次，再查看核心日誌；不同客戶端的選單名稱與入口會隨版本改變，不必假設每個殼層都有完全相同的按鈕。

降低維護風險：拆分、備份與故障回復

規則集拆分的原則不是檔案越多越好，而是每一份都有明確責任與更新節奏。按服務、地區或策略用途分類，能讓你知道某項變更會影響哪些流量；把所有內容塞進一個大型 provider，雖然宣告較少，卻會讓審查、回復及定位誤判變得困難。另一方面，拆得過細也會增加 URL、快取檔與更新狀態的管理成本。實務上可先由一至數份用途清晰的規則集開始，等到變更頻率或維護者不同，再決定是否進一步拆分。

建議保留一份可工作的主設定檔副本，並在每次大幅調整前記錄當下可用的版本。更新 provider 後若大量網站突然走錯策略，先回復最近一次規則集提交或暫時停用該條 RULE-SET，確認基本連線恢復，再檢查變更差異。不要同時改動 DNS、模式、策略組與規則集，否則即使問題消失，也很難判斷真正原因。對於由訂閱管理的配置，還要確認本機修改是否會被訂閱更新覆蓋；若會，應採用客戶端支援的覆寫或合併方式，而不是把希望寄託在手動修改能永久保留。

更新頻率也應按照規則的變動特性設定。很少變化的靜態清單使用較長間隔，可以減少重複抓取；需要快速反映變更的清單才值得縮短週期。間隔不是保證更新成功的期限：電腦休眠、網路暫時不可用、GitHub 無法連線或服務端回應錯誤，都可能使更新延後。因此，對重要規則集應定期檢查核心狀態，並以 Git 提交紀錄核對遠端內容是否確實更新，不能只因 YAML 裡有 interval 就認定它一直正常運作。

相較於把所有規則複製進主設定檔，rule-providers 讓版本追蹤、多人審查及回復舊內容更直接；相較於不明來源、更新狀態不透明的第三方大清單，自行放在 GitHub 的規則也更容易確認每次改動。不過，完全手動維護同樣可能漏掉新網域，規則集的品質仍取決於來源與測試。若你希望在整理自訂 provider 的同時，也用介面檢視核心狀態、切換設定檔並管理日常代理，Clash V.CORE 可作為比只能編輯單一 YAML 的工具更完整的使用選擇；需要時可前往下載頁，依平台挑選合適版本。