Clash 分流總走錯節點？用日誌 matched rule 與 FINAL 命中六步核對

為什麼「規則寫對了」仍可能走錯出口？

Clash／mihomo 的分流本質是一套有序規則表：對於每一個連線請求（通常可還原出域名、目標 IP、埠與協定類型），核心會自上而下尋找第一條滿足條件的規則，並將該條所指向的policy當成本次匹配的結果。許多編輯訂閱時只盯著自己想加的幾條規則，卻忽略了更上方還有更寬鬆的 MATCH、來自 Rule Provider 的批次條款，或是預設的 GEOIP；一旦先被匹配，後面再精細的 DOMAIN-SUFFIX 也不會有機會執行。

另一個維度是策略組本身不是節點：規則可能把流量導向名為 Proxy、過期訂閱組 的 group，而該組在 proxy-groups 裡若是 Selector，實際出站還取決於你（或訂閱預設）選中的成員；若是 url-test，還可能隨延遲測試切換。若只看「我以為規則指向日本組」卻沒看該組當下選到哪個具體代理，就會誤判成「規則壞了」。因此，分流調試的目標是：同時看清「規則命中哪一列」與「該列之後解析出的實際節點」。

先統一用語：matched rule、FINAL 與 MATCH

不同圖形客戶端對日誌欄位的翻譯不一，但核心行為一致。當文檔或介面出現 matched rule、rule、policy 等字樣時，通常指本次連線實際命中的那條規則（含其 policy 名稱）。請以你當前版本顯示的文字為準，重點是能把「這一筆連線」與「設定檔中某一列」對上號。

FINAL 在常見範本裡是規則表最後一行，型態多為 MATCH,某策略組。它的語意是：若前面沒有任何規則匹配當前連線，就全部走這裡。因此，當日誌顯示命中 FINAL 或最底層 MATCH 時，代表你要的不是「FINAL 壞了」，而是你以為會匹配的那條規則其實沒被選中——要回頭找「誰先匹配了」或「域名／IP 為什麼不符合你寫的條件」。

部分教學與訂閱會用 MATCH 作為兜底關鍵字，與「規則類型 MATCH」容易混淆。閱讀日誌時請以整列規則在陣列中的位置與實際列印出來的 policy 名稱為準，不要只憑關鍵字猜。

策略組順序與巢狀：規則只負責「進哪一組」

在 proxy-groups 中，順序呈現的是組在設定檔裡的排列，與規則表中的匹配順序是兩件事：規則表決定流量進入哪個組名；組的類型再決定如何從成員中挑節點。常見情況包括：

• Selector：手動或介面選擇一個成員；若成員本身又是另一個 group，就形成巢狀，需要層層追到葉節點代理。
• url-test / load-balance：依測試結果或演算法挑選，日誌裡看到的最終節點可能與幾秒前不同。
• Relay：鏈式轉發，順序錯誤會導致「以為走 A 實際經 B」的體感差異。

因此，規則命中只解答「這筆連線依規則表應進哪個 policy 名」；若該名對應到巢狀策略組，還要結合面板狀態與日誌裡的最終 outbound，才能回答「是不是真的走錯節點」。若你希望系統複習規則表與 Rule Providers 的撰寫要點，請直接閱讀Clash YAML 規則分流完全指南（2026），本篇不再重複欄位語法細節。

實務上還有一種常見混淆：使用者在面板裡切換了全域「當前節點」，以為只影響某條規則，實際上卻改了某個 Selector 的選中值，導致凡是指向該組的流量都跟著變。此時日誌仍會顯示「命中正確的規則列」，但最終 outbound 與預期不符——這屬於策略組狀態問題，不是規則表邏輯錯誤。對照方式同樣是先抄 matched，再展開該 policy 對應的 group 名稱一路往下追，直到出現具體的 VMess／VLESS 等葉節點為止。

日誌層級：要先看得見規則欄位

若客戶端僅顯示「已連線／逾時」，沒有域名與規則欄位，你很難做實勘。日誌層級需調到足以輸出連線級資訊（常見名稱為 info 或 debug，依核心與面板而定）。除錯完成後建議調回較低層級，避免硬碟與 CPU 被日誌拖慢。若問題牽涉 DNS 先於規則（例如 Fake-IP 與域名不一致），可再交叉閱讀Fake-IP 與 Redir-Host 排查，與本文的「規則層」形成閉環。

六步核對：從重現連線到定位可改之處

以下步驟假設你已能開啟核心日誌或連線清單；介面名稱可能略有差異，但邏輯順序不要跳步。

步驟一：固定變因，重現一筆乾淨連線。 關掉不必要的擴充套件、避免同一秒大量背景請求干擾。選一個目標站（或 App），重新整理一次，讓日誌出現單一主機名為佳。若使用 TUN 與系統代理並存，建議暫時只保留一種接管方式，否則難以對應日誌；可參考TUN 與系統代理教學確認目前架構。

步驟二：在日誌中抄下「目標與規則」兩件套。 目標請記域名（若有）與／或 IP／埠；規則欄請抄matched 顯示的規則描述或 policy 名。若只看到節點名而無規則列，請在設定中開啟顯示詳情或換用日誌檢視視窗。

步驟三：在載入後的規則表（含 Rule Provider）中搜尋，誰最先匹配？ 用你抄下的域名或 IP，對照訂閱合併後的完整規則清單。若發現是一條遺忘的 GEOIP 或寬鬆的 IP-CIDR 插在前面，優先調整順序或收窄條件，而不是狂加底層 DOMAIN。

步驟四：若命中 FINAL 或最底 MATCH，追「為什麼沒匹配到你寫的那條」。 常見原因：子網域漏寫、服務改用不同 CDN 主機名、規則寫 DOMAIN 而實際連線走純 IP、或更前面有一條 DIRECT／全表代理。把「實際主機名」與「規則字串」做一次字面上的並排比對，往往就能恍然大悟。

步驟五：從 policy 名稱追到最終節點。 規則指向 Proxy 時，打開 proxy-groups 裡同名的組：看類型、當前選中成員、是否巢狀。若該組是 Selector，確認面板是否選到「自動選擇」而非你以為的區域節點；若為 url-test，接受它可能自動切換的事實，或改用手動組做對照實驗。

步驟六：只改一處，再重複步驟一至五。 同時改規則順序、又改策略組、又換訂閱，會讓你無法判斷哪個變因有效。建議先以「調整單一規則位置」或「僅切換 Selector 成員」做 A／B 測試，並保留舊設定備份。

常見誤判：其實規則有生效，但你看的不是同一層

以下情況很容易讓人喊「規則不生效」，其實日誌一對就明白：

• 瀏覽器與系統使用不同的 DNS 快取，導致你以為連的是 A 域名，核心卻看到另一個 CNAME 之後的名字。
• HTTPS 站點在規則裡寫了主域，實際請求卻落在 *.cloudfront.net 之類的 CDN 上，需要更精準的規則或域名集。
• 訂閱遠端規則集更新後，插入位置與本地手寫規則的相對順序改變，原本「手寫在上」的假象被打破。

這些都屬於分流調試的日常功課：以日誌為證據線，而不是以「感覺」為證據線。

圖形面板、系統匣與純核心日誌有何不同？

多數使用者透過圖形客戶端觀察連線：表格裡常有「規則／策略／節點」等欄位，語系可能是英文或中英混排，不必強求與官方文檔用語一字不差，只要同一欄位前後對照時語意一致即可。進階使用者若直接讀核心輸出的文字日誌，請注意時間戳與請求順序：瀏覽器同一頁往往同時發多個請求，請鎖定與問題網域相符的那一列，不要被相鄰背景請求干擾判讀。

若使用外部 Web 控制台（例如部分面板會透過 REST 查連線細節），資料更新可能有延遲或取樣粒度不同；這時仍以核心當下一瞬間的規則命中為準，而不是面板快取列表。跨裝置除錯時亦請記得：手機 App 的主機名與桌面瀏覽器未必相同，同一個服務在兩端可能走到不同 CDN，規則表自然也可能命中不同列。

最後，任何「規則命中／FINAL／策略組順序」的結論都應在同一版設定、同一種接管模式下複驗一次。升級核心、重新載入訂閱或切換規則集後，合併後的順序可能改變；若複驗失敗，先確認是否載入了預期的執行中設定檔，再重做六步。若你已能穩定讀懂日誌，下一步便是把這些經驗固化成自己的規則表註解與版本備註，長期維護成本會明顯下降。

讀者常問（與上方 FAQ 結構化資料呼應）

問：matched 顯示的規則和我本地檔案裡那一行字不完全相同？ 可能因為 Rule Provider 展開、註解剔除、或訂閱合併時產生的等價列；以核心實際載入的合併結果為準，客戶端「檢視執行中設定」功能若有，可一併打開核對。

問：我只改 FINAL 指向能不能解決？ 可以當臨時手段，但等同把「未分類流量」全部導向某組；長期仍應找出為何你的具體規則沒匹配，否則其它網域也會默默走 FINAL。

問：與「訂閱連結」有關嗎？ 訂閱決定節點清單與部分遠端規則；若節點標籤混亂，策略組內怎麼選都可能錯。更新訂閱後若行為突變，請比對訂閱版本與規則集變更日誌。本站提供免費客戶端下載與訂閱匯入指引，方便你固定工具鏈後再談進階 YAML。

結語：用日誌對齊真相，再動 YAML

Clash 分流調試的核心不是背誦關鍵字，而是建立一條可重複的證據鏈：連線目標 → matched rule／命中列 → policy 名稱 → 策略組解析 → 實際出站節點。當你習慣用日誌回答「到底命中哪條規則」與「為何落到 FINAL」，多數「走錯節點」都能收斂到具體幾行設定，而不是整包重寫。

這套方法也適用於團隊或家庭環境下的「規則爭議」：把某次異常連線的日誌截圖與對應 policy 名字寫進備忘，比口述「我網頁怪怪的」更易排查。時間若允許，建議將成功除錯後的版本控管備份命名清楚（日期＋接管模式），將來回溯時不必與新版本訂閱盲比對。

相較於反覆更換訂閱或盲測節點，願意多花幾分鐘看規則命中與策略組順序的使用者，通常能更快穩定自己的網路環境，也能在請教他人時附上可對照的日誌片段。若你需要介面清楚、能搭配較新核心與一致中文說明的客戶端來落實上述排查，歡迎從本站整理好的入口開始，少在版本與路徑細節上繞路。

延伸閱讀可從技術專欄依關鍵字挑選 DNS、TUN、YAML 等文章，與本篇併讀即可拼出完整除錯地圖。