1. 纯 IP 流量的致命短板与嗅探器诞生背景
在网络分流实战中，传统的规则系统高度依赖域名匹配（如 `DOMAIN-SUFFIX,netflix.com,PROXY`）。
然而在现实网络环境中，存在大量「不走常规域名流程」的流量：
1. **客户端内置硬编码 IP**：Telegram 等应用内部维护了一组海外直连数据中心 IP 列表，登录时不发起任何 DNS 查询，直接向纯 IP 发起 TCP 连接；
2. **应用自身做了 DNS 预解析**：部分流媒体客户端在后台自己提前查好了 IP，发起网络请求时只提供目标 IP；
3. **Redir-Host 模式下的残留流量**。
面对这些只有 IP 地址的数据包，分流引擎只能无奈地将其交给耗时的 `GEOIP` 规则甚至直接滑落至末尾的 `MATCH` 规则，造成分流混乱与跨区串流。**Sniffer 嗅探器就是专门拯救纯 IP 流量的技术核武器。**
💡 Sniffer 只在连接建立的最初一两个数据包中提取明文字段，不解密正文内容，绝不损害通信安全与隐私。
2. TLS Client Hello 报文解析与 SNI 提取机制
虽然 HTTPS 流量的正文内容被强加密算法保护，但在建立 TLS 安全握手的第 1 个包（Client Hello）中，客户端必须以明文形式告知服务器自己想访问的主机名，以便服务器从单 IP 绑定的多个证书中返回正确的那一张（此机制即为 RFC 6066 规范的 **SNI（Server Name Indication）**）。
Mihomo 的 Sniffer 引擎工作流程：
1. 数据包进入内核后，Sniffer 拦截首包并在内存缓冲区中定位 TLS 协议头；
2. 依据 ASN.1 编码规范快速偏移至 Extension 扩展字段列表；
3. 解析出明文字符串（如 `video.netflix.com`）；
4. 将该连接的元数据（Metadata）中的目标主机名强制从空字符串改写为 `video.netflix.com`；
5. 重新将连接送回规则引擎匹配，成功命中流媒体分流规则！
yaml
# 生产级 Sniffer 嗅探配置范例
sniffer:
enable: true
force-dns-mapping: true
parse-pure-ip: true
override-destination: true # 关键：将连接目标重定向为嗅探出的域名
sniff:
TLS:
ports: [443, 8443]
HTTP:
ports: [80, 8080-8880]
override-destination: true
QUIC:
ports: [443, 8443]
skip-domain:
- "Mijia Cloud"
- "dlg.io.mi.com"
- "+.apple.com" # 苹果私有安全握手跳过嗅探，防止证书告警3. override-destination 参数的妙用与避坑
配置中的 `override-destination: true` 是一把双刃剑：
### 核心妙用：
- 当开启此参数时，内核不仅在本地把连接还原为域名进行规则匹配，而且**在发往远程代理节点时，也会将目标地址改写为嗅探出的域名**，交由远端节点在本地进行精准的 CDN 解析。这对于 Netflix、Disney+ 等要求客户端 IP 与 DNS 解析必须同属一个自治域（ASN）的严苛流媒体服务至关重要。
### 防避坑注意：
- 某些特殊的物联网设备（如米家智能家居、某些局域网私有 IoT 设备）使用魔改的 TLS 协议，在 SNI 字段中乱填非标准字符串，如果开启嗅探可能会导致连接超时断开。此时需在 `skip-domain` 中将对应域名加入例外排除。
❓ 常见疑问与排查步骤
开启 Sniffer 会大幅增加系统延迟或 CPU 消耗吗？
不会。Mihomo 使用零拷贝切片技术仅检查首包头部前几个字节，嗅探耗时仅需微秒级（0.005ms 左右），对系统吞吐量几乎无感知。
QUIC 协议嗅探有必要开启吗？
推荐开启。现代 YouTube 和 Google 搜索大量使用 HTTP/3 (QUIC) 协议，开启 QUIC 嗅探能确保 UDP 443 流量同样精准被还原域名。
Telegram 在嗅探开启后能正常走指定代理吗？
Telegram 的 MTProto 协议不包含 TLS SNI，但开启 `parse-pure-ip: true` 配合内置 IP 分类规则（如 GEOSITE,telegram），内核依然能精准将其调度至 Telegram 专属策略组。