核心觀念：規則不是「全部一起算分」，而是「排隊逐一比對」
可以把 rules 想成一份由上而下的 if 鏈：每一條連線進來時，核心從第一行開始問「這條規則是否與當前連線相符？」；一旦相符，就採用該列第三欄（或您的設定格式中對應欄位）所指定的策略，並停止再往後看。因此規則順序就是優先級：寬鬆規則放太前面，會讓後面精心寫的細則永遠變成死碼；這正是許多分流不生效抱怨的真正原因——不是後面那條壞了，而是根本輪不到它執行。
與優先序同樣重要的是規則類型能看到的資訊。DOMAIN 類需要可用的主機名；GEOIP、IP-CIDR 需要可靠的目的位址；若決策當下仍只有 IP、卻沒有還原出 SNI／Host，域名規則可能長期無法觸發，流量會一路滑到後面的 IP 規則或 MATCH。這類「輸入條件不足」與「順序錯誤」在症狀上很像，排查時請先用日誌確認第一條命中究竟是誰，再決定要調順序還是補 Sniffer／DNS。
小結：先問「誰先匹配？」再問「匹配後送去哪個策略組名稱？」兩題都對，節點才會跟著對。
MATCH 是什麼？為什麼通常放在最後一行？
MATCH 是一條必定命中的規則：它不檢查域名或 IP，而是直接說「前面都沒接住的話，這筆連線跟著我走」。因此實務上幾乎永遠把 MATCH 放在 rules 清單的最末端，當作兜底（預設出口）。常見寫法是把兜底指到名為 PROXY 或 🚀 手動選擇 這類的 proxy-groups，或依個人習慣寫 MATCH,DIRECT 讓剩餘流量直連。
若您把 MATCH,某策略 放在清單中段，等於宣告「後面的規則全部作廢」；若放在最前，更是整份表只剩第一行有效。這兩種都會表現為怎麼改域名規則都沒用。遇到類似情況，請先在圖形介面或文字編輯器中捲到 rules 底部，確認 MATCH 是否只有一條且在正確的結尾位置，並確認訂閱合併沒有再次插入另一條更早的 MATCH（見下文「合併與插入」）。
# Snippet — MATCH as final catch-all; replace PROXY with your group name
rules:
- DOMAIN-SUFFIX,corp.example,DIRECT
- GEOIP,private,DIRECT,no-resolve
- GEOIP,CN,DIRECT,no-resolve
- MATCH,PROXY1規則第三欄：接的是「策略組名」，不是您心裡的節點暱稱
每一條規則最後指向的，必須是設定檔裡真的存在的名稱：DIRECT、REJECT 等內建動作，或 proxy-groups 底下某個 name。若訂閱把預設組叫做 🔰 選擇節點，而您規則寫 PROXY，載入時可能報錯或落到意外預設；若勉強載入成功，也可能與介面上您點選的組不是同一個物件，看起來就像規則沒生效。
圖形客戶端常在全域選單讓您挑「目前出口」，那往往是在操作某個最上層策略組；但 rules 仍可能把多數流量指到另一個自動組（例如 url-test）。因此除錯時請以日誌中的策略名稱為準，而不是只看介面大圖示。若您使用自動測速或主備組，可再讀 url-test／fallback 健康檢查，把「規則命中」與「組內選線」兩層關係分開理解。
2訂閱合併、prepend-rules 與「您以為的位置」
實務上很少只維護一份靜態 YAML：多半是訂閱節點＋社群規則包＋個人補丁，由客戶端或範本引擎合併。此時決定成品的關鍵是：您的自訂規則被插在整張表的前面還是後面。若工具把訂閱附帶的大段 GEOIP,CN,DIRECT 放在最前，而您的 DOMAIN-SUFFIX 被 append 到尾巴，就會出現國內 IP 先被直連規則帶走，海外網站卻因 CDN 邊緣位於本地而「看起來像被當成國內流量」的體感落差。
解法是對照您使用工具的合併順序說明：哪些鍵會前置、哪些會追加；必要時改為手動維護一段固定骨架，只把訂閱當 proxy-providers。無論如何，請在腦中保留一張「合併後的完整 rules」示意圖，而不是只看分檔中的片段；真正的規則優先級永遠以載入後順序為準。
3實務骨架：從「區網／廣告／例外」到「國別／兜底」
下列順序僅作為可讀性良好的起點，實際仍須依您的 DNS、FakeIP、TUN 與應用場景微調：（1）區網與必須直連的管理後台；（2）明確域名例外（要走代理或直連的少數站）；（3）廣告或拒絕類（若您有）；（4）大型 GEOSITE／RULE-SET；（5）GEOIP 或寬鬆 IP 規則；（6）最後一行 MATCH。與 GEOIP／GEOSITE 教學 對照閱讀時，可把本文當成「這些類型塞進清單時的相對位置該怎麼排」的導讀。
# Snippet — illustrative ordering; adapt names and sections to your profile
rules:
- IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- DOMAIN-SUFFIX,internal.corp,DIRECT
- GEOSITE,google,PROXY
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT,no-resolve
- MATCH,PROXY
上例中，若您把 GEOIP,CN,DIRECT 移到 GEOSITE,google 之前，且 Google 的連線在決策時先被判定為「落在 CN 的 IP」，則可能永遠走不到 GEOSITE,google 這一行。這不是 Google 規則壞掉，而是國別規則更早命中。類似取捨在跨國 CDN 站點上非常常見，解法通常是把域名級規則上移，或縮窄過於寬鬆的 GEOIP／IP-CIDR。
4用日誌驗收：只看「第一條命中規則」
當您懷疑分流不生效，請先把 log-level 調到 info（必要時短暫提高），重現連線後在紀錄中搜尋該連線對應的規則名稱或規則索引（依客戶端呈現為準）。您要確認的不是「我心裡希望它走哪條」，而是引擎實際採納了哪條。若顯示的規則與預期不同，下一步只有兩類：要嘛調整順序，要嘛修正該規則類型所需的輸入（例如補域名、開 Sniffer、對齊 DNS）。
建議固定一套口訣：DNS／FakeIP 是否讓域名規則可見？→第一條命中是域名還是 IP 規則？→命中後送進哪個策略組？→該組目前選到哪個節點？四步下來，大多數「節點不對」會落在前兩步，而不是最後一步單純換機場能解決。
常見坑（與優先序高度相關）
太早出現的第二條 MATCH 或寬鬆 GEOIP
合併設定時若重複引入訂閱範本，可能不小心得到兩條 MATCH；或某包習慣把 GEOIP,CN 放在極前段。症狀是日誌顯示命中了您沒印象的規則列——此時請展開完整合併結果搜尋關鍵字，而不是只改自己維護的小檔。
介面選擇覆寫與規則誤解
某些客戶端在 GLOBAL 層級的手動選擇，會讓新手以為「我已選了節點 A，為何規則仍走 B？」其實是不同策略組各自有狀態。請對照日誌確認命中規則指向的組名，再回介面找對應組別。
HTTPS 階段沒有域名，域名規則形同不存在
此時連線會提早落入 IP／GEOIP／MATCH。若您只加域名規則而不處理 TLS 資訊取得方式，會感覺規則順序怎麼調都無效。請銜接 Sniffer 教學 與 TUN／系統代理是否覆蓋目標程式。
提醒：代理與路由設定須符合所在地法規與服務條款；本文僅供合法合規的網路除錯與自用學習。
開源資訊與安裝包取得方式
Mihomo 上游以開源方式維護，需要核對某版規則行為時可至公開程式庫查證。若您要安裝或更新圖形客戶端，建議優先使用 本站 Clash 下載頁，並搭配 設定說明文件；將「取得安裝包」與「追蹤原始碼」分開，可避免誤以為必須自行從 Release 頁拼裝環境。
結語
Clash Meta／Mihomo 的分流體驗，很大一部分建立在「您是否真的理解 rules 的有序語意」：不是寫得多就覆蓋得全，而是誰先匹配決定了結果。MATCH 則像安全網，把剩餘流量收斂到您指定的預設策略；它應該穩穩待在清單末尾，而不是意外攔在中段讓後續規則全部報廢。
相較於只靠直覺調整訂閱或反覆切換節點，先從日誌確認第一條命中規則與策略組名稱，通常能更快終結分流不生效的循環。當您把順序、兜底與合併後的實際清單對齊後，再回頭疊加 GEOIP、GEOSITE 或 PROCESS-NAME，維護成本會明顯下降，也比較不會陷入「改 A 壞 B」的拉扯。
相較於其他同類工具，Clash 系在「規則、策略組、日誌」之間的對照關係較一致；把本文的順序觀念內化後，您會更容易與本站其他長文串成一套可複用的排查路徑。