先确认连接已经进入内核
连接记录只有 IP、域名规则没有按预期命中时，才值得检查嗅探。如果目标应用根本没有出现在记录里，应先排查接管方式；开启 sniffer 不会让尚未进入内核的流量自动出现。可以先用本地 Mihomo 实验的方法建立可回退的验证环境。
本文按2026年10月4日核对的官方配置文档解释字段。以下步骤是编辑整理的排错流程，不是设备实测结论。
域名识别不等于改变实际目标
sniffer 可以处理官方列出的 HTTP、TLS 与 QUIC 流量，协议里的 ports 决定检查范围。识别到域名后，是否把它用作实际访问目标，还受到 override-destination 控制。协议内部的同名设置能覆盖全局设置，排查时必须看两层。
因此，记录里出现了域名，只证明获得了可用于判断的信息，不能据此断言目标地址已经改写。嗅探也不是 TLS 内容解密器；不要把它描述成可以读到所有 HTTPS 正文的工具。
对照三个不同开关
| 字段 | 核对对象 |
|---|---|
| enable | 嗅探是否开启 |
| force-dns-mapping | 由 redir-host 识别的流量是否强制嗅探 |
| parse-pure-ip | 尚未取得域名的流量是否强制嗅探 |
如果目标应用使用非配置端口，即便总开关开启，也应先核对协议端口范围。若配置包含 skip-domain、skip-src-address 或 skip-dst-address，还需确认是否主动跳过了目标请求。
用同一次请求比较前后结果
保存原始设置与目标连接记录；先只核对 enable 和协议端口，再发起一个新的请求。旧的长连接可能让你观察到修改前的行为，应在目标应用里重新连接，而不是把所有系统连接一起清空。
记录域名、实际目标与命中的规则，随后检查是否存在协议级 override-destination。确有必要测试覆盖目标时，只改这一项，观察目标应用能否按预期工作，并保留恢复值。不要同时调整 DNS、节点和规则，否则无法解释结果差异。
什么情况下应退回原设置
如果开启后只有特定应用异常，而同一配置下其他请求正常，先检查它是否落在嗅探协议与端口范围，再查看是否适合为该目标设置窄范围例外。没有具体连接证据时，恢复原设置比批量强制嗅探更容易定位原因。
分流结果仍不对，可继续看规则、全局与直连；安装包与内核归属不清楚时，先查Clash 官方项目来源。
一手来源
MetaCubeX：域名嗅探配置。核对协议范围、全局与协议级 override-destination，以及跳过列表。