流量嗅探原理

很多人第一次在代理软件里看到「流量嗅探（sniffing）」这个开关，会以为它是某种安全功能，或者是用来「防 DNS 污染」的。其实都不是。这篇就把它到底在做什么讲清楚。

它的本质：补全域名信息的工具

流量嗅探的本质，不是安全功能，也不是为了防 DNS 污染，而是一个补全域名信息、方便代理分流和路由决策的工具。

在很多场景下，应用只会直连一个 IP，比如 142.250.xx.xx，代理层并不知道这是 Google、YouTube 还是别的服务。如果不开嗅探，代理只能看到 IP，规则无法命中，结果就是流量按默认策略走（比如直连），该走代理的没走代理。

开启嗅探后，代理会在连接建立后，读取前面一小段数据，比如 TLS 的 ClientHello，从里面拿到 SNI（Server Name Indication），例如 google.com。

这样即使应用只连的是 IP，代理也能「看懂」真实目标，规则命中，让流量走正确的出口。这就是一个非常典型、而且完全合理的嗅探使用场景。

这也是为什么很多人误以为嗅探是「防 DNS 污染」的原因。实际上它并没有修复 DNS，也没有阻止假 IP 的返回。

它只是绕过了「对 DNS 结果的依赖」：哪怕 DNS 被污染了，只要 TLS 里的 SNI 还是真域名，嗅探依然能识别目标站点，从而把流量正确交给对应策略。这叫绕开 DNS，不叫解决 DNS。

在普通代理环境里，「代理 + 嗅探」是完全没问题的。浏览器发请求，代理读取 Host 或 SNI，判断目标，再转发给网站，一切正常。

嗅探真正需要理解的地方，在于它拿到域名之后用来干什么。这里有两种截然不同的行为：

destOverride（改写连接目标）：嗅探出域名后，用这个域名去重写 outbound 的目标——把原本「连某个 IP」的语义，变成「基于域名发起连接」，甚至可能触发重选出口或重建连接。这一步是主动干预连接语义：哪怕最终连的还是同一个 IP，TCP 行为、TLS 时序、首包特征都已经不再是「原样直达」。
routeOnly（只读判断）：仍然会嗅探、仍然读 ClientHello、仍然解析出域名，但这个域名只用于路由规则判断。真正的 TCP 连接仍然使用最初的目标 IP，不会被重写，不会重建 outbound，不会替换连接语义，TLS 数据原样透传。

换句话说，routeOnly=true 把嗅探从「会动手的代理逻辑」，降级成了「只读的策略判断工具」。

对绝大多数上网场景，destOverride 和 routeOnly 没有肉眼可见的差别。但对连接透明性要求极高的下游（例如 Tor、某些透明代理链路），差别是决定性的。

这类系统有一个核心前提：前级网络不应该理解我在做什么，更不应该基于理解结果来改变连接方式。当前面放一个会解析 ClientHello、并根据结果去改写连接目标的代理时，下游会把它当成中间人分析行为，从而拒绝或异常。

真正破坏透明性的，不是「嗅探看了一眼数据」，而是「嗅探结果被用来改写连接目标（destOverride）」。开启 routeOnly 之后，前级网络不再「因为理解我而改变我」，它看到的连接又变回一个干净、透明的 TCP 管道，一切恢复正常。

流量嗅探本身不致命，destOverride 才是——它不能接受的不是被观察，而是被理解之后再被干预。