前言：把分流規則變成可維護的規則集
當規則只有幾條時，直接寫進 Clash 設定檔的 rules 區塊很方便；但當域名清單逐漸變長，或需要在多台設備間共用時，所有內容都塞在同一份 YAML 裡，就會變得難以檢查、更新和回復。每次增刪規則都要修改主設定，也容易不小心改動其他分流邏輯。
Rule Providers（規則提供者）可以把規則清單拆成獨立檔案，再由主設定透過 RULE-SET 引用。把規則檔放在 GitHub 上後，你可以查看變更紀錄、比較修改前後的差異，也能讓多個配置共用同一份規則來源。本文以支援 Rule Providers 的 Mihomo 為例，說明 YAML 格式、GitHub 託管方式、規則優先序，以及下載或解析失敗時的檢查步驟。
先確認核心版本
不同 Clash 核心及版本對規則提供者欄位、檔案格式的支援可能不同。以下範例以 Mihomo 為主；若客戶端使用其他核心，請先確認核心支援 rule-providers，不要只依照介面名稱判斷。
1先建立結構正確的 YAML 規則檔
規則提供者的檔案與主設定用途不同。主設定負責定義規則來源、更新週期和策略；遠端規則檔則只放該規則集的內容。使用 format: yaml 時，常見格式是以 payload 作為根欄位，並在其下逐行列出規則項目。請勿把完整的主設定檔直接當成規則清單引用。
例如，建立一個用於代理域名的檔案 rules/proxy-domains.yaml：
這裡的 behavior: domain 代表規則集內容是網域類型，不是完整的 Clash 規則列。若要在同一個規則檔中混合網域、IP 或其他規則類型，可評估使用 classical，並按該行為所要求的格式撰寫項目。不要只把 behavior 改成另一個值，卻保留不相容的內容；核心可能因此無法載入整份規則集。
選擇符合內容的 behavior
- domain：適合只列出網域的清單，檔案內容精簡，容易由非技術使用者維護。
- ipcidr：適合只列出 IPv4 或 IPv6 網段的清單，應確認每條網段格式正確。
- classical：適合需要完整規則類型的情況，例如混合
DOMAIN-SUFFIX、DOMAIN或其他核心支援的規則。
注意 YAML 縮排
YAML 使用空格表示層級，不要用 Tab 縮排；同一層的項目需對齊。規則前的連字號必須位於 payload: 下一層。若網域含有 + 等特殊字元，使用引號包住，可避免被解析成其他 YAML 語法。
2用 GitHub 託管並取得 Raw 連結
建立 GitHub 儲存庫後，將規則檔以清楚、穩定的路徑提交到預定分支，例如 main 分支下的 rules/proxy-domains.yaml。檔名和路徑建議使用英文小寫、連字號或底線，避免空格及頻繁更名；主設定中的 URL 必須與儲存庫、分支和檔案路徑完全相符。
- 在 GitHub 建立或選擇一個儲存庫，並確認要提供給 Clash 使用的檔案可被公開讀取。
- 新增 YAML 規則檔，檢查縮排、欄位和規則內容後提交變更。
- 打開該檔案的原始內容頁面，取得 Raw 形式的網址，而不是一般檔案瀏覽頁面的網址。
- 將 Raw 網址填入主設定的
url欄位，並確認分支名稱和檔案路徑沒有拼錯。
以下網址以 YOUR-USER 和 YOUR-REPO 作為示意，必須換成你自己的帳號及儲存庫名稱。直接複製示意網址並不能取得有效規則。公開規則通常不需要存取權杖；如果規則包含私人資訊或敏感內容，不應直接放在公開儲存庫，也不要把 Token 寫進可分享的 Clash 設定檔。
用提交紀錄追蹤變更
每次只修改一類規則，並在提交說明中記錄變更目的，例如「新增工作服務域名」。日後若某個網站突然走錯策略，可以對照 GitHub 的檔案差異，確認是新規則造成，還是遠端更新未成功。
3在主設定中宣告 Provider 並引用 RULE-SET
完成遠端檔案後，在主設定加入 rule-providers 區塊。以下示範一個網域規則集，請替換 URL、策略組名稱和本機快取路徑。interval 的單位是秒；例如 86400 代表約每 24 小時檢查更新一次。更新頻率應配合規則變更需要，不必設得過短。
這個範例中的 proxy-domains 是 Provider 名稱；RULE-SET,proxy-domains,PROXY 必須引用相同名稱，並把符合規則集的連線交給 PROXY 策略或你的實際策略組。path 是核心在本機保存規則檔的位置，應避免與其他 Provider 共用同一個檔案路徑，否則快取可能互相覆蓋。若客戶端使用受管理的配置或特殊工作目錄，相對路徑的實際位置可能不同，請依核心日誌確認。
理解常見欄位的作用
- type：
http表示由核心透過網路取得規則檔；URL 需能直接回傳檔案內容。 - behavior：說明規則內容類型，必須與檔案實際內容相符。
- format：指定遠端檔案格式；此例為 YAML。若改用純文字規則，格式及內容都必須一併調整。
- url：規則來源網址。確認分支、大小寫與副檔名都正確，且核心所在設備能連線。
- path：本機快取路徑。首次下載、重新啟動或更新時，核心會依此位置讀取規則。
- interval：自動檢查更新的間隔秒數。更新太頻繁可能增加請求次數，設得太長則新規則不會即時套用。
4掌握規則優先序與日常維護
Clash 依照 rules 清單由上而下檢查，符合第一條規則後就會採用其策略。因此，把 Provider 加進設定並不代表它一定會生效；如果上方已有更寬泛的規則先匹配，後面的 RULE-SET 就可能沒有機會處理該連線。
例如，若你先放入會涵蓋大量流量的網域、IP 或地理位置規則，再放自訂規則集，部分目標可能已被前面的規則攔截。建議先寫需要明確指定的自訂規則，再放較廣泛的分類規則，最後才放 MATCH 等兜底規則。實際順序仍需依你的分流目標安排，不能只照抄範例。
- 自訂例外放前面：若某個域名必須直連或使用特定策略，將明確的單獨規則放在會涵蓋它的廣泛規則之前。
- 避免重複來源：同一批域名若同時存在於多個規則集，應檢查它們的先後順序，否則實際結果可能由較前面的規則決定。
- 保留兜底規則：通常將
MATCH放在最後，確保前面的規則都不符合時仍有明確處理方式。 - 先小範圍測試：新增或更新規則後，使用客戶端的連線記錄或規則匹配資訊確認命中的規則與策略，而不是只憑網頁能否開啟推測。
- 做好變更回復：更新規則檔前保留前一版內容或善用 Git 提交紀錄；如果出現誤分流，可先還原變更，再逐條檢查。
建議的維護流程
先在 GitHub 編輯並檢查 YAML，再提交變更；接著確認核心成功載入 Provider，最後從連線記錄驗證實際命中結果。分開檢查「規則檔可讀取」與「規則能正確分流」，更容易定位問題。
5更新失敗與規則未生效的排查方法
使用遠端規則集時，問題通常分為兩類：Provider 沒有成功下載或解析，或者 Provider 已載入，但規則順序、內容或策略設定不符合預期。排查時先查看 Clash Verge、Clash Verge Rev 或其他客戶端的核心日誌，再逐一核對設定，不要一開始就同時改動 URL、格式和規則順序。
- 日誌顯示連線或下載錯誤：確認 Raw URL 在核心所在設備可開啟，檢查網路連線、網址拼寫、儲存庫公開狀態和分支名稱。一般 GitHub 檔案頁面不一定是可直接解析的原始檔網址。
- 回傳內容不是規則檔：若取得的是錯誤頁面、權限提示或其他 HTML，而設定宣告為 YAML，核心會解析失敗。檢查檔案是否公開、路徑是否正確，以及 URL 是否指向實際檔案。
- YAML 解析錯誤：檢查
payload拼字、冒號、縮排和引號，確認每個列表項目都有連字號。也要避免在規則值中混入不支援的格式或多餘欄位。 - Provider 名稱找不到：比較
rule-providers下的名稱與RULE-SET引用名稱，注意大小寫及連字號；兩者不一致時，引用就無法指向預期的規則集。 - 設定看似正常但分流錯誤：先確認連線記錄中是否命中
RULE-SET，再檢查它前面是否已有匹配規則，以及第三個欄位指定的策略組是否存在。 - 更新後仍顯示舊規則：檢查
interval、本機快取和核心日誌；可依客戶端提供的 Provider 更新或重新載入功能操作。清除快取前先確認路徑，避免刪除其他設定資料。 - 只有部分裝置失敗：對照各裝置使用的核心、核心版本、設定檔來源與網路環境。相同 YAML 在不同核心上不一定具有相同支援行為。
避免把錯誤交給規則檔本身
如果 Provider 載入成功但網站仍走錯策略，優先檢查規則優先序、策略組名稱和域名是否涵蓋實際連線目標；如果載入失敗，則先檢查 URL、可讀取性和 YAML 格式。分清這兩種狀況，可以避免反覆修改正確的規則內容。
透過 Rule Providers 管理規則，核心價值不只是把設定檔縮短，而是把規則來源、更新時間與修改紀錄分開管理。建議從一份用途單純、內容精簡的規則集開始，確認更新和命中結果都正常後，再逐步拆分不同用途的清單。完成後，也要定期檢查失效域名、重複規則和不再需要的例外，讓配置保持清晰且容易回復。