為什麼「嗅探」會跟 Fake-IP 與規則順序扯上關係？
許多現代 HTTPS／HTTP3 連線在一開始只有目的 IP 與埠位，核心若無法還原域名，就只能用 IP 去撞規則表裡的 IP-CIDR、GEOIP 之類條目。Sniffing做的事情，是在允許的協定下讀取附帶的主機名線索（常見如 TLS 的 SNI、明文 HTTP 的 Host、部分 QUIC 情境），讓分流引擎「晚一步」仍能把連線與某個網域名稱對起來。
override-destination則再往下一步：不只用還原出的名字做規則匹配，還可能改變實際對外撥號時採用的目的位址語意，讓後續路徑與你從 DNS 拿到的那組紀錄不完全同一條故事線。當 DNS 區塊使用 Fake-IP 時，客戶端先看到的是一段本機替換位址；嗅探與覆寫如果在時間序與字串層次上和你手寫的 DOMAIN 規則不一致，就會出現表面上是規則打架、實際上是連線識別打架的假象。
這也是為什麼症狀经常是局部性的：同一台電腦上，靜態少、協定單純的站可能完全正常；高度依賴 CDN 平滑切換、或多子域輪詢的服務，則更容易暴露路徑分裂。接下來請不要先大改訂閱，而是依序做下面六步，把問題縮成「可重現的一筆連線」。
先對一下症狀：你遇到的是不是本篇範圍？
若符合以下任何組合，很大機率值得按本文排查：
- 啟用嗅探或更新訂閱模板後，只有部分網域出現 TLS 錯誤、長連線、或無限重新整理。
- 同一網站在短时间内連到不同國家／供應商的 CDN 邊緣，體感像在「跳節點」，但規則其實沒有改。
- 圖形面板或日誌裡，主機名有時是品牌域、有時是
*.cloudfront.net、*.akamaized.net之類別名，策略組跟著忽左忽右。 - 你已經照 matched rule 文檢查過規則順序，却发现「命中列」會隨嗅探開關而變。
若你是全網斷線、或一開 TUN 就整機無法上網，請優先回到 TUN 與系統代理對照文；若僅 DNS 內網名無法解析，則先看 Fake-IP 與 Redir-Host 選擇。本篇鎖在嗅探重寫與 Fake-IP／規則互動這條較窄的進階路徑。
六步核對：從關掉重寫到對齊規則與日誌
下列步驟假設你使用的是支援 mihomo 行為的 Clash Meta 系核心；圖形介面的具體開關名稱可能略有差異，但語意應一致。請一次只改一個維度，每步之間都重載設定並複驗同一個問題網域。
步驟一：用 A／B 測試確認「覆寫目的位址」是不是扳機
在備份設定後，將 sniff 區塊中的 override-destination 設為 false（或圖形介面中等價的「不要覆寫目的位址」），暫時保留 sniffing 本身與 Fake-IP 不變。重載後只測試原本會壞的 1～2 個站點。
- 若症狀明顯緩解，可以把問題範圍縮到「嗅探還原 + 覆寫撥號」與目前 DNS／規則不相容；請繼續步驟二與三做長期修補，而不是簡單永久關閉嗅探。
- 若完全無差，仍然要保留此結果：代表扳機可能在嗅探埠範圍、協定覆蓋、或與 TUN／系統 DNS 客戶端的互動；請跳到步驟五。
步驟二：檢查 Fake-IP 白名單與「需要真實 IP」的網域
在 Fake-IP 模式下，核心會維護一份「不要替換」的列表（常見名稱如 fake-ip-filter 或圖形介面中的「Fake-IP 忽略／篩選」）。某些服務若強依賴真實解析結果才能跟 CDN 契約對齊，卻同時被嗅探改變連線目的語意，就容易出現握手已完成但上層內容錯亂或反覆更換出口。
請將問題主域及其常見別名（含登入、靜態、API 子域）與站內 Fake-IP 專文中的觀念對照：你要回答的只有一句話——這個域名是否應該走真實解析路徑，而不是被替換後再靠嗅探「硬拗」回來。
步驟三：用「實際主機字串」重審規則順序，而不是憑記憶
很多人以為自己為 example.com 寫了 DOMAIN-SUFFIX，就應該永遠命中；實務上，連線層看到的可能一直是 cdn-123.vendor.net。當嗅探啟用時，這個字串有時會從 SNI 被還原，有時仍維持上一跳的 IP；先命中哪一條規則，完全取決於當下核心用作匹配的材料與你表頭的寬鬆條款。
請打開現行有效設定（含 Rule Provider 展開），用日誌裡的目標主機名與 IP，對照YAML 規則與策略組指南裡的順序原則：任何寬鬆的 GEOIP、大段 IP-CIDR、或訂閱自動插入的「全表代理」若插在細域名之前，都會讓你產生「嗅探讓規則失效」的錯覺。
步驟四：拉高日誌層級，建立「連線證據鏈」
將 log-level 調到足以輸出連線與規則欄位（常見為 info 或 debug）。對問題網站只做一次乾淨重現，然後在日誌中截取同一秒內、同一目標的完整列，記錄：
- 呈現給使用者／應用層的主機名（若有）。
- 分流引擎還原或採用的主機名／SNI。
- matched rule 或等價欄位顯示的策略名稱。
- 是否有與嗅探、路由覆寫相關的警告或重試行。
若你看不懂 matched 欄位，請直接對照matched rule 與 FINAL 文；那一篇負責「規則表語意」，本篇負責「嗅探如何把材料餵給規則表」。
步驟五：收斂 sniff 範圍與接管型態（TUN／系統代理）
過度寬鬆的嗅探覆蓋，等於讓核心在很多並非必要的協定上也嘗試還原與覆寫；若你同時開啟 TUN 模式，資料路徑更長，技術上更容易遇到「還原成功但時序不完美」的邊角案例。
實務上可嘗試的收敛手法包括：僅保留 TLS／HTTPS 相關嗅探、暫時關閉不必要協定、確認只有單一路徑在接管（避免系統代理與 TUN 重疊除錯）、以及確認本機防火牆或安全軟體沒有攔截回環段的 Fake-IP 回應。每一步之後都用同一測試 URL複驗，避免同時改三個開關卻找不到有效變因。
步驟六：決定長期策略——關閉、限縮，還是改 Redir-Host 對照？
若 A／B 測試一再證明 override-destination 與 Fake-IP 難以並存，你有三條常見退路：
- 維持 Fake-IP，但關閉覆寫、並用規則與白名單精準處理少數問題域——適合大多數訂閱使用者。
- 限縮嗅探到特定埠或協定，避免「全域重寫」；適合進階玩家願意維護兩套設定備份。
- 在可接受的前提下，對特定場景改用 Redir-Host 或調整 DNS 模式，讓域名與解析結果在進規則表前就更一致；細節仍請回 Fake-IP 專文評估副作用。
沒有一鍵「完美模版」：選項之間永遠是可觀測性與複雜度的取捨。只要你手上有日誌證據鏈，就能向自己或他人在復盤時說清楚為什麼採某一條退路，而不是靠感覺。
為什麼「CDN 亂跳」常跟嗅探一起做夢魘？
大型網站往往在 DNS 與邊緣調度上採用多層別名：用戶端以為自己在連品牌主域，實際握手階段看到的是另一張證書與另一個邊緣主機名。嗅探還原出的字串若在某些請求成功、某些請求失敗，規則命中就會在「走品牌域規則」與「走 CDN 供應商規則」之間切換。
此時若再加上 override-destination，核心可能在不同請求之間選擇不同的撥號策略，外觀就像不停換節點。解法往往不是再新增十條 DOMAIN，而是：
- 先把覆寫關掉，確認跳動是否立即緩和；
- 再用抓到的真實主機名字串決定要不要收斂到較寬的後綴層級；
- 最後才考慮是否需要獨立策略組承載該站點。
這種情境與「節點品質差」完全不同：就算換再多伺服器，若識別鏈不一致，體感仍然輪迴卡住。
進階心態：把嗅探當成「還原器」，不是萬能补丁
嗅探解的是資訊不足問題，不是幫你忽略 DNS 與規則設計。當 Fake-IP 讓客戶端以為世界很簡單、實際出口卻很複雜時，override-destination 就像在多軌列車之間強制扳道岔——扳對了皆大歡喜，扳錯了就會出現本文開頭那些只有一小撮站點異常的古怪現象。
因此，成熟的排障順序永遠是：先有日誌證據，再決定開關組合；而不是逆向操作。當你把六步跑過一次，會自然培养出對設定檔的「可觀測性」：知道每一次連線故事從 DNS 到規則表發生了什麼。
讀者常問（與上方 FAQ 結構化資料呼應）
問：我該不該完全關掉 sniffing？ 不一定要。多數訂閱模板預設啟用 sniffing 有其場景價值；真正的分水嶺通常在於是否覆寫目的位址以及嗅探範圍是否過寬。請用步驟一做二分法，而不是情緒式全關。
問：圖形客戶端找不到 YAML，怎麼辦？ 在允許的版本中，使用「檢視執行中設定」或匯出完整設定再搜尋關鍵字 sniff；若介面提供嗅探精靈，請記下每次更動對應了哪幾個底層欄位，方便與日誌交叉驗證。
問：這跟訂閱連結裡的遠端規則有關嗎？ 有。許多套裝規則會預置嗅探段落與順序；你以為的「我只改了一行」可能在合併後變成「嗅探段落被整段覆寫」。除錯時請以合併後實際載入的設定為準。
結語：先讓連線故事說人話，再動 YAML
Clash Meta 時代的進階排障，核心是能把一筆連線拆成可敘事的鏈路：DNS 模式 → 客戶端看到的位址 → 嗅探是否還原主機名 → 是否覆寫撥號 → 規則表第一命中列 → 策略組落地節點。當你照本文六步做完，應該能明確回答兩件事：嗅探重寫是不是扳機，以及規則順序要不要因真實主機字串而調整。
相比反覆更換訂閱或盲測節點，這種「證據先行」的方法更能長期降低維護成本；也方便你在社群或團隊環境裡，用同一份日誌截圖對齊認知，而不是用形容詞互相猜測。若你需要一份介面清楚、能穩定搭載較新核心、並把免費訂閱連結匯入、規則與日誌查看流程講明白的客戶端起點，歡迎先從本站整理好的下進入行門開始，把工具鏈固定後再談進階嗅探微調。
更多分流觀念與平台專題可從技術專欄首頁依關鍵字挑選；把 Fake-IP、matched rule、YAML 與本篇併讀，通常就能蓋住九成進階場景。