前言：把自訂規則放進 GitHub 管理
如果你經常為不同網站新增分流條件，或希望在多台裝置上使用相同規則，把規則直接散落在各份 Clash 設定中，日後修改和同步都會變得麻煩。使用 rule-providers，可以將規則清單獨立存放，再由主設定透過網址載入；GitHub 則提供了方便維護、檢視差異和追蹤版本的地方。
本文以 Mihomo 為例，示範如何將規則檔放在 GitHub 公開儲存庫、在 Clash 設定中宣告 provider，並透過 RULE-SET 將規則套用到指定策略組。整體概念是：GitHub 負責保存規則檔，Clash 核心負責定期取得清單，而主設定決定清單放在規則鏈中的位置。
適用情境
適合需要跨設備共用規則、集中維護自訂網域，或希望透過 Git 歷史追蹤每次變更的使用者。若你只是新增一兩條規則，直接寫在主設定中也完全可行。
1準備 GitHub 規則檔
先在 GitHub 建立一個儲存庫，或選擇已有的公開儲存庫，再新增規則檔。建議將不同用途的清單分開，例如工作網站、影音服務或自訂直連網域。這樣更新其中一組規則時，不會不小心影響其他流量。
- 建立儲存庫，或在既有儲存庫內新增專用資料夾，例如
clash/rules。 - 新增一個 YAML 檔案，例如
work-sites.yaml，並在檔案中放入規則清單。 - 提交變更後，開啟檔案的原始內容頁面，確認網址使用
raw.githubusercontent.com，而不是一般的 GitHub 網頁網址。
以下是適用於 classical 行為的規則檔範例。payload 底下每一項都是一條完整規則；範例網域僅作格式示意，請依實際需求替換。
DOMAIN-SUFFIX 會匹配指定網域及其子網域，DOMAIN 用於精確匹配，DOMAIN-KEYWORD 會檢查網域是否包含指定字串。網段規則則使用 IP-CIDR；其中的 no-resolve 可避免為了套用這條 IP 規則而額外解析網域。請勿將說明文字、Markdown 標題或程式碼圍欄一併貼進規則檔。
注意公開內容
公開儲存庫的規則檔任何人都可能讀取。請勿放入訂閱連結、帳號資訊、存取權杖或其他機密資料。也要避免引用來源不明、內容會被他人任意修改的規則清單。
2在 Clash 設定中宣告 rule-provider
取得原始檔案網址後，在主 YAML 設定的頂層加入 rule-providers 區塊。以下使用 GitHub 上的公開檔案作示範；請將網址中的帳號、儲存庫名稱、分支和檔案路徑換成自己的資料。
work-sites 是 provider 名稱，稍後會在 rules 區塊引用。type: http 表示由網址取得清單，behavior: classical 表示檔案包含完整規則，format: yaml 則對應上一步帶有 payload 的 YAML 檔案。path 是核心保存下載內容的本機路徑，interval: 86400 表示每隔 86400 秒檢查更新一次，也就是約一天。
若你的規則檔使用純文字格式，請確認核心版本支援相應格式，再按該核心的設定要求調整 format 和檔案內容。Mihomo、舊版 Clash 核心以及不同客戶端所附的核心，對支援欄位可能不完全相同；匯入前應先確認實際使用的核心，而不要只依照客戶端名稱判斷。
網址與分支
直接使用 main 分支的原始網址最簡單，但每次提交都可能改變線上內容。若想鎖定某個版本，可將網址改為特定標籤或提交版本所對應的原始檔路徑，並在確認更新後再手動切換。
3用 RULE-SET 套用清單並安排順序
宣告 provider 只代表 Clash 知道如何取得清單，還需要在主設定的 rules 區塊加入 RULE-SET，才能讓清單中的匹配結果導向策略組。以下範例將工作網站流量交給名為 PROXY 的策略組：
RULE-SET 的第一個參數必須與 rule-providers 中的名稱完全一致；最後一個參數是策略組或策略名稱，必須已存在於設定中。若你的策略組名稱不是 PROXY，請改成實際名稱，例如 🚀 手動選擇。逗號和縮排也要遵守 YAML 格式。
Clash 會依照 rules 的排列順序逐條比對，命中後便採用該條規則的策略，不會繼續尋找後面的規則。因此，較具體且需要優先處理的條件通常要放在較廣泛的規則之前。以上例子中，規則集放在 GEOIP 和 MATCH 之前，讓清單中的項目先進入代理策略；但單獨的 example.com 直連規則排在其後，對於已被規則集匹配的網域不會生效。
如果希望某個網域優先直連，就要把直連規則移到規則集之前，或將該網域從 provider 清單中移除。反過來說，若希望規則集覆蓋一般直連條件，就把 RULE-SET 排在一般規則前面。修改排序前，先釐清哪些條件應優先，避免同一個網域同時出現在多條規則中而造成結果與預期不同。
核對兩個名稱
確認 RULE-SET 引用的 provider 名稱與宣告一致，也確認規則指向的策略組確實存在。這兩處名稱錯誤，是匯入後規則看似無效的常見原因。
4更新設定與追蹤規則版本
儲存設定後，先在 Clash Verge、Clash Verge Rev 或其他支援的客戶端中套用設定，查看設定檢查結果及核心日誌。不同客戶端的選單名稱略有差異，通常可在設定檔頁面重新載入，或在代理設定中手動更新規則提供者。自動更新則依賴核心正常運行、網址可連線，以及 interval 所設定的檢查時間。
若規則更新後沒有立即反映，先確認更新時間是否已到，再手動觸發 provider 更新或重新載入設定。也可以檢查本機快取檔是否存在，以及日誌中是否顯示下載成功。修改 GitHub 檔案後，先在瀏覽器開啟原始網址，確認內容已更新且仍是有效 YAML，再排查 Clash 端問題。
用 Git 記錄每次變更
將規則拆成容易理解的小型提交，例如「新增工作文件網域」或「移除失效規則」，日後就能從 GitHub 的提交紀錄查看變更內容。若多人共同維護，可透過 Pull Request 先檢查差異，再合併到正式分支。這比直接在各台設備上修改 YAML 更容易追蹤，也較不容易遺失設定。
使用固定分支時，遠端內容一旦更新，所有引用該網址的裝置可能在下次檢查時取得新版本。若某次修改造成大量網站走錯策略，可透過 Git 還原檔案，或將 provider 網址暫時改回先前確認可用的版本。重要環境建議先在測試設定中驗證，再更新日常使用的規則來源。
5載入失敗時的檢查方向
provider 無法載入時，建議由外到內逐項檢查，先確認網路與網址，再檢查檔案格式及設定語法。不要一次同時更改多個欄位，否則難以判斷真正原因。
- 原始網址是否可讀取：在瀏覽器開啟
raw.githubusercontent.com網址，確認回應不是 404、登入頁或一般 GitHub HTML 頁面。公開規則檔不需要私人權杖。 - URL 路徑是否正確：逐一核對使用者名稱、儲存庫、分支和檔名大小寫。GitHub 路徑中的大小寫差異可能導致找不到檔案。
- YAML 縮排及欄位是否正確：
rule-providers、provider 名稱和欄位需保持正確層級；清單中的payload也要縮排一致，避免使用 Tab。 - 核心是否支援設定格式：確認目前載入設定的核心支援
behavior、format等欄位。若錯誤訊息指出欄位不支援，應先核對核心版本和其設定文件。 - 本機路徑是否可寫入：檢查
path所在目錄是否可由核心建立或寫入。容器、受限權限環境或特殊安裝方式，可能讓相對路徑指向不同位置。 - 更新間隔與快取狀態：設定剛更新時，舊快取可能仍在生效。手動更新 provider，並在日誌中確認下載時間和結果。
避免直接清除所有設定
排錯前先備份主設定及規則檔。若要清除 provider 快取，先確認目標檔案是可重新下載的規則快取，而不是包含節點或其他重要資料的設定檔。
常見問題
GitHub 規則儲存庫一定要公開嗎？
最簡單的方式是使用公開儲存庫，並以原始檔網址供核心讀取。私有儲存庫通常需要額外的驗證方式，而將權杖直接寫進 Clash 設定可能造成機密外洩，不建議在不了解安全風險時採用。
規則檔更新後，所有裝置會立刻同步嗎？
不一定。裝置要能連線到來源網址，並且等到更新間隔到期，或由使用者手動觸發更新。若希望多台裝置使用完全相同的版本，可以固定到特定提交或標籤，確認變更後再統一更新來源。
rule-provider 已載入，為什麼流量還是走錯策略？
先確認 provider 的名稱有被正確引用、目標策略存在，再檢查規則在 rules 中的位置。由於規則依序比對，排在前面的廣泛條件可能先匹配，使後面的規則集沒有機會生效。
可以直接把其他人維護的規則集放進自己的設定嗎？
技術上可以，但應確認來源可信、格式相容且內容符合預期。外部規則可能變更、失效或加入過度寬泛的匹配條件；使用前建議檢視內容、測試流量走向，並保留可回復的版本。