VPN混淆与伪装协议：当流量特征本身成为问题

需要 VPN混淆的场景只有一种：隧道本身没问题，但流量的「样子」被认了出来。这一页先讲 DPI 靠什么识别，再讲两条主流的 VPN混淆技术路线各自的代价。

DPI 是怎么认出 VPN 的

深度包检测（DPI）设备不需要解密就能做出判断，依据分三类：

协议指纹。 每种协议的握手包都有固定结构。WireGuard 的第一个包类型字段固定、长度固定；OpenVPN 的初始报文以特定字节开头；IKEv2 走 UDP 500 —— 这些都是明确的标识。

统计特征。 即便报文内容随机，包长度分布、发送节奏、上下行比例仍然带有模式。一条隧道内的视频流和真实的 HTTPS 视频流，在时序上并不完全相同。

主动探测。 这是最强的一类。检测方发现可疑连接后，主动去连那台服务器，发送畸形或重放的数据，观察它如何回应。学术界对 Shadowsocks 被主动探测识别的研究（IMC 2020）详细记录过这一模式：不同实现对异常输入的响应差异，本身就成了识别依据。

路线一：让流量看起来是随机数据

obfs4 是 Tor 的可插拔传输之一。它给流量加一层「看起来毫无结构」的外壳：握手用带认证的密钥交换，攻击者没有服务器公钥就无法发起有效连接（这直接抵抗主动探测），报文还会插入随机长度的填充。

Shadowsocks 起源于一个简单的加密 SOCKS5 代理，后来演进为使用 AEAD 加密的方案。它的流量在传输中没有可读的协议头，看上去接近随机字节。

这条路线的弱点在于：「完全随机」本身也是一种特征。正常互联网流量很少呈现高熵且无任何协议头的形态，统计上反而显眼。

路线二：让流量看起来就是 HTTPS

TLS 封装 是最直接的做法 —— 把 VPN 隧道整个塞进一个真实的 TLS 连接里。OpenVPN over TCP 443 就是这个思路的简化版；stunnel 一类工具可以给任意协议加上这层外壳。

WebSocket + TLS + CDN。 流量伪装成对某个域名的 WebSocket 请求，并经由 CDN 中转。此时前端看到的是访问一个正常网站的 IP，隐蔽性来自「这个地址确实还承载着大量真实流量」。

基于真实站点的伪装。 更新的一类方案让服务器在收到非法握手时表现得像一个普通网站 —— 攻击者主动探测时，得到的是一个正常网页，从而无法确认这是代理服务。

这条路线的代价是被绑在 TCP 上，以及多一层握手带来的延迟。

一张对比

VPN混淆方案的实际选择

先确认问题出在哪一层。连不上有很多种原因：服务器 IP 被封、端口被封、协议被识别，或者只是线路拥堵。

• 换服务器就好了 → IP 层封锁，不需要混淆。
• 换端口就好了 → 端口封锁，用 443 即可。
• 换什么服务器都在握手阶段失败 → 协议特征被识别，这时才需要混淆。

混淆不是越多越好。每加一层都要付出延迟和带宽的代价，在不需要的网络环境里，裸 WireGuard 永远是更快的选择。