Clash Meta 开启 Sniffer 后 HTTPS 仍走错节点？对照 mihomo 日志查 SNI 并修复（2026）

1. 为什么「规则写对」仍会走错：HTTPS 与匹配键

HTTPS 把应用层内容加密后，中间设备默认只能看到五元组、证书链、以及 TLS 握手早期的少量明文字段。对代理内核来说，最棘手的是：某些连接在建立之初只有目标 IP 或内网解析结果，还没有稳定的「域名字符串」可供 DOMAIN / DOMAIN-SUFFIX 规则消费。若此时又启用了 Fake-IP，本地会先拿到一段虚拟地址，再在后续阶段尝试还原真实意图；任一环节不同步，都会出现你肉眼在浏览器地址栏里看到的是 A 域名，内核早期却按 B 或纯 IP 做了一次匹配的现象。

因此，「分流失效」并不总等于「规则写错了」。更常见的根因是：匹配发生时缺少域名键，于是一条过于宽泛的 GEOIP 或 MATCH 抢先命中；或是DNS 与连接阶段使用了不同的解析路径，导致你以为命中了某条 DOMAIN，实际上另一条并行请求已经直连。要把它从玄学拉回工程问题，必须学会在 mihomo 日志里对齐「这一次连接到底用什么键做了路由决策」。若你尚未完成基础订阅导入与模式切换，可先对照 订阅导入教程，再进入本篇的日志细读。

2. Sniffer 在 Clash Meta 里具体补什么（SNI 与路由语义）

Sniffer（嗅探）并不是魔法开关，而是一组「在可控成本内，从明文握手阶段提取主机名信息」的机制。对最常见的 TLS over TCP，客户端在 Client Hello 里会带上 SNI（Server Name Indication），告诉服务器「我想访问哪个虚拟主机」。内核若能读取该字段，就有机会把原本只能按 IP 走的决策改写为按域名再走一遍规则，从工程上补齐 DOMAIN 类规则的输入条件。

需要建立正确预期：SNI 不一定等于浏览器地址栏里的主机名，也不总是与证书 CN/SAN 完全一致；CDN、多域名共用证书、边缘调度域名都可能让你看到「熟悉的站，陌生的 SNI」。因此日志里看到异常 SNI 时，第一反应应是对照真实业务链，而不是立刻删除嗅探。另一方面，嗅探有 CPU 与实现边界，通常建议先用规则顺序与 DNS 收敛问题，仅在仍然出现「明显按 IP 误匹配」时，把 Sniffer 当作诊断与短期兜底，再决定是否在全局长期开启。行为细节与字段名请始终以你所用内核版本的上游文档为准；开源仓库见 mihomo（Clash Meta）GitHub 仓库，与安装包获取渠道无关。

3. 在 mihomo 日志里确认 Sniffer 是否生效

实战里建议你把日志级别调到能看清连接与路由决策的档位（具体选项因客户端封装而异），然后只复现一次问题页面加载，避免并发请求淹没视线。关注三类信息：第一，这条连接最初是否以 IP 目标出现；第二，是否在握手后多出一行与 SNI / sniff / host 相关的字段；第三，最终 rule 命中的是哪一条，对应哪个 策略组。若你始终看不到 SNI 被解析，要么嗅探未开启或被跳过，要么该流量根本不是典型 TLS（例如部分 QUIC 路径需要单独核对内核能力与你是否禁用了 HTTP/3 做对照）。

图形界面若有「连接详情 / 会话列表」，也可以与文本日志交叉验证：同一时刻内核记录的域名键应与规则匹配一致。若界面显示域名正确，但文本日志仍显示长期走 IP 规则，往往说明你看的不是同一跳连接，或存在应用程序并行发起的多宿主请求，其中一条仍落在直连。此时不要急着改 Sniffer，先把日志按时间戳过滤到单标签页、单站点复现。

4. 从一条异常连接反推：SNI → 规则 → 策略组

下面是一套可照抄的逆推顺序。第一步，在日志中找到「结果错误」的那条 TCP 连接，记录它命中的策略与规则类型。第二步，回看该连接在嗅探前后打印的主机名字段：若嗅探前只有 IP，嗅探后出现 SNI，而最终规则仍是 GEOIP 或 IP-CIDR 抢先命中，说明规则顺序需要前移更具体的 DOMAIN，而不是继续堆后缀。第三步，若 SNI 已出现，但命中了错误的 DOMAIN-SUFFIX，检查是否订阅规则集里有更粗粒度的关键字规则与你自定义段落冲突，可参考 高级规则分流指南 里关于「自定义在前、规则集在后」的写作习惯。

第四步，确认该站点是否使用了与你想象不一致的边缘域名：把日志里出现的 SNI 原样加入本地规则做小范围测试，比盲目抄一整份社区列表更有效。第五步，把策略组从 url-test 暂时改为手动 select，固定单一节点复现，排除自动测速抖动造成的「看起来像走错组」。测速与 fallback 的语义若仍模糊，可回到 策略组专文对照。

5. 常见踩坑：规则顺序、Fake-IP、skip 与 override

第一类坑是规则顺序：把大洲级 GEOIP、超大 IP-CIDR 段放在精细 DOMAIN 之前，Sniffer 即便读出了 SNI，也可能已经来不及改变第一次决策——具体语义以你当前内核实现为准，但「越具体的业务域名越靠前」几乎总是更稳妥。第二类坑是DNS 与 Fake-IP：系统 DoH、路由器劫持、或应用自带 DNS 会让「解析路径」和「连接路径」分裂；改完 DNS 段后务必清缓存并重启内核，再抓一份干净日志。

第三类坑是 Sniffer 的 skip 列表：为了隐私或兼容性，配置里可能把某些域名、进程或端口排除在嗅探之外，结果恰好命中你正在调试的站点。第四类坑是对 override-destination（或等价选项）的误解：它改变的是内核如何把嗅探结果映射到后续路由语义，错误组合会让你看到「日志里有 SNI，但策略仍像没生效」。遇到这类情况，建议先只保留最小嗅探开关做 A/B，再逐项恢复高级选项。最后，若问题仅出现在浏览器之外的客户端，记得核对是否必须启用 TUN 才能让该进程的 TLS 流经过内核；可与 TUN 与域名分流专文 中的进程视角对照。

6. 最小 Sniffer 配置片段（对照上游文档微调）

下列 YAML 仅作结构示意，字段名与默认值请对照你所安装的 mihomo 版本文档调整；升级内核后也应复查一次 Sniffer 段落是否被废弃或更名。

sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
  # Add skip-domain / force-sniff etc. per upstream docs

若站点使用非标准端口，记得把端口列表扩写；若你同时调试 HTTP/2 明文升级 或特殊协议，可能需要额外嗅探类型。始终避免在生产配置里长期打开过于激进的调试日志，以免磁盘与隐私成本失控。

7. 排查清单（2026 实测向）