Clash Meta Sniffer 开启后 HTTPS 报错？跳过证书与域名排除逐步修复
不少用户在 Clash Meta（Mihomo）里打开 Sniffer（嗅探）后，浏览器或部分 App 突然出现 HTTPS 证书错误、握手失败、或只有特定域名打不开。Sniffer 的作用是在不解密业务 HTTPS 的前提下，从 TLS ClientHello 里读出 SNI 等信息，让基于域名的分流在「只看到 IP」时仍然可靠——但它会改变内核侧对连接目的地的理解方式，也可能与 fake-ip、override-destination 或极少数应用的证书钉扎策略相互作用。本文按先验证、再收敛的顺序，说明如何用 skip-domain（嗅探排除）、何时才考虑 跳过证书验证（skip-cert-verify），以及如何与 DNS 文里的思路衔接排查。
Sniffer 在解决什么问题
在 redir-host 或部分 TUN 场景下，连接在内核里可能先以「目标 IP」形式出现；若规则大量依赖 DOMAIN / DOMAIN-SUFFIX，没有主机名就难以命中正确策略。开启 Sniffer 后，核心会在早期从 TLS 流量中解析出域名线索，使规则引擎有机会按真实访问的站点做决策，而不是仅凭 IP 猜测。
这与「中间人解密 HTTPS」不是一回事：标准 Sniffer 读取的是握手元数据，不是应用层明文。也正因为如此，若你看到的报错是浏览器提示证书与域名不符、证书链无效，往往还要区分：究竟是嗅探与路由改写带来的副作用，还是上游节点、系统时间、订阅 TLS、或目标站本身的问题。
心智模型
把 Sniffer 看成「给连接补全主机名标签」的模块：标签越准，域名分流越好用；但一旦与 override-destination、DNS 映射或客户端自己的校验逻辑打架，就会表现为少数站点异常——这时用排除列表比全盘关闭更利于长期维护。
典型现象：怎样判断和 Sniffer 相关
下面几类情况值得在改规则前先做「开关对比」——同一节点、同一分流，仅切换 sniffer.enable 或 GUI 中的嗅探开关：
- 仅部分域名报错，其余站点正常；关闭 Sniffer 后立即恢复。
- 银行、政务、企业 VPN、部分国产 App 在代理环境下突然无法登录，日志里能看到 TLS 相关失败或反复重试。
- 使用 fake-ip 时，规则依赖域名匹配；开启 Sniffer 后策略命中漂移（该直连的走了代理，或相反），并伴随偶发证书提示。
- 打开
override-destination后问题显著增多——说明「改写目的地」与目标应用的期望不一致。
若关闭 Sniffer 后问题依旧，请优先回到 《DNS 泄漏与 fake-ip 排查》 的路径：核对 dns.enhanced-mode、nameserver 与 fallback、以及系统/浏览器 DoH 是否绕过了内核 DNS。
第一步：嗅探排除（skip-domain）
最稳妥的修复通常不是全局关 Sniffer，而是把已知敏感或不兼容的域名加入嗅探排除，让这类连接不参与（或按内核文档语义跳过）嗅探逻辑，从而避免对目的地解析的额外干扰。各发行版 GUI 可能显示为「跳过嗅探域名」「Sniffer 排除」等，底层多对应配置中的 skip-domain 列表。
写法上常见支持后缀匹配，例如使用 +.example.com 覆盖子域；具体通配规则以你所用的 Mihomo 版本文档为准。下面是一段示意结构，请按本机 YAML 合并位置与缩进调整：
# Illustrative sniffer block — align with your Mihomo version docs
sniffer:
enable: true
sniff:
TLS:
ports: [443]
QUIC:
ports: [443]
skip-domain:
- '+.bank.example'
- '+.internal.corp'
force-dns-mapping: true
parse-pure-ip: false
override-destination: false
实操建议：不要一次性抄超长列表。先在连接日志里确认异常站点的精确主机名，每次加入 1～3 个域名字段，重载配置后复测；稳定后再考虑是否合并订阅或模板里带来的默认排除项。
如何找该填的域名
- 在客户端日志中过滤失败请求对应的 SNI 或 URL 主机名。
- 用浏览器开发者工具「网络」面板查看证书报错页的主文档请求域名。
- 对 App 内嵌网页，优先记录 API 子域，而不是仅记首页域名。
override-destination 与 fake-ip 协同
override-destination: true 会让内核用嗅探到的域名信息去改写连接目标，在部分复杂 CDN 或多证书场景下能改善分流，但也更容易触发「客户端以为连的是 IP / 某一证书 SAN，而实际链路被导向另一路径」的错觉问题。若你刚打开该选项就出现集中爆发，可先回退为 false，确认基线恢复后再单独评估每个策略组是否需要更细粒度域名规则。
fake-ip 与 Sniffer 都是为了让「域名级规则」可用，但组合不当时会出现解析与连接阶段不一致的阅读困难。建议与 同站 DNS 专题 一致：每次只改一个变量——先固定 DNS 模式与 nameserver，再动 Sniffer；或先关 Sniffer 验证 DNS，再开 Sniffer 加排除。
| 选项 | 常见收益 | 常见风险 |
|---|---|---|
sniffer.enable |
补全 TLS 域名，域名分流更准 | 少数站点与嗅探逻辑不兼容 |
override-destination |
修正「只看 IP 走错路」 | 与部分证书校验假设冲突 |
fake-ip |
规则早匹配、体验快 | 与嗅探、Redir 栈组合需对齐 |
何时才谈「跳过证书验证」
社区里常把 skip-cert-verify 当作救命开关，但它几乎总是作用在代理出站（连接你的机场节点或自托管入口）的 TLS 校验上，而不是替代 Sniffer 修复业务站点证书。把它设为 true 意味着客户端不再严格验证与节点之间链路的证书——这会显著增加被劫持或误连伪造入口的风险，只适合短期排障或你完全信任的封闭环境。
更健康的顺序是：先换用证书链完整的节点或端口；检查本机系统时间；确认没有公司安全软件截断 TLS；最后再在单一代理项上临时开启 skip-cert-verify: true 验证猜测。切勿在全局模板里长期扩散该选项。
安全提示
跳过证书验证不是「让网站变可信」，只是跳过到代理节点这一段的校验。业务站点的 HTTPS 仍由浏览器验证；若浏览器仍报证书错，应回到站点本身、系统根证书或是否走了恶意 HTTP 拦截。
图形客户端里改什么
Clash Verge、OpenClash、各 Windows 前端对 Sniffer 的暴露程度不同：有的提供嗅探总开关、TLS/QUIC 端口、跳过列表；有的需要直接编辑原始配置。无论哪种入口，请保持单一真相来源——避免同时在「覆写 YAML」与「订阅合并片段」里重复定义 sniffer，后者可能以你意想不到的顺序被覆盖。
若你刚接触 TUN 或 Meta 内核，可先完成 《Clash for Windows 安装与配置》 或 《Clash Verge Rev macOS》 的基线，再叠加 Sniffer；否则容易把「驱动 / 权限问题」误判成嗅探问题。
常见问题
一开 Sniffer 几乎所有 HTTPS 都红
更像全局网络、系统时间、或订阅节点 TLS 问题。先关 Sniffer 对比；若仍全红，检查节点可用性与端口，排除本地安全软件 HTTPS 扫描。
只有某个 App 不行，浏览器正常
高概率是证书钉扎或 App 自定义校验。对该 App 相关域做 skip-domain，或让该 App 流量 DIRECT 绕过嗅探栈（按你的规则能力选择）。
HTTP/3 / QUIC 异常
若配置了 QUIC 嗅探，可与 TLS 分支分别对比；部分网络环境对 UDP 443 有限速或阻断，现象类似「证书错」实为握手走不完。
实操检查清单
- 记录问题站点的准确主机名与报错文案（截图 + 日志）。
- 仅切换 Sniffer 开关做 A/B，确认因果关系。
- 为该站点添加
skip-domain（或等价 GUI 项），小步验证。 - 检查
override-destination与 fake-ip、DNS 是否同时变动过。 - 仅在指向节点的代理上、短期尝试
skip-cert-verify，确认后撤回或换节点。
用可维护的客户端收敛复杂度
Sniffer 是 Meta 系内核的进阶能力：能显著改善域名分流的命中率，也值得为少数不兼容目标维护一份小而清晰的排除表。把「嗅探开关、排除列表、DNS 模式」写进你自己的配置笔记，下次升级内核或换 GUI 时能快速还原。