為什麼開了 TUN，HTTPS 仍常「像只有 IP」？
在規則模式（mode: rule）下，核心需要把每一條連線對應到條件（域名、IP、進程名稱等）再決定策略組。對於 HTTPS，瀏覽器實際連線時先握到的是對端 IP；若此時規則引擎尚未取得與該連線一致的主機名線索，介面上就容易呈現為「目標是某個 IP」，而您寫在設定裡的 DOMAIN／GEOSITE 規則也會無從命中。這與「會不會解密 HTTPS 內容」無關：Sniffer 做的是在允許的範圍內讀取握手階段已存在的資訊（例如 TLS 的 SNI），把「這條連線疑似要去哪個域名」補回規則決策鏈，而不是破解加密載荷。
另一種常見混淆，是把問題歸因於「FakeIP 讓域名變成假 IP」。FakeIP 與嗅探可以並存，但角色不同：DNS 模組負責解析階段的映射與防洩漏；Sniffer 則偏向連線已建立後，在資訊不足時補域名線索。若只調 DNS、不開 Sniffer，部分應用程式的連線路徑仍可能讓規則引擎長時間只看到 IP，這時就會出現讀者描述的「規則寫了卻像沒寫」的體感。
Sniffer 在做什麼？與哪些規則有關？
簡單說：Sniffer是一組流量特徵還原機制，優先從 TLS、QUIC 與明文 HTTP 等來源提取主機名，讓後續的 DOMAIN、DOMAIN-SUFFIX、GEOSITE 類規則有機會在HTTPS 場景下生效。它不取代 PROCESS-NAME（進程規則仍看「誰發起連線」），也不取代 GEOIP；三者是不同維度的條件，可並列寫在 rules: 裡，並遵守由上而下第一筆命中。
若您的主要訴求是「讓某個網站走代理／直連」，且該站是常見的 443／TLS 站，Sniffer 往往是讓域名規則穩定落地的關鍵拼圖之一。相對地，若流量完全沒有可解析的握手資訊、或被您刻意排除在嗅探之外，仍會退回以 IP 為主的匹配路徑。
1前置檢查：TUN、規則模式與 DNS 地基
在啟用 Sniffer 之前，建議先確認三件事：（1）客戶端已用 TUN 或等效方式，讓目標應用程式的流量確實進入核心；（2）mode 為 rule（或您清楚自己在 Global 模式下規則不會被走）；（3）dns 區塊與 fake-ip／redir-host 等選項沒有與您的分流目標互相打架。Windows／macOS 桌面可對照 Clash Verge Rev TUN 模式完整開啟教程；DNS 細節請併讀 Meta 核心 DNS 防洩漏指南。
若您同時需要「某個程式無論連哪個域名都走特定出口」，那是 PROCESS-NAME 按進程分流 的強項；本文則補上「同一條 HTTPS 連線如何讓域名規則看見主機名」這一段。
提醒：嗅探與 DNS 劫持、TUN 路由會改變本機流量走向；與公司資安政策或法規衝突時請勿強行套用。教學僅供合法合規的網路除錯與自用分流。
2開啟 Sniffer：根設定區塊
在完整設定檔的根層級加入 sniffer:（若圖形介面有對應開關，本質上也是寫回同一結構）。下列片段為結構示意：埠範圍請依您環境調整，並與既有 tun、dns 區塊並存而非覆蓋。
# Snippet — merge into full config; comments in English for parser compatibility
sniffer:
enable: true
sniff:
HTTP:
ports:
- 80
- 8080-8880
TLS:
ports:
- 443
- 8443
QUIC:
ports:
- 443
force-dns-mapping: true
parse-pure-ip: true
enable 為總開關。sniff 底下依協定分列要參與嗅探的埠：實務上 TLS 與 QUIC 覆蓋多數現代網站與行動端常見路徑；若您有內網服務使用非標準埠，也可在清單中補上，但請避免過度寬泛導致不必要處理。
force-dns-mapping 意在當嗅探得到域名時，盡量與 DNS 模組的映射關係對齊，減少「嗅探到的名字」與「FakeIP 映射」各說各話的狀況（實際效果仍受完整 DNS 設定影響）。parse-pure-ip 則與僅有 IP 的目的地如何參與後續流程有關，常見於讀者卡住的「純 IP 顯示」情境；若您發現異常路由，請在變更後用日誌對照，再決定是否保留。
3進階：override-destination 與「要不要改寫目的地」
部分版本與圖形介面會提供覆寫目的地相關選項（常見於特定 sniff 子項或全域 Sniffer 設定）。語意大致是：當嗅探還原出域名後，是否要把後續連線決策以域名為準重新對齊。開啟後有時能顯著改善域名規則命中，但也可能在少數應用或內網場景引入意料外的路由；建議以單一變因方式實驗：先只開 enable 與埠，確認日誌出現域名後，再評估是否需要覆寫類選項。
若您使用訂閱或規則集自動產生的設定，請注意 GUI 可能把 Sniffer 相關鍵藏在進階頁；匯出完整 YAML 後全文搜尋 sniffer:，比只在介面上勾選一兩項更不容易遺漏相依設定。
4與域名分流規則的配合：順序仍是王道
Sniffer 解決的是「條件從哪裡來」，不是「哪條規則比較帥」。因此您仍要維持合理的 rules: 排序：通常會把最明確的域名／應用規則放在前段，寬鬆的 GEOIP 或 MATCH 放在後段。若一條很寬的 GEOIP 早於細緻的 DOMAIN-SUFFIX，即使 Sniffer 已還原域名，也可能先被前面的 IP 規則吃掉——這在排查時常被誤判為「嗅探沒開」。
實務上建議把「依依賴嗅探的 HTTPS 站點」整理成一組 rule-providers 或明確的 DOMAIN 列，並在調整期間暫時把 log-level 提高到 info 或 debug，觀察每一條連線最終命中列與還原出的主機名是否一致。
5略過與例外：內網、區網與不信任嗅探的服務
某些環境需要對區網 IP 段、區域服務域名或金融／企業應用停用嗅探或排除在規則還原之外，以避免與內部憑證、分割隧道（split tunnel）或應用自有 DNS 行為衝突。具體鍵名可能隨核心版本演進（例如略過清單、略過來源位址等），請以上游文件與您使用的 Mihomo 版本為準；原則是：能精確縮小範圍就不要全域關閉，保留對公網站點的嗅探能力。
排查：開了仍像沒開時的檢查清單
先看日誌是否出現主機名
將日誌級別調到可讀的除錯資訊後，重新觸發一次目標網站的 HTTPS 存取，確認連線紀錄中是否出現還原後的域名或相關欄位。若完全沒有，回到 TUN／流量是否進核心、以及 Sniffer 埠是否涵蓋該連線。
再對照 DNS 與 FakeIP
當嗅探與 FakeIP 同時啟用時，最難查的是「名字對了、映射錯了」。此時請交叉比對 DNS 教學 中的 enhanced-mode、nameserver-policy 與 tun.dns-hijack，一次只改一個變因。
最後才懷疑規則集過舊或策略組名稱
確認 proxy-groups 內的英文策略名與規則列完全一致；並確認規則集訂閱是否更新。若僅特定網站異常，優先新增單域測試規則驗證，而不是整包重載。
小結：Sniffer 讓「HTTPS 也有域名可供匹配」；TUN 讓流量進核心；DNS 讓名字與映射一致；規則順序決定誰先吃到流量。四件事對齊後，多數「只有 IP、規則不命中」的案例都能收斂。
開源資訊與安裝包取得方式
Mihomo 上游以開源方式維護，需要授權條款、原始碼或議題追蹤時，GitHub 仍是合適資訊來源。日常安裝或更新圖形客戶端，建議優先使用 本站 Clash 下載頁，並搭配 設定說明文件；將「取得安裝包」與「閱讀開源倉庫」分開，可避免誤以為必須自行從 Release 頁拼裝環境。
結語
對 Clash Meta／Mihomo 使用者而言，Sniffer不是炫技開關，而是把 HTTPS 場景拉回「域名分流可讀、規則可維護」的實務模組：在 TUN 與 DNS 地基打穩的前提下，依序啟用嗅探、校準埠與對應選項，再用日誌驗證主機名是否出現，最後才微調規則順序與策略組。相較於反覆堆疊 IP 規則或全域代理，這條路徑通常更省長期維護成本，也更符合「該走代理的站點用域名描述」這一直覺。
若您已能跑通 PROCESS-NAME 與基礎域名規則，把 Sniffer 納入同一套設定哲學，就能把桌面與行動端常見的 TLS／QUIC 流量一併納管。相較於零散工具鏈，同一套核心規則表可與本站 TUN、DNS、WSL2 等文章銜接成完整排查鏈。