先搞懂：嗅探在管线里做了什么

在 TUN、透明代理或 Redir 模式下，内核最先看到的是二元组乃至裸 TLS 记录，并不一定自带浏览器地址栏里的主机名。嗅探模块会在允许的端口上尝试解析 HTTP Host、TLS ClientHello 里的 SNI、以及（若启用）QUIC 相关线索，从而把一个「原本是 IP 的流量」翻译成可用于规则的域名语义。

override-destination（嗅探重写）打开时，内核可能在后续分流阶段优先采用嗅探得到的域名来走 DOMAIN / DOMAIN-SUFFIX 等匹配，而不是死守最初的目标地址字面量。这样做的好处显而易见：Fake-IP 与大量现代网页能重新对齐「人话域名」。代价同样直观：一旦 SNI 与真实业务链路不完全一致——例如前后端分拆、第三方统计域、CDN 别名、握手分片或中间层代答——你就会看到命中了「看起来合理、实际上不是这一条连接该跟的域」，于是出现只坏一部分页面元素、音频能开视频不能开、App 内 WebView 异常而系统浏览器正常等「割裂感」极强的症状。

排查信条 永远以连接日志里的「routing 语义」为准，不以地址栏为准；只要你把嗅探当成可关可开的实验开关，而不是信仰，很多问题会在第一步就露出马脚。

YAML 结构与更多规则写法可参考《Clash YAML 规则分流完全指南》。下面假设你使用 Clash Meta（mihomo）系内核，并已能导入订阅、看到连接日志。

还要注意一类「看起来像 CDN 乱跳、其实是重写抖动」的场景：页面首屏资源由边缘节点 A 承载，音视频或 DRM 许可证却落在节点家族 B；若嗅探阶段抓到的是较早抵达的那一段 ClientHello，而后序连接换了主机名或走了连接迁移，重写域名可能与后续会话不一致。这类问题在流媒体、直播与大型 SaaS 控制台里并不少见，单靠再加一条 DOMAIN 往往治标不治本——必须把重写当成有条件的补丁，而不是全局真理。

第一步：复现问题时，抓住「目标」与「嗅探结果」两列

打开客户端的连接/内核日志视图，在你刷新故障页面的同一秒停止滚动，挑出相邻三到五条 TLS 连接（必要时区分进程）。你需要抄下四类信息：时间戳、原始 destination（若是 Fake-IP，常常是伪造地址池）、嗅探产物或等价字段（有些 GUI 折叠显示）、以及matched rule。

若你发现：matched rule 对应的域名与浏览器开发者工具 Network 面板里的主机名始终对不上，且总是在某个 CDN 后缀家族之间跳转，这已经强烈暗示重写参与了分流决策。反过来，若嗅探字段为空或停留在 IP，而你的规则主要是 DOMAIN 维度，则应怀疑嗅探没生效或被跳过，而非急着追加 IP-CIDR。

这一阶段的产出是一张手写对照表——不必很漂亮，但必须可追溯：后面五步都只是把它填满。

如果你在桌面浏览器「一切正常」，却在某个嵌入 WebView 的 App里看到截然相反的表现，也请沿用同一表格：两类进程的证书校验策略、HTTP/3 启用与否与系统 DNS 缓存往往不同，嗅探重写对它们的影响权重也不对称。先把「出错侧」的连接单独挑出来，再谈规则，不要被「同一个 URL」这个表面现象带偏。

第二步：核对 sniffer 覆盖端口与协议，排除「部分流量根本没嗅探」

并不是所有出站连接都会经过嗅探。TLS与HTTP常见端口若在嗅探配置之外，连接会一直维持 IP 字面形态；而你误以为「嗅探开着」，就会在 Fake-IP 与 DOMAIN 规则之间反复试错。

请逐项核对：

  • 443、8443等 TLS 端口是否在嗅探端口列表内；是否存在自定义 HTTPS 端口遗漏。
  • 站点是否大量使用 HTTP/3（QUIC）——若嗅探侧未覆盖对应路径，表象常为「首个 HTML 正常，流媒体或大文件异常」，因为后续链路走了不同栈。
  • 客户端是否开启了跳过私有地址或等价选项：局域网访问不应被错误重写到公网域名。

配置层级上，你可以在配置文件中找到类似结构的嗅探段落（字段名随内核版本略有差异，以下示例仅供对照语义）：

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports:
        - 443
  force-dns-mapping: true
  parse-pure-ip: false
  override-destination: true

如果你在这一步就发现某些端口压根不在列表里，先把覆盖面补齐再谈重写；否则后面的 Fake-IP 讨论没有意义。

第三步：把 override-destination 当作独立变量做单因子实验

这是本篇最关键的旋钮：嗅探重写是否与当前故障因果相关，要靠对照实验验证，而不是靠社群帖子默认值。

在能够稳定复现的两分钟内：

  1. 保持嗅探总开关与其它字段不变，仅将 override-destination 设为 false（或 GUI 等价选项关闭重写）。
  2. 重载内核配置，清空旧连接缓存（必要时重启客户端）。
  3. 重复第一步抓取同样的三到五条日志。

判读：

  • 若异常站点立刻恢复，而整体上分流仍可接受：说明你此前的 DOMAIN 命中过度依赖重写，或与 Fake-IP 映射交错产生了错误域名优先级。下一步不是简单「永远关」，而是用第五、六步收窄影响面。
  • 若毫无变化：故障主因大概率在 DNS 模式、fake-ip-filter、或更上游的规则顺序，请回到 Fake-IP 专篇与 matched rule 专篇并联阅读。
  • 若旧病好了、新的长尾站点又坏：典型的「重写关与开各救一半」，应通过 fake-ip-filter、sniffer 排除域、或把部分业务改回 IP/规则集策略，而不是反复横跳布尔值。

第四步：对齐 Fake-IP：映射、filter 与「该在什么时候看见真域名」

Fake-IP把大量解析提前收口到内核侧，以降低 DNS 泄漏与路径分裂；但它的代价是：应用层看到的地址与远程真实地址解耦。嗅探重写试图在稍后阶段把语义拉回来——如果拉错，就会出现「分流看着对、证书或 HTTP/3 却打架」的边缘症候。

本步只做三件事：

  • 核对你是否在 fake-ip-filter（或等价名单）里把局域网、分流板、运营商弹窗等应走真实解析的域排除干净；遗漏时常见整类内网域名莫名被送进代理。
  • 在日志中核对：同一域在 DNS 面板与连接面板的出现顺序，是否出现二次改写（先 fake、后嗅探、再匹配）与你脑内模型不一致。
  • 若你对 Redir-Host 与 Fake-IP 的取舍仍犹豫，请先读《Clash DNS 选 Fake-IP 还是 Redir-Host》，再回来改嗅探；否则容易两个旋钮同时旋转，实验读数不干净。

第五步：用「自上而下」的 rules 视角收束 CDN 乱跳

嗅探只是把主机名送进规则引擎的输入侧；真正决定走哪条策略的，仍然是 rules 的自上而下命中一次即停。当你看到 CDN 乱跳时，十有八九是：多条规则都能「说通」不同子域，再叠加上嗅探改写，表象被放大。

请打开《matched rule 与 FINAL 六步核对》中的方法：对故障连接逐条读出 matched rule，回到 YAML 用全文搜索定位「抢答」的那一行。特别关注：

  • 是否有一条过宽的 DOMAIN-KEYWORD / 大后缀 DOMAIN-SUFFIX 横在细规则之前。
  • RULE-SET 插入点是否在想象之外；展开后的条目顺序即真实顺序。
  • 兜底 MATCH / FINAL 是否承担了大量本应显式写出来的长尾主机名——嗅探只是把长尾更名，并不会替你写好细则。

若主机名层面一时难以穷尽 CDN，可考虑阶段性改用更稳健的策略组兜底（例如特定流媒体单独一组），但以日志验收为准绳，而不是迷信超长第三方规则集。

第六步：收敛配置——关掉重写不是认输，而是划定嗅探边界

经过前五步，你通常会得到一张明确的因果表。下面是工程师常用的收敛优先级，从上到下试行：

  1. 收窄嗅探适用范围：只对确有需求的端口与协议启用；关闭不必要的 QUIC 嗅探试探（在某些网络路径上会放大握手差异）。
  2. 维护排除列表：把已知易被错误 SNI 干扰、或必须在公司内部 DNS 场景的域放到 sniffer skip/exclude（字段名随 GUI 而定）。
  3. 分段 override：对绝大多数站点关闭重写，仅在确有 Fake-IP + DOMAIN 对齐刚需的子域局部开启——若客户端不支持拆分，可用规则前置 PROCESS/GEOIP/IP 维度减负。
  4. 抬高观测密度：短期内提高日志级别，抓到一组完整 TLS 握手失败或 RST相邻记录；然后再回到默认级别，避免磁盘写入长期爆表。
  5. 对照 TLS/SNI 专题：若日志提示握手异常或证书链投诉与嗅探时间点重合，接续阅读《TLS 握手失败与 SNI 五步排查》，区分「重写误判」与「节点链路」两类根因。
日志表象 更可能的解释 首选动作
matched rule 域名与站点资源主机名错位 override-destination 改写优先级过高或 SNI 非业务域 第三步单因子关闭重写对照
仅 HTTP/3 业务异常 QUIC 嗅探覆盖或端口不匹配 第二步补齐端口或暂时禁用 QUIC 嗅探试验
同一页面多刷新 matched rule 轮换 多 CDN 主机名未收口 + 嗅探输入抖动 第五步整理 RULE-SET / DOMAIN-SUFFIX 家族
关闭重写后长尾域名大面积掉进兜底 规则缺失而非嗅探坏了 补 DOMAIN 前先验证 DNS 映射是否在 fake-ip-filter

常见问题（正文摘要）

嗅探会加重延迟吗？

握手解析本身占用极小时间窗口；体感卡顿更多来自走错节点、往返地理位置变差或错误的 UDP 路径。请以日志里的 outbound 与 RTT 为准。

GUI 找不到 override-destination 怎么办？

以导出运行中 YAML为准：许多前端只是隐藏字段。你可以在配置文件检索关键字并手动写入后重载；升级内核时注意发行说明是否调整了嗅探默认值。

我是不是应该无脑跟随订阅作者的默认 sniff？

订阅作者的默认值面向大众长尾，不是你的局域网环境与 ISP DNS。把它当作起点，在本篇六步里本地化校准，远比在社交群里追问「哪一个万能模板」更有效。

写在最后：嗅探是工具，重写是双刃剑

Clash sniffing解决的是透明路径下的可读性问题；override-destination解决的是把可读性写回分流决策——一旦出现域名语义抖动，它就会与 Fake-IP、分流顺序在同一管线里相互作用，表象便是你最讨厌的「只坏一部分站点」。把本篇六步固化：锁定日志 → 核对端口 → 单因子重写实验 → 对齐 Fake-IP → 自上而下读 matched rule → 收敛嗅探边界，你会少走大量无效的规则复制粘贴。

最后补一条工程习惯：每次只改一个变量，改完立刻用「同一 URL、同一时间点」的短窗口复测，而不是同时动 DNS 模式、TUN、规则集三路。这样当症状消失时，你能明确知道是重写、Fake-IP 还是某条 RULE-SET 在背锅；下次升级内核或换订阅时，也更容易用同一套表格做回归。把「可复现实验记录」留下来，远比收藏十份 YAML 模板更能救你于线上故障。

相比在各种模板之间跳跃，先在可控窗口内做一次对照实验，再用站内专栏把 DNS、分流日志与 TLS 线索并联，维护成本更低。若你希望客户端安装包与订阅链接维护在单一可信入口，可使用本站下载页获取免费发行渠道并与同伴对齐版本；内核升级路线仍可对照上游文档，但日常下载不建议让读者散落在多处 Release 页面。

→ 立即免费下载 Clash，用支持 Meta 内核与完整日志视图的图形客户端完成嗅探与重写对照实验；先把 Fake-IP 与 matched rule 对齐，再迭代嗅探范围也不迟。

更多教程请浏览技术专栏。