為什麼「規則寫對了」卻像沒生效？
在 Clash Meta／mihomo 裡，分流規則（DOMAIN、DOMAIN-SUFFIX、規則集等）本質上是在問：「這條連線應該對應到哪個網域或目標？」若答案只有一個裸 IP，而你的規則幾乎都寫在網域層級，核心就只能往更後面的 IP-CIDR 或 MATCH 掉下去——於是出現「明明寫了某站要走專用策略組，實際卻走預設節點」的錯覺。
傳統 HTTPS 在建立 TLS 連線時，Client Hello 裡會帶 SNI（Server Name Indication），理論上可用來還原使用者想連的主機名稱。許多網站與 App 在採用 HTTP／3 時會改走 QUIC（常見仍是 UDP 443），握手資料結構不同，若嗅探模組沒開或埠範圍沒覆蓋，核心同樣會長時間只知道「一個 UDP 流到某個 IP」。這就是進階使用者常說的：「要開 Sniffer（嗅探）才能把加密流量的域名還原出來，再讓分流規則命中。」
Sniffer 在核心裡實際做了什麼？
簡單說，Sniffer 會在資料路徑上讀取早期封包內容：對明文 HTTP 讀 Host；對 TLS 讀 SNI；對 QUIC 讀 Initial 裡的相關欄位（實際解析深度依版本與設定而定）。當核心因此得到一個「更像真實網域」的名稱後，就能把後續路由決策從「純 IP」拉回到「網域規則可讀」的世界。
另一個常一起出現的開關是 override-destination：當嗅探到的主機名與原本連線目標不一致時，是否要用嗅探結果覆寫內部用來匹配規則的目的地資訊。對需要精準命中 DOMAIN-SUFFIX 的情境，通常會希望開啟；若你遇到少數相容性問題，再針對特定網域用 skip-domain 或客戶端提供的略過清單機制排除即可（欄位名稱請以你使用的核心版本文件為準）。
sniffer 區塊。改動後請重載設定或重啟核心，並用連線日誌確認規則命中的網域欄位是否已從 IP 變成主機名。
第一步：在 YAML 啟用 Sniffer 與 TLS／QUIC 埠
下列片段示範一組常見、可再依環境微調的起手式：打開嗅探、涵蓋 TLS 與 QUIC 常用埠、並讓嗅探結果能參與路由。請將其合併進你的主設定（實際縮排與既有鍵值請保持 YAML 合法）；若你已使用訂閱產生的完整配置，通常放在頂層與 dns、tun 同級即可。
# Sniffer starter template for mihomo / Clash Meta (adjust ports if your network uses non-standard ones)
sniffer:
enable: true
sniff:
HTTP:
ports: [80, 8080-8880]
TLS:
ports: [443, 8443]
QUIC:
ports: [443, 8443]
force-dns-mapping: true
parse-pure-ip: true
override-destination: true
QUIC 區段的埠請與實際服務一致：大多數網站仍落在 443，但若你面對的是自架服務或非標準埠，需要同步修改，否則嗅探根本不會被觸發。force-dns-mapping 有助於讓 fake-ip 與嗅探結果在內部對齊（具體效果與你的 dns 模式有關）；parse-pure-ip 則讓「只連到 IP」的連線仍有機會被還原出網域資訊。
第二步：確認分流規則順序真的會用到「網域」
嗅探只負責「把名字還原出來」；要不要走對節點，仍取決於 分流規則 怎麼寫、以及順序是否被其他規則提前截走。實務上請先確認：目標站點的 DOMAIN-SUFFIX 或規則集條目，位於夠靠前的位置，不會被過寬的 GEOIP 或 MATCH 搶先匹配。若你使用遠端規則集，也要留意更新頻率與是否含有 CDN 邊緣域名——有時需要補上上游 API 域名與內容域名兩組規則。
想系統性理解規則設計，可搭配站內 規則分流詳解；若你主要在桌面環境處理「全系統接管」，則建議同時對照 TUN 模式指南，避免只開系統代理導致部分程式仍繞過核心。
HTTP／3 與 QUIC：為什麼「只嗅 TLS」不夠？
現代瀏覽器與不少行動 App 會優先嘗試 HTTP／3，底層走 QUIC over UDP。此時若 Sniffer 僅啟用 TLS、沒有為 QUIC 宣告合適埠與解析路徑，核心在路由階段看到的可能仍是「UDP 封包往某 IP 去」，與一般 TCP 443 的 TLS 流程不同。當你發現「同一個網站在某瀏覽器正常、換 Edge／Chrome 或行動版就歪掉」，很值得優先懷疑 HTTP／3 與 QUIC 路徑。
排查時可以暫時在瀏覽器實驗選項關閉 HTTP／3 做對照測試；若關閉後規則立刻命中，幾乎可以確定要從 Sniffer 的 QUIC 設定與相關規則優先級著手，而不是盲目更換節點供應商。
第三步：對齊 TUN、DNS 與 fake-ip，避免「嗅得到卻對不上」
即使 Sniffer 運作正常，若 DNS 模式與 fake-ip 設定和實際流量路徑不一致，仍可能出現日誌裡域名正確、策略卻與預期不符的狀況。請依序自查：應用程式是否真的把流量送進 Clash（TUN 與「僅系統代理」差異極大）；DNS 是否仍繞過核心直連；以及 fake-ip 映射是否在內部快取與嗅探結果之間產生競態。
對遊戲、語音與大量 UDP 場景，也可交叉閱讀 遊戲 UDP 與 TUN 分流排查，裡面對「雙重 NAT、規則順序、直連優先」的討論，與 Sniffer 啟用後的行為是同一條決策鏈上的不同環節。
仍走錯節點：建議檢查清單
- 確認
sniffer.enable為true，且變更後已重載／重啟核心。 - TLS 與 QUIC 埠是否涵蓋實際連線（自架站、企業代理、非 443 服務要手動補）。
override-destination是否依需求開啟；若懷疑副作用，先對單一網域關閉或加入略過清單比對。- 規則順序：網域規則是否早於過寬的 IP／地區規則？是否誤把 CDN 根域與 API 子域寫反？
- 模式：需要全系統接管時，是否已改用 TUN 或等同能力，避免部分程式直連。
- 對照日誌：連線紀錄中顯示的「匹配域名／規則」是否已從純 IP 變成主機名；若仍是 IP，代表嗅探未觸發或被略過。
這類問題最終往往回到一句話：讓核心在正確的時間點拿到正確的域名線索。Sniffer 不是萬靈丹，但對 TLS SNI 與 QUIC 佔比愈來愈高的網路環境，它幾乎是進階分流必備的官方能力之一。
相較於手動把所有目標改成 IP 規則，或到處堆疊巨型規則集，把 Sniffer、DNS 與 TUN 的關係一次釐清，長期維護成本通常更低；而圖形用戶端若能清楚呈現「嗅探後命中的網域」與實際策略，也能顯著縮短你半夜對著日誌猜測的時間。