域名嗅探要开启吗？分流作用、识别限制与核对方法

域名嗅探不必一律开启。它可以尝试从连接数据中补充域名，帮助客户端按域名分流；如果当前连接已能正确识别、规则也符合预期，先保留现有配置即可。是否需要它，应由具体异常和对照结果决定。

本文以 Mihomo 内核为例，适用于已经进入客户端的新连接。其他内核、不同版本及客户端界面的选项，需要分别核对，不能直接照搬字段。

嗅探从哪里找到域名？

可以把它理解成查看连接开头的“地址线索”。例如，明文 HTTP 请求可能带有 Host；普通 TLS 握手的 ClientHello 可能带有服务器名称，也就是常说的 SNI。Mihomo 的 HTTP 识别实现和 TLS 识别实现体现了这些处理。

客户端也可能从应用提交的目标信息、DNS 记录或 Fake-IP 映射中获得域名。因此，连接列表显示了域名，不足以证明它来自嗅探。映射机制可延伸阅读本站的 Fake-IP 说明。

普通域名嗅探并不会因此获得 HTTPS 网页正文、密码或完整页面路径。TLS 的数据保密机制与握手中的名称线索是不同层面，相关边界见 TLS 1.3 标准说明。这里讨论的是通常的端到端 HTTPS 连接。

开启本功能也不要求安装根证书。若另一个工具要求导入证书来检查 HTTPS 内容，那涉及额外的解密机制，应单独了解其用途，不能当成本项功能的必需步骤。

同时，域名本身也是访问线索。分享连接截图前仍要检查其中的网站名称、账户标识和订阅信息；正文受到加密保护，并不表示连接记录没有隐私价值。

先检查生效配置，而不只是界面上的勾选状态。按当次核对的 Mihomo 嗅探文档，至少有这些条件：

核对项目	要确认的问题
协议与端口	是否配置了相应的 HTTP、TLS 或 QUIC，目标端口是否在范围内
触发条件	对仅有 IP、或 redir-host 映射的连接，相关设置是否符合需求
排除范围	域名、来源地址或目标地址是否被配置为跳过
连接数据	本次连接是否提供了能被识别的名称线索

其中 parse-pure-ip 面向尚未获得域名的流量，force-dns-mapping 涉及 redir-host 类型识别的流量。它们控制尝试范围，不保证任何连接都能成功还原域名。不要为了一个应用，把所有端口和设备都扩大到尝试范围。

会影响只依赖普通 SNI 提取的判断。ECH 用于保护 ClientHello 中的真实名称等信息，普通嗅探不能凭空恢复受保护的内层字段，见 RFC 9849 的机制说明。

不过，客户端仍可能从 DNS 或应用提供的信息取得域名。记录中有名字，不能证明 ECH 没生效；没有名字，也不能单独证明节点故障。排查应确认信息来自哪里，再决定用什么规则。

override-destination 控制是否将嗅探结果用作实际访问目标。当前实现中，识别结果会记录在 SniffHost；启用覆盖时，还会改写目标主机信息并清除原目标 IP。细节见嗅探调度实现。

另一个容易漏掉的细节是：域名规则取值实现会优先采用已有的嗅探域名。因此，关闭“覆盖目标”也不能理解成“嗅探结果只供展示，绝不影响分流”。

这解释了为什么应分别记录识别名称、命中规则和最终出口。出现变化时，不能只看连接列表多了一个域名，就认定已经修好；还要确认访问结果符合预期。具体行为以所用内核版本为准。

备份当前配置，记录客户端及内核版本。固定目标、节点和连接方式，在规则模式下发起一次请求，记下目标信息、命中规则、出口与实际错误。

按文档检查协议、端口与排除项，再调整需要验证的选项。保持 DNS、节点及规则顺序不变，重新加载配置后建立新连接。旧连接不能代替新设置的验证。

比较域名是否补全、规则是否改变、页面是否恢复。只有特定应用出现异常时，恢复基线，再针对它的目标或来源范围研究排除配置。不要仅凭一条嗅探失败日志，就重置整个系统。

如果域名已经正确而出口仍然不对，继续查规则顺序及策略组选择，可参考本站域名分流规则核对方法。嗅探提供的是判断线索，无法修正写错的匹配范围，也不能保证提速。

作者：小六｜资料核对日期：2026-11-06。

想判断自己的情况是否需要开启嗅探，可以带上内核版本、相关选项及脱敏后的新连接记录，通过 Telegram 联系我交流。无需发送完整订阅或账户凭据。