為什麼要用 rule-providers 管理自訂分流規則
如果你只替自己的一份 Clash 設定加入幾條規則，直接編輯主設定檔通常最快；但當規則逐漸增加，或你要在筆電、桌機與家中其他裝置共用同一份清單時，把所有內容塞在主 YAML 裡就容易變得難以維護。每次調整都要重新找出正確位置，訂閱更新也可能覆寫手動修改；如果團隊成員各自複製設定，久了還會出現規則版本不一致、有人漏加新網域的情況。
rule-providers 可以把規則資料與主設定分開：主設定負責宣告規則集的來源、格式、更新方式與本機儲存位置，再透過 RULE-SET 將規則集接入現有規則清單。如此一來，主 YAML 不必隨每次規則調整而改動，GitHub 上的規則檔也能透過版本紀錄追蹤變更。跨裝置使用時，各裝置只要載入同一份設定並能連線到規則檔來源，便可取得相同的規則內容。
要先釐清一個常見誤解：GitHub 負責託管檔案，Mihomo 核心負責依設定定期取得更新。這不是 GitHub Actions 主動把規則推送到你的電腦，也不是每次修改檔案後所有用戶端都會立刻同步。更新時間取決於 interval、核心是否正在執行、網路能否連到來源，以及用戶端是否重新載入設定。理解這個界線，才能正確設定排程並判斷更新延遲是否正常。
本文以 Mihomo 相容設定為例。不同圖形用戶端可能把設定檔放在不同位置，選單名稱也可能略有差異；下方設定應加入實際生效的設定檔，而不是任意建立一份未被載入的 YAML。若你使用的是不支援相同欄位或核心版本較舊的客戶端，請先確認其核心支援狀況，再套用設定。
建立 GitHub 規則檔並設定 rule-provider
建議先建立專用的公開 GitHub repository，將自訂規則放在清楚的目錄，例如 rules/。規則檔案應只包含可公開分享的分流資料，不要把訂閱網址、節點資訊、帳號憑證、內網主機名稱或個人識別資料一起提交。公開 repository 的內容任何人都可能讀取；若規則本身不適合公開，應選擇受控的託管方式，並確認用戶端能以合適的權限取得檔案。
對一般網域清單，可以採用 domain 行為，並以 YAML 格式提供網域項目。以下是示意檔案；請把網域換成你確實需要分流、且有權管理的項目：
payload:
- '+.example.com'
- '+.service.example'
- 'api.example.net'+.example.com 用來表示網域及其子網域的匹配範圍；單一主機名稱則可明確寫成 api.example.net。不要把這種網域清單與 classical 規則內容混為一談：不同 behavior 對檔案內容的預期不同。使用 classical 時，檔案可以放置帶有規則類型的項目，例如 DOMAIN-SUFFIX 或 PROCESS-NAME；使用 domain 時，則應依核心文件所定義的網域項目格式整理。
提交檔案後，從 GitHub 的檔案頁面取得該檔案的 Raw 網址，並確認網址指向實際的 YAML 內容，而不是 repository 瀏覽頁面。使用固定分支（例如 main）時，更新檔案後 Raw 內容會隨之變更；若你希望先檢查再發布，也可以使用受控的發布分支或版本標籤，但要確保設定引用的路徑與分支名稱一致。
rule-providers:
my-custom-domains:
type: http
behavior: domain
format: yaml
url: "https://raw.githubusercontent.com/ACCOUNT/REPOSITORY/main/rules/custom-domains.yaml"
path: ./ruleset/my-custom-domains.yaml
interval: 86400
rules:
- RULE-SET,my-custom-domains,Proxy
- MATCH,DIRECT這段設定中，my-custom-domains 是規則集名稱，必須與 RULE-SET 所引用的名稱完全相同；名稱可自行取用，但建議使用能辨識用途的英文短名。url 是遠端檔案位置，path 是核心在本機儲存規則資料的位置，interval 則以秒為單位，設定為 86400 代表約每 24 小時檢查一次。請將 ACCOUNT、REPOSITORY 與策略群組名稱 Proxy 換成實際值，並確認該策略群組確實存在於你的設定中。
path 是相對於核心工作目錄解析的路徑，不一定等於圖形用戶端顯示的設定檔資料夾。若核心無法寫入該位置，或不同裝置的工作目錄不一致，可能出現下載成功但載入失敗、重新啟動後找不到檔案等狀況。實際部署前，先查看客戶端或 Mihomo 文件所說明的工作目錄與檔案權限；不要因為一台電腦可用，就假設另一台裝置必定使用相同的路徑。
安排更新週期，並確認規則順序
interval 是檢查遠端規則集的間隔，不是保證某一分鐘完成更新的鬧鐘。裝置關機、核心尚未啟動、網路暫時中斷或遠端服務無法連線，都會使更新延後。若你剛提交了修正，不妨先透過用戶端提供的規則集更新或設定重載功能手動測試；確認成功後，再讓定期更新接手日常維護。
更新頻率應配合規則變動速度與服務限制。每天更新通常足以應付一般個人清單；如果規則數量很少、內容很少改動，可以採用更長週期，降低不必要的請求。反過來說，把間隔設得很短也不會讓規則匹配更準確，只會增加下載與檢查頻率。規則檔若剛好在兩次檢查之間修改，裝置會在下一輪更新時才取得新內容，這是排程運作方式的一部分。
使用公開原始檔網址時，GitHub 適合存放一般規則清單，但不應把它視為高可用、即時推送的設定服務。若你的部署對更新時效或服務可用性有較高要求，應評估託管來源、快取與故障時的處理方式。規則檔最好保持小而明確，提交訊息則記錄修改原因，例如新增了哪個服務網域、移除了哪條過時項目，方便日後追查規則變化。
規則順序同樣重要。Clash 會依照 rules 中的排列順序比對，通常先匹配到的規則就會決定流量去向。因此，自訂規則集的 RULE-SET 應放在可能提前攔截同一流量的廣泛規則之前，並放在最後的 MATCH 之前。如果它被放在 MATCH,DIRECT 之後，規則集即使更新成功，也沒有機會參與一般流量的判斷。
- 檢查策略名稱：
RULE-SET後面的策略必須與proxy-groups中的名稱一致；若大小寫或文字不同，核心可能無法依預期導向策略。 - 避免規則重複與衝突：先檢查現有訂閱是否已有相同網域的規則。即使重複規則不一定造成解析錯誤，也會使結果取決於排列位置，增加日後排查難度。
- 把例外規則放在合適位置：若一個服務需要特定網域走代理、另一些網域則應直連，應明確列出例外並確認它們位於能先匹配的位置，不要只依賴過於寬泛的網域後綴。
- 確認檔案格式與行為相符：
domain、ipcidr與classical適用的資料內容不同。更改行為類型時，同時檢查遠端檔案結構與主設定的宣告。
比較穩妥的維護方式，是把規則更新視為一次小型發布：先在測試設定中載入，確認核心接受設定、規則集成功下載，再查看連線紀錄或規則匹配資訊，確認目標請求確實選到預期策略。測試通過後才合併到主要分支。若多人共同維護，建議透過 Pull Request 審核變更，並在變更說明中記錄測試結果；這比每個人直接編輯主設定更容易發現網域拼字錯誤或範圍過大的匹配。
載入失敗排查與跨裝置維護流程
當規則集沒有更新或規則看起來未生效時，先分辨問題是在「取得檔案」、「解析檔案」還是「規則匹配」。只要一次檢查一個環節，就不必因為流量結果不符合預期而同時更改 URL、路徑與規則順序，最後反而無法知道真正原因。
遠端檔案無法取得
先檢查 url 是否為 Raw 檔案網址，分支名稱與檔案路徑是否正確，並確認 repository 的可見性允許核心讀取。將網址貼到瀏覽器開啟時，應能看到規則檔內容，而不是 GitHub 的檔案頁面、登入提示或 404 錯誤。若本機瀏覽器可以開啟，但核心仍無法下載，檢查 Clash 連線紀錄中的錯誤訊息、DNS 狀態與核心網路連通性；不要把瀏覽器的代理狀態直接當成核心一定能連線的證據。
檔案取得成功但解析失敗
檢查 YAML 縮排、冒號與引號是否成對，並確認遠端檔案確實符合設定的 format 和 behavior。最常見的失誤包括把完整的 Clash 主設定貼進規則檔、在網域清單中混入不相容的規則型態，或提交空檔案。可以先縮小成只有一兩條規則的測試檔，讓核心成功載入後再逐項加回；若加到某一行便失敗，就能更快定位格式問題。
規則已載入但流量仍走錯策略
在用戶端檢查目前載入的設定檔與連線紀錄，確認請求的目的網域是否真的落在規則涵蓋範圍，再查看該連線最後命中的規則與策略群組。若規則集已載入但沒有命中，常見原因是網域範圍寫得太窄、實際請求使用另一個子網域，或更早的規則已經先匹配。若命中正確的 RULE-SET 卻仍無法連線，則應轉而檢查策略群組與節點狀態，而不是繼續改寫網域清單。
適合多裝置與團隊的維護流程
跨裝置同步時，主設定和規則檔都要有清楚的版本管理方式。可以把主設定中使用的規則集名稱、遠端 URL、更新間隔與相對路徑寫進團隊文件，並約定由誰審核 GitHub 變更。不同裝置的核心版本、工作目錄和檔案權限可能不同，所以測試時至少要涵蓋一台桌面裝置與一台實際會長時間使用的裝置；如果手機端採用不同用戶端，也要確認它支援相同的 provider 格式。
日常維護不必追求把所有網域都納入自訂規則。優先收錄已確認需要特殊分流、且能說明用途的項目；定期移除過時網域，避免清單無限制膨脹。若一項規則的效果不確定，先在測試分支驗證，再發布到共用規則檔。如此即使更新後出現問題，也能透過 GitHub 的變更紀錄回復前一版，而不必猜測是哪位使用者修改了本機設定。
手動維護大型清單、複製貼上多份 YAML，或依賴只存在單一裝置上的設定，往往會造成規則漂移與排錯困難。相較之下，Clash 的 rule-providers 能把規則資料、更新間隔與主設定拆開，再利用 GitHub 的版本紀錄協作審核；只要留意核心支援、載入路徑與規則順序，就能讓跨裝置維護更有跡可循。如果你也想在不同平台上管理 Clash 設定，可以前往下載頁查看可用用戶端與版本資訊。