1 為何 TUN／FakeIP 下仍會「HTTPS 分流」失準
Clash 系在 rule 模式下，會依序嘗試以 IP、網域、GEOSITE 等條件命中規則，最後才落到 MATCH。問題在於：對 HTTPS 而言，連線建立時核心先看到的是對方伺服器的 IP（在 FakeIP 場景下，甚至可能是本機回傳的假 IP）。此時若尚未還原出瀏覽器真正想連的功能變數名稱，則像 DOMAIN-SUFFIX,example.com,PROXY 這類依賴「網域」的規則可能根本無法在正確時機生效，流量會提早被較寬鬆的 IP 規則或預設策略帶走，體感就是「明明寫了規則，卻像沒寫」。
這與「DNS 有沒有洩漏」不完全同一層問題：您可能已用 DoH、已開 fake-ip，但分流引擎在決策瞬間仍需要一個可靠的 host 名稱來對照規則。Meta 核心提供的解法，就是在允許的前提下對流量做深度辨識：對 TLS 客戶端交握封包解析 SNI（Server Name Indication），把「使用者想連的站名」抽出來，供後續規則與日誌使用。這就是 Clash Meta Sniffer 要解的核心痛點，也是與純 DNS 文章互補之處：DNS 決定解析，嗅探則補上連線層的網域線索。若您尚未整理過 DNS 整體架構，建議一併閱讀Meta 核心 DoH 與 FakeIP 最佳實踐，兩邊設定會比較容易對齊。
記住一句話：規則看的是「當次連線被判定的那個目的識別」；Sniffer 的任務，就是讓 HTTPS 場景下這個識別盡量回到真實網域，而不是停在 IP 或假 IP。
2 Sniffer 在做什麼：從 TLS 讀 SNI，不是「偷看網頁內文」
嗅探在這裡指的是對連線起始封包的協定欄位解析，而不是解密 TLS 內容。對一般 HTTPS，瀏覽器會在 Client Hello 帶上 SNI，告知伺服器要連哪個虛擬主機；Sniffer 在核心內截取這段資訊後，就能把「目的 = 某個 IP」還原成「目的 = www.example.com」這種可供網域規則使用的形式。部分情境下也會處理明文 HTTP 的 Host 標頭，但實務上HTTPS 走錯策略最常與 TLS／SNI 相關。
為什麼這會影響策略組？因為規則命中後指向的是某個 proxy-groups 名稱（例如 PROXY 或 AUTO）。若第一步網域就沒對上，後面根本不會走到您預期的群組，自然也不會進入您為該站準備的自動測速或故障轉移邏輯。關於策略組本身的寫法，可參考Clash URL-Test 與 Fallback 教學；本文則專注在「讓規則先正確命中」這一層。
3 怎麼開：設定檔中的 sniffer 區塊（範例）
在 Mihomo／Clash Meta 系設定檔頂層可加入 sniffer。下列為常見的結構示意（實際欄位名稱與巢狀層級請以您使用的核心版本說明文件為準；不同釋出版本可能微調 sniff 下各協定的寫法）。
# Example — verify keys against your Mihomo / Meta version docs
sniffer:
enable: true
sniff:
TLS:
ports:
- 443
- 8443
QUIC:
ports:
- 443
force-dns-mapping: true
parse-pure-ip: true
override-destination: true
enable: true 為總開關。於 sniff 底下為不同協定指定要嗅探的連接埠：TLS 涵蓋多數傳統 HTTPS；若站點改走 QUIC／HTTP3，也需在支援的前提下一併列入，否則仍可能只看到 IP。若您發現開啟 Sniffer 後日誌仍顯示大量純 IP 連線，請優先確認連接埠與協定是否涵蓋實際流量，而不是先懷疑規則寫錯。
4 override-destination、force-dns-mapping 與 FakeIP 的配合
override-destination
當 Sniffer 從 TLS 還原出網域名稱後，override-destination: true 代表後續規則匹配時以嗅探到的 host 作為目的資訊（概念上「覆寫目的地」），讓 DOMAIN／DOMAIN-SUFFIX 類規則能與真實造訪站點一致。若設為 false，嗅探結果可能只用於日誌或部分模組，分流仍只看 IP，問題就會繼續存在。實務上若您已確認嗅探有抓到 SNI，但規則行為不變，請優先核對此開關與核心版本說明。
force-dns-mapping 與 parse-pure-ip
force-dns-mapping 意在讓嗅探到的網域與 DNS 模組的路徑更一致，減少「嗅探是 A 網域、DNS 快取卻像 B」的錯位；parse-pure-ip 則與僅有 IP 的連線是否再嘗試還原有關。兩者與您前端的 DNS 設定（是否 FakeIP、是否 redir-host／fake-ip 模式）高度相關。若 DNS 與嗅探各說各話，最後仍可能出現偶發錯線，因此建議把DNS 防洩漏一文中的 dns 區塊一併檢視，確認 enhanced-mode、fake-ip-range、nameserver／fallback 分層是否清楚。
5 QUIC、HTTP/3、ESNI／ECH 與常見除錯順序
現代網站愈來愈常預設 HTTP/3，底層走 QUIC（UDP 443）。若 Sniffer 只開了傳統 TLS TCP，卻未涵蓋 QUIC，瀏覽器可能優先走 QUIC，您仍會看到「目的像 IP、規則對不上」的現象。處理方向包括：在設定允許時為 QUIC 開啟嗅探、或在瀏覽器暫時關閉 HTTP3 做對照測試、或確認核心是否對該協定版本有完整支援。
另一邊，若網站採用加密的 SNI（例如 ECH 普及後的環境），可解析的明文 SNI 可能減少，嗅探能取得的資訊會跟著變化。這屬於網路協定演進帶來的限制，並非 Clash 單方面設定錯誤。除錯時建議依序確認：① Sniffer 是否啟用且 override-destination 符合預期；② 該站是否走 QUIC／是否需加連接埠；③ DNS 與 FakeIP 是否與嗅探結果一致；④ 規則順序是否被更前面的 IP 規則攔走。
- 只看 IP 規則：若前面有寬鬆的
IP-CIDR規則先命中，後面網域規則永遠輪不到，需調整順序或細化前段規則。 - 日誌有 SNI 但策略不變：核對
override-destination、模式是否為rule，以及用戶端是否覆寫設定檔。 - 效能疑慮：嗅探會增加少量解析成本；一般家用場景可接受，若在低功耗設備上可關閉非必要協定嗅探範圍。
6 與策略組的關係：先命中規則，再談自動選節點
Sniffer 並不取代 URL-Test 或 Fallback，而是讓「該走哪個策略組」這件事先被正確決定。流程可理解為：連線進來 →（必要時）嗅探還原網域 → 規則匹配 → 指向某策略組 → 策略組內再決定實際節點。因此若您已為特定站點寫好網域規則，卻仍走到預設的 MATCH，多半要先回到目的識別是否為網域來排查，而不是急著增加更多節點測速。
實務上建議把 Sniffer、DNS、規則三者當成同一套系統維護：每次更換訂閱、匯入大型規則集、或切換 FakeIP 範圍時，都用一兩個已知網域的站點做對照測試，觀察日誌中的 host 與策略是否符合預期。長期下來，比反覆手動切換節點更能穩定體驗。
7 總結
Clash Meta Sniffer 解決的是 HTTPS 分流在 TUN／FakeIP 環境下常見的目的位址與真實網域脫節問題：透過解析 TLS 的 SNI，讓網域規則能對準使用者真正造訪的站，並可藉 override-destination 讓後續匹配使用還原後的 host。搭配正確的 DNS、適當涵蓋 QUIC，並與策略組、規則順序一併檢視，多數「少數站點走錯線」都能被收斂到可解釋的原因上。
若您需要跨平台一致的用戶端與內建 Meta 核心能力，建議從本站下載頁取得與教學對齊的版本，再將本文 sniffer 片段與既有設定合併。相比只在圖形介面反覆切換節點，先把嗅探與 DNS對齊，往往能一次改善整類網站的HTTPS策略命中表現。
