为什么「规则写得对」却像没生效？
在 rule 模式下，Clash 家族内核会自上而下匹配规则。若某条连接在决策时携带的主机信息只是一个裸 IP（例如应用硬编码地址、CDN 边沿 IP、或 DNS 阶段与转发阶段信息不一致），那么你在配置里精心维护的 DOMAIN-SUFFIX、DOMAIN-KEYWORD 往往永远轮不到命中，最后只能落到宽泛的 GEOIP 或 MATCH。这类现象在现代浏览器的 HTTP/3（基于 QUIC）上尤为常见：首包未必暴露传统 HTTP Host，而规则引擎又急需一个「像域名一样可用的标识」来做策略。
Clash Meta（mihomo）的 Sniffer（嗅探）要做的，就是在流量已经过内核时，从TLS 的 SNI、QUIC 初始握手等字段里把「真实访问意图」还原出来，再把这个结果交给后续规则匹配。它不是替代 DNS，而是补齐「只有 IP 时怎么分流」这一环。若你刚接触内核分支与配置差异，可先读 Clash Meta 升级指南，确认当前客户端确实基于 mihomo，再继续改 sniffer 段。
启用 Sniffer 之前：先对齐运行形态
嗅探发生在流量经过内核转发路径时。若你只用系统代理、而目标应用根本不读系统代理，相关连接可能完全绕过 Clash，Sniffer 再完善也帮不上忙。实务上多数读者会在 TUN 透明接管或本机 TUN/混合端口 + 全局路由场景下打开 Sniffer；系统级接管与 DNS 细节见 TUN 模式指南。另外请保持 mode: rule（或你确实需要全局时再讨论），否则「分流规则」本身就不参与决策。
DNS 与 fake-ip 仍要单独梳理：嗅探解决的是转发面上的主机名缺失，不是替你把污染或错误解析一并修好。若 DNS 段使用 redir-host 等模式，可与官方文档中的 force-dns-mapping 字段联动理解；下文给出配置时也会点到它与 parse-pure-ip 的分工。
最小可用配置：打开 Sniffer 与三类协议
下列骨架与 mihomo 官方文档「域名嗅探」一致，仅将 enable 设为 true 并按需收紧端口。字段含义以官方 Wiki 为准；升级内核后若个别键名有调整，请以当前版本文档为最高优先级。
# Example sniffer skeleton (mihomo). Tune skip-domain to your LAN / intranet.
sniffer:
enable: true
force-dns-mapping: true
parse-pure-ip: true
override-destination: true
sniff:
HTTP:
ports: [80, 8080-8880]
TLS:
ports: [443, 8443]
QUIC:
ports: [443, 8443]
skip-domain:
- '+.example-lan.local'
skip-src-address:
- 127.0.0.0/8
skip-dst-address:
- 192.168.0.0/16
override-destination：官方说明默认为 true，表示是否用嗅探到的主机名作为后续实际访问目标。关掉它有时用于调试或规避特定应用兼容性，但若你期望「嗅探结果仅用于规则匹配、不改变连接目标」，需要在理解副作用的前提下再改。各协议下的 override-destination 可覆盖全局设置。
parse-pure-ip：对「拿不到域名」的连接尝试嗅探；这正是解决「只有 IP 却想按域名分流」的关键开关之一。force-dns-mapping：面向 redir-host 场景下希望强制走嗅探的补充条件，是否与你的 DNS 段搭配，请对照当前配置逐项验证，避免想当然。
TLS SNI 与 QUIC：分流规则终于能「看见」谁
对绝大多数 HTTPS 站点，客户端会在 TLS Client Hello 里带上 SNI，指明正在访问的证书主机名。Sniffer 读出 SNI 后，内核才能把连接映射到类似 example.com 这样的逻辑主机，从而让前置的 DOMAIN 规则生效。若某些站点或中间设备采用非常规封装，嗅探可能失败——这时应回到日志观察是否出现解析异常，而不是盲目堆规则。
QUIC（HTTP/3）路径上，初始包里同样携带可供识别的目标主机信息；mihomo 在 sniff.QUIC 段声明端口范围后，会对符合条件的 UDP 流尝试解析。与 TCP TLS 相比，UDP 更容易被上游运营商或本地防火墙特殊对待；若你同时折腾游戏语音，请别把游戏 QUIC 与浏览器 QUIC混为一谈——前者往往应优先直连，可参考 游戏 UDP 与 TUN 分流 里的直连思路，并在 skip-domain /地址排除里避免误伤。
skip-domain 与地址排除：防止「该嗅探的没嗅、该跳过的乱嗅」
内网管理地址、银行或企业门户、部分物联网云，如果错误嗅探或错误重写目标，可能出现「能打开登录页却无法跳转」之类诡异现象。官方支持 skip-domain、skip-src-address、skip-dst-address 等过滤维度；域名匹配支持 +.example.com 这类后缀写法（详见 Wiki 语法）。上线 Sniffer 时建议从小范围开始：先只对问题站点验证有效，再逐步扩大端口与协议范围。
skip-dst-address（私网段）往往比写一长串域名更省事，也更不容易遗漏。
分流规则仍要讲究顺序：嗅探不是万能补丁
Sniffer 提供的是主机名信息，最终走哪条策略仍取决于你的 rules 与策略组。若把过于宽泛的 IP-CIDR 或 GEOIP 放在 DOMAIN 规则之前，嗅探结果可能根本没机会参与匹配。这与是否开启嗅探无关，而是典型的「规则优先级」问题；语法与策略组配合请系统阅读 规则分流详解，把专用策略组写在订阅大段规则之前。
实战里推荐为「易出问题的业务」单独建 select 或 url-test 策略组，在 rules 顶部用 DOMAIN-SUFFIX 精确点名，再交给该组；嗅探负责把「本来是 IP 的连接」还原成可点名的域名，两者叠加才有稳定效果。
排查清单：嗅探已开，为什么还不对？
第一步：确认流量真的经过内核
关闭再打开 TUN，或对比「仅系统代理 / 仅 TUN」两种形态。若应用绕过虚拟网卡，Sniffer 不会触发。可结合客户端连接日志观察会话是否由 Clash 创建。
第二步：提高日志粒度，看嗅探是否成功
将 log-level 提到 debug（调试结束后记得收回），关注是否出现与嗅探相关的字段解析失败、被 skip-* 排除、或端口不在 sniff.*.ports 范围内。没有成功嗅探时，不要期待 DOMAIN 规则突然生效。
第三步：核对 DNS 与 fake-ip 是否「帮倒忙」
假 IP、映射表与真实解析混用时，会出现「日志里域名看似正确、应用侧行为却分裂」的情况。此时应回到 dns 段与 fake-ip-filter（或等价配置）逐项收紧，而不是继续堆代理节点。TUN 与 DNS 的联合排错顺序在 TUN 模式指南 中有更系统的叙述。
第四步：审查 override-destination 与应用兼容性
极少数应用对目标地址被重写敏感；若你确认嗅探成功但握手异常，可尝试在理解风险的前提下对特定协议关闭 override-destination，或把该业务加入 skip-domain，观察是否恢复。
第五步：订阅覆盖与客户端合并策略
图形客户端可能在「合并订阅」时把你的自定义 sniffer 段覆盖掉，或把规则插入顺序打乱。每次更新订阅后复查最终运行配置，确认 sniffer.enable 仍为 true，且自定义规则仍在靠前位置。
安全与合规提示
Sniffer 仅解析本机经内核转发的流量元数据，用于本地分流决策；请避免在不可信设备上开启远程管理接口或共享配置。若你在企业网络或学校网络环境，务必遵守当地政策与网络使用规范。本文描述的是开源内核的公开能力，不构成对任何第三方服务条款的解读。
skip-* 列表可能与内网业务冲突。请基于官方文档自行裁剪。
小结
Clash Meta Sniffer解决的是「连接在规则层只有 IP，导致分流规则失明」这一类问题；TLS SNI与 QUIC嗅测让 DOMAIN 类规则重新获得抓手。把它与正确的 TUN/DNS 拓扑、合理的规则顺序放在一起，才能稳定落地；单开开关而不改规则，只会觉得「偶尔有效、偶尔失效」。
相比零散脚本，维护良好的 Clash / mihomo 生态在可观测性（日志、REST 面板）与跨平台客户端配套上更省心：同一套配置可以同时照顾日常浏览、AI 工具分流与游戏直连。若你希望用图形界面管理订阅、策略组、TUN 与 Sniffer 片段，可选择与 mihomo 深度集成的现代客户端；功能说明也可在 使用文档 中先建立全局认识，再回头微调 YAML。