搜索意图：为什么「只有 IP」会让规则失灵
在规则模式下，内核需要在连接进入策略链时，尽快知道「这到底是访问哪个站点」。对明文 HTTP，早期包头里往往带有 Host；而对 HTTPS，业务数据被 TLS 加密后，若缺少其它线索，内核在部分路径上只能看到对端 IP。此时若你的规则大量依赖 DOMAIN / DOMAIN-SUFFIX，而决策点拿不到域名字符串，就会退而依赖 GEOIP 或更靠后的默认策略，表现便是明明写了分流规则，日志里却像没写。
另一类常见混淆，是把问题全部归咎于「订阅规则不够新」。实际上，若连接元数据里没有主机名，再完整的远程规则集也无法在域名维度命中。Sniffer 并不是替代 DNS，而是给「已经进内核、但暂时只有 IP 表征」的那部分流，补上一把从握手阶段可读字段还原域名的能力；这与 FakeIP 与 DNS 解析链是否一致 强相关，需要放在一起理解。
Sniffer 在 Meta / Mihomo 里具体做什么
Sniffer 会在允许的端口上观察流量的握手特征。对典型 TLS over TCP，客户端在第一个记录里会带上 Server Name Indication（SNI），其中通常包含用户试图访问的域名；对 HTTP/3（QUIC），也有可解析的主机名线索（具体字段随协议与实现演进，以当前内核文档为准）。内核拿到这个「还原后的主机名」后，再交给后续规则匹配与策略组选择，从而使 HTTPS 域名分流在体验上接近「像 HTTP 时代一样按域名决策」。
需要明确边界：嗅探不是解密 HTTPS 内容，也不是中间人攻击；它利用的是握手阶段本就会暴露给路径设备的那部分元数据（在合规与隐私层面，仍应只在自有设备、授权网络内使用）。企业或校园网若禁止此类流量处理方式，请先遵守本地政策，再谈技术细节。
前置：先确认 TUN、规则模式与日志视角
若流量根本没有进入 Meta 内核（例如仅系统代理、且目标进程绕过本地端口），Sniffer 也无从嗅探。实务上多数读者会在已开启 TUN、或确认连接会经过内核透明代理路径后再谈嗅探。TUN 驱动、权限与虚拟网卡冲突，可参考 Clash Verge Rev TUN 模式完整指南 逐步排查。
同时建议在客户端中打开连接日志，观察字段里是否出现 host / 域名类信息。若始终只有 IP，再进入下一节的 YAML 配置；若已有域名但仍走错策略，则更可能是规则顺序或 DNS 与 fake-ip-filter 配置问题，请对照 Meta 内核 DNS 防泄漏指南 中的清单逐项核对。
1在配置中开启 sniffer：可复制骨架
在配置根级增加 sniffer: 段（具体键名以你所用的 Mihomo / 客户端版本为准；升级内核后建议复查发行说明）。下面是一段教学用骨架：端口列表、是否解析纯 IP、是否覆盖目标等选项，应结合你的隐私与兼容性预期调整，不要不经理解整段粘贴生产环境。
# Skeleton — adjust keys per your Mihomo / Meta version release notes
sniffer:
enable: true
sniff:
HTTP:
ports: [80, 8080-8880]
TLS:
ports: [443, 8443]
QUIC:
ports: [443]
force-dns-mapping: true
parse-pure-ip: true
override-destination: false
其中 override-destination 一类开关，决定嗅探得到的域名在后续转发语义上是否覆盖原先仅以 IP 表征的目的地。开与不开会影响少数应用的路径与兼容性：若开启后出现异常回连，可尝试关闭并观察日志差异；这与「仅用于规则匹配显示」和「参与实际选路」之间的取舍有关，不同版本说明可能用词不同，请以官方文档为准。
2与 DNS、FakeIP 对齐：避免「嗅到了却和解析打架」
在 FakeIP 场景下，客户端可能先拿到一段私有地址式的快速应答，再异步解析真实目标；若此时 Sniffer 还原的域名与 DNS 模块记忆中的主机名不一致，就会出现规则忽隐忽现的错觉。做法上，应保持 dns.enable、enhanced-mode（或等价选项）、以及 fake-ip-filter 列表与真实需求一致：需要走真实解析的域名，应进入过滤表，而不是简单全局关闭 FakeIP。
force-dns-mapping 意在让嗅探结果与 DNS 模块的映射关系更一致，但若你的上游 DNS、DoH 路径与 TUN 劫持未对齐，仍可能表现为「嗅探域名对了、出口仍错」。此时不要只旋转 Sniffer 一个旋钮，而应把 DNS 查询是否真的进了 Clash 作为前置条件；涉及 tun.dns-hijack 与劫持范围的内容，同样汇总在 DNS 长文 中。
提示：部分客户端提供图形化「嗅探」开关，底层仍是对上述 YAML 的封装。若你在 UI 里打开嗅探却无效，优先检查配置是否被远程订阅覆盖、本地覆写是否生效，以及是否实际加载了含 sniffer: 的那份配置。
3规则链上的域名分流：顺序仍然是一切
Sniffer 解决的是「有没有主机名可供匹配」；而命中哪一条规则，仍由 rules: 自上而下决定。若你把宽泛的 GEOIP,CN,DIRECT 或远程规则集放在过于靠前的位置，它可能在域名信息尚未参与决策之前就已经匹配成功。建议将你最关心的域名级覆写（个人维护的 DOMAIN-SUFFIX 等）放在足够靠前、且逻辑上安全的区域，并避免与订阅里自动追加的超大规则集产生重复冲突。
若同一目标既可以用进程规则命中，又可以用域名规则命中，应事先想清楚优先级：PROCESS-NAME 适合「按软件」一刀切，Sniffer + 域名适合「同一软件访问不同站点要分流」。两者混用时，务必用日志确认最终生效的第一条规则究竟是哪一类。
4验收：在日志里看到域名再谈「成功」
配置完成后，用一次可控的访问来验证：例如访问一个你明确写了 DOMAIN-SUFFIX 的站点，观察连接记录里主机名是否从纯 IP 变为域名，以及命中的规则名称是否符合预期。若只有部分应用仍显示 IP，可能是该应用使用了非标准端口、ESNI/ECH（视网络与客户端支持而定）、或完全不经由当前 TUN 路径，需要回到应用侧与捕获方式继续细分。
不建议用「网上随机 DNS 泄漏测试」作为唯一判据，那些站点往往看不懂 Meta 内部的 FakeIP 语义。更可靠的是内核自己的日志叙事：嗅探字段、DNS 上游、最终策略组三者是否讲同一个故事。
常见踩坑清单
- 只开 Sniffer 不开 TUN（或流量未进内核）： 握手包根本未经过嗅探引擎。
- 远程配置覆盖： 订阅更新后把本地
sniffer:冲掉，表现为「昨天还行、今天不行」。 - 规则顺序： 宽泛条目抢先匹配，域名规则永远轮不到。
- FakeIP 与嗅探结果不一致： 未维护好
fake-ip-filter或 DNS 策略。 - QUIC / HTTP3： 端口或协议特征未纳入当前嗅探配置，浏览器仍走 QUIC 时只看到 IP。
排查顺序建议
建议固定顺序：① 确认内核已加载含 sniffer.enable: true 的配置；② 在 TUN 或等价路径下复现问题，并截取一段连接日志；③ 核对嗅探字段是否出现；④ 再检查 DNS 与 FakeIP；⑤ 最后微调规则顺序。多数「HTTPS 只有 IP」在①～③ 就能定位，不必急着改订阅或换节点。
合规提醒：请仅在法律与网络使用政策允许的范围内使用代理与嗅探相关能力；他人网络、工作设备上的类似配置可能涉及未经授权的流量处理。
关于下载：开源内核与图形客户端的源码与变更可在 GitHub 查阅；日常获取安装包请优先使用 本站下载页，与仓库 Release 页区分使用场景。
小结
在 Clash Meta / Mihomo 中，Sniffer 嗅探是补齐 HTTPS 域名分流的关键一环：它让规则链在 TLS/QUIC 仍加密的情况下，依然有机会基于主机名做决策。与站内 TUN、DNS、PROCESS-NAME 教程连读时，可以把 Sniffer 理解为「让域名规则重新看得见」的桥梁，而不是孤立开关。
相比在多个工具之间来回改系统代理，把订阅、DNS、嗅探与规则顺序收敛到同一套 Meta 配置里，长期排错成本通常更低；当你用日志把「域名是否出现、第一条命中规则是什么、出口策略组是谁」三件事对齐后，绝大多数「规则写了像没写」的现象都会落到可复现的具体环节，而不是玄学网络。