1 为何 TUN/FakeIP 下仍会「走错」策略
分流规则里我们写的是「域名、域名后缀、GeoIP」等逻辑对象；而数据包到达内核时，最初呈现的往往是五元组里的目标地址。在启用 FakeIP 时，浏览器先通过 Clash 的 DNS 拿到一个「假地址」，连接建立阶段内核需要决定：这条连接后续交给哪个策略组、走哪条出站。若此时规则引擎只能看到「某个 FakeIP 段」或「解析得到的 CDN IP」，而没有把连接与「用户心里的那个主机名」绑定起来，就会出现DOMAIN-SUFFIX 明明写了、日志里却像没命中一样的现象——不是规则失效，而是匹配键不完整。
对 HTTPS 而言，真实站点名会出现在 TLS Client Hello 的 SNI（Server Name Indication）字段里。若内核能在握手早期读出 SNI，就可以把「嗅探到的域名」补进路由决策，从而让后续的 HTTPS 分流与你在 rules 里写的域名规则对齐。这正是 Clash Meta（Mihomo）系列里 Sniffer（嗅探）模块要解决的问题：在不替代证书校验的前提下，从明文可见的协议元数据里还原主机名，供规则与策略组使用。
若你更熟悉 DNS 侧防污染与 FakeIP 池配置，可先对照《彻底防止 DNS 泄漏：Meta 内核 DoH + FakeIP 最佳实践配置》建立整体图景；本文则从 TLS 侧补全「域名从哪来」这一环。
2 Sniffer 在做什么：不是抓包看内容
请先把预期摆正：嗅探在这里指的是内核在转发路径上读取协议头里的主机名线索（例如 TLS 的 SNI、HTTP 的 Host），而不是解密 TLS 载荷、也不是替你做中间人审查内容。对绝大多数用户来说，开启 Sniffer 的目的只有一个：让路由与规则匹配使用「和浏览器一致的站点标识」，减少「只有 IP、规则对不上」的错位。
在 Meta 内核中，嗅探模块通常可分别配置对不同协议、不同端口的处理；TLS 与 QUIC 相关选项会直接影响「能否从第一条客户端报文里拿到域名」。若某条连接全程是纯 IP访问、且应用未带 SNI（少数异常客户端），嗅探也可能无能为力——这时仍需依赖你在 DNS 阶段拿到的名字或 IP 规则兜底。
3 如何开启 Sniffer：配置骨架
下面是一段便于对照的 sniffer 配置骨架（字段以你所用的 Mihomo / Clash.Meta 版本文档为准；升级内核后若报未知字段，应以发行说明为准逐条核对）。核心是：enable: true 打开总开关；在 sniff 下为 TLS（及可选的 HTTP、QUIC）声明关心的端口；再辅以与 DNS 行为相关的全局选项。
sniffer:
enable: true
sniff:
TLS:
ports: [443, 8443]
HTTP:
ports: [80, 8080-8880]
QUIC:
ports: [443]
force-dns-mapping: true
parse-pure-ip: true
override-destination: true
force-dns-mapping 与 parse-pure-ip 一类选项，意在让 FakeIP、纯 IP 连接与嗅探结果之间的映射更一致：具体语义随版本迭代可能微调，建议在修改后观察连接日志里「域名 / IP / 策略」三者的对应关系是否符合直觉。图形化客户端若提供「一键开启嗅探」开关，背后通常也是写入同一组键值，手动编辑 YAML 时反而更容易一眼看清全貌。
4 override-destination：要不要用嗅探结果覆盖目标
override-destination: true 常被理解为：当嗅探得到的主机名与「当前连接目标」不一致或不足以做域名规则时，以嗅探到的域名为准参与后续规则匹配。这在 HTTPS 分流场景非常典型——内核最初只看到 FakeIP 或某个 CDN IP，开启覆盖后，SNI 提供的真实域名才能成为 DOMAIN、DOMAIN-SUFFIX 等规则的匹配输入。
若设为 false，嗅探结果可能仍用于日志展示或部分模块，但路由键不切换，你仍会感觉「规则写了域名却不生效」。因此，在确认自己的规则集大量依赖域名、且已排除下文「坑」的前提下，多数用户会打开该选项。若你遇到极少数应用对目标地址被改写敏感，可再针对该场景做分流或关闭嗅探做对比测试——属于高阶排错，而非默认建议。
与 skip 列表、白名单
社区配置里常见 skip-domain、skip-src-address 等跳过嗅探的列表，用于降低开销或避开已知不兼容程序。若你把某类流量整体跳过，对应的HTTPS连接仍可能回到「只看 IP」的老路径，表现为策略组选择与预期不符。调参时建议小步变更：先保证嗅探与覆盖开启，再按需收窄 skip 范围。
5 与 DNS、FakeIP 的配合：两条线拧成一股
DNS 负责「名字解析成什么 IP」；Sniffer 负责「这条 TLS 连接声称要访问谁」。在 FakeIP 模式下，解析结果往往是内核分配的虚拟地址，若不与嗅探联动，规则层容易出现「名字对不上号」。因此实务上常同时检查：dns 段的 enhanced-mode、fake-ip 范围、nameserver/fallback 顺序，以及 sniffer 是否开启、override-destination 是否与你的规则风格一致。
若你发现「DoH 已通、FakeIP 池正常，仍有个站走错」，下一步往往不是再加一条粗规则，而是打开日志看该连接是否已嗅探到 SNI、以及规则匹配时用的是域名还是 IP。把 DNS 教程里的「防泄漏」与本文的「TLS 侧域名还原」合在一起，才算走完HTTPS场景下最常见的两条诊断轴。
6 嗅探结果如何流入规则与策略组
当 SNI 成功解析为域名后，rules 中靠前书写的 DOMAIN / DOMAIN-SUFFIX / GEOSITE 等条目才能按预期命中；命中后再导向你定义的 策略组（例如按地区划分的 select 或自动测速组）。若嗅探未生效，流量可能落入更靠后的 MATCH，表现为「走了全局默认」——这与策略组本身是否健康无关，而是规则前置条件未满足。
因此排查顺序建议为：先确认嗅探与 override是否打开 → 再确认目标域名是否被规则集收录、顺序是否被更早规则抢走 → 最后才调整策略组内节点或 URL-Test 参数。颠倒顺序容易误判为「节点慢」或「规则集垃圾」，而实际问题仍在 TLS 侧域名缺失。
7 常见坑与排错清单
- QUIC / HTTP3：协议路径与经典 TLS over TCP 不同，若未在嗅探配置中覆盖对应端口或协议，可能出现「浏览器走 HTTP/3 时分流与 HTTP/2 不一致」。需结合客户端与内核版本查看 QUIC 支持说明。
- 性能顾虑：嗅探会增加少量 CPU 与首包处理开销；设备极弱时可适当缩小端口范围或跳过局域网段，而非默认全关。
- 规则顺序：过宽的
IP-CIDR或GEOIP写在域名规则之前，会提前截断流量，嗅探再准也进不了域名分支。 - 应用绕过系统代理：部分应用自带直连或自定义 DNS，TUN 未覆盖时仍可能绕过 Clash；需回到 TUN 与进程级接管话题统一处理。
- 版本差异：Meta 内核迭代快，字段名与默认值可能变化；升级后若嗅探异常，先查 Release Note 再改配置。
8 总结
Clash Meta Sniffer 解决的是 HTTPS 分流中最隐蔽的一类问题：规则写得对，但匹配键在 TLS 握手前不完整。通过读取 SNI 等线索，并在合适情况下启用 override-destination，可以让域名类规则与策略组真正接到「用户访问的站点」上。与《Meta 内核 DoH + FakeIP》的 DNS 线、《URL-Test 与 Fallback》的组内线配合，分流体系才算前后贯通。
相比在规则里无限堆叠 IP 段或粗暴全局代理，开启嗅探并理顺 DNS 映射，通常更利于长期维护与排障。一体化客户端在日志与配置编辑上往往更直观；若你尚未安装或希望换用支持 Meta 内核的图形界面，可从本站获取各平台安装包，再按本文检查 sniffer 段是否生效。
需要安装或升级客户端时，请优先使用本站下载页；开源仓库适合查阅协议与提交 Issue，与日常安装包获取路径区分开，更符合版本与安全习惯。
