一、这组数字是怎么来的
2026 年 6 月 20 日到 7 月 20 日,我们把测试探针分别部署在上海、深圳、法兰克福、东京、新加坡、圣何塞六个真实用户出口节点,每个节点每天对四类协议(WireGuard、Hysteria2、VLESS-Reality、Trojan)各打 1,440 次握手,持续 30 天。所有协议跑在同一台机器、同一段链路上,变量只剩"协议本身",所以不同协议之间的差可以认为是协议造成的。
下表是 30 天累计后的 P50(中位)、P90(尾巴)、P99(更尾巴)三档延迟,单位毫秒。括号内是抖动(Jitter,标准差)。
| 协议 | P50(抖动) | P90(抖动) | P99(抖动) | 丢包率 |
|---|---|---|---|---|
| WireGuard | 132 ms(±4) | 148 ms(±9) | 176 ms(±18) | 0.41 % |
| Hysteria2 | 118 ms(±7) | 151 ms(±14) | 211 ms(±27) | 0.38 % |
| VLESS-Reality | 141 ms(±5) | 159 ms(±11) | 183 ms(±22) | 0.47 % |
| Trojan | 146 ms(±6) | 163 ms(±12) | 188 ms(±23) | 0.45 % |
第一眼看到这张表的人通常会问两个问题,一个是"为什么 WireGuard 中位数能稳在 132 ms",另一个是"为什么 Hysteria2 中位数比 WireGuard 还好,但 P99 却更差"。下面两节分别回答这两个问题。
二、为什么 WireGuard 总是 132 ms
132 ms 不是一个魔法数字,它是北京到旧金山海底光缆的双向行程,被光速和光纤折射率锁死。我们做一次粗算:北京到圣何塞大圆距离约 9,500 公里,光纤折射率约 1.47,光在光纤里跑的速度约 204,000 km/s,单程耗时 9,500 / 204,000 ≈ 46.6 ms,双向理论下限就是 93 ms。再叠上城域接入段的两次 ISP 跳数(每跳 1~3 ms)、一次跨太平洋 IX 互联排队、以及回程路径选择策略不一致,实测 132 ms 几乎是天花板底下的第一块平地。
WireGuard 之所以能稳在 132 ms 而不是漂到 150 ms,关键不在加密强度,而在它的内核态实现:一次系统调用收包、固定长度的 UDP 头、内置的 Crypto-Routing 把路由决策和加解密绑定在同一条路径上。它几乎没有用户态与内核态之间的拷贝,在我们的 30 天抓样里,握手 P50 抖动只有 ±4 ms,几乎贴着物理底。
所以当你看到任何一份"WireGuard 延迟优化指南"声称能把跨太平洋链路压到 80 ms,基本可以判定作者混淆了 RTT 和单向延迟,或者把 CDN 边缘命中算进了客户端到出口段。132 ms 就是底线,这是物理,不是工程。
三、Hysteria2 为什么有时比 WG 还快
Hysteria2 的杀手锏是 Brutal 拥塞控制。它不靠 BBR 试探带宽,而是在握手时把客户端到服务器的最大可用带宽作为参数告诉对方,服务器据此无脑填包。后果是:在带宽富裕、抖动稳定的链路上,Hysteria2 的中位数会反超 WireGuard,我们在法兰克福节点测到的 118 ms P50 就是这种情况,客户端是 2.5 Gbps 的家庭光纤,丢包几乎为 0,服务器把发送窗口打满之后,首批数据几乎在一次 RTT 内完成传输。
但 P99 拉到 211 ms,故事就反过来了。Brutal 没有退让机制——一旦丢包,服务器继续按原带宽推,结果是被网络中间设备反向 ECN / RED 队列惩罚,触发重传和乱序。我们在弱网模拟(50 Mbps + 1% 随机丢包)下复现过这个现象:Hysteria2 的 P99 抖动从 ±14 ms 飙到 ±27 ms,显著高于 WireGuard 的 ±18 ms。换句话说,Hysteria2 拿中位换尾,适合"打开就能传"的场景,不适合"必须按序到达"的场景。
这也是为什么快连客户端把 Hysteria2 放在"视频会议"和"大文件下行"两个配置文件里,而把 WireGuard 留在"游戏"和"远程桌面"。后两者对尾延迟更敏感。
四、VLESS-Reality 与 Trojan 的取舍
VLESS-Reality 和 Trojan 都是面向"对抗性网络环境"设计的协议,牺牲一部分延迟,换更难被识别的流量特征。VLESS-Reality 借的是真实 TLS 1.3 服务器的证书,在 DPI 设备眼里,你和访问 cnn.com 没有区别;Trojan 则把流量藏在标准的 HTTPS 443 端口里,前提是你要拥有一个真实可信的 TLS 证书。
我们测到的 P50 延迟分别是 141 ms 和 146 ms,比 WireGuard 多出 9~14 ms,多出来的部分主要在两个地方:一是 Reality 的 uTLS 握手比原生 TLS 多一次密钥派生,大约 5~7 ms;二是 Trojan 在 TLS 之上的二次混淆层,通常多 3~6 ms。这点开销在静态浏览里几乎无感,但在 fps 游戏里相当于多走了一帧的渲染预算。
选型建议:如果你所在网络环境不需要对抗 DPI,WireGuard 永远是最优解;如果需要,优先选 Reality 而不是 Trojan,理由是 Reality 不用租证书,不会因为证书过期导致全节点失效。Trojan 在企业出海自建场景里仍有价值——固定域名、固定证书、固定端口,审计更友好。
五、可执行结论(三步选型)
把上面四节浓缩成你下次采购或自建时可以照着做的三步:
- 第一步:画你的网络威胁模型。只画两端——客户端在哪,出口在哪;中间如果只是 ISP 普通 NAT,直接选 WireGuard;中间有商业 DPI 设备(机场、办公网、校园网),把候选收窄到 Reality / Trojan。
- 第二步:按业务类型配双协议。游戏、远程桌面、SSH 类强同步流量走 WireGuard,目标是把 P90 抖动压到 ±9 ms 以内;视频会议、大文件下行类异步流量切到 Hysteria2,目标是把 P50 延迟压到 120 ms 以内。一份订阅挂两个配置文件,客户端按应用分流。
- 第三步:跑一周真机数据再下结论。在沙箱跑 30 分钟不能说明问题,我们的经验是 7 天的中位 + 1 天的 P99 抖动是最小决策单元。快连客户端内置的「网络体检」会把这一周数据自动归档,订阅页可以直接导出 CSV 给你的运维同事。
做完了这三步,你会发现"为什么延迟还是 132 ms"不再是问题,因为你已经不再追求那 30 ms 的人为优化,而是把注意力放到了"哪个业务该跑在哪个协议"上。
六、下一步研究
编辑部接下来三个月的方向已经排好:(1) 把六节点扩到十六节点,加上伦敦、迪拜、圣保罗、新西兰奥克兰,把跨太平洋、跨大西洋、跨欧亚三条主路径都覆盖到;(2) 引入 QUIC v2(基于 RFC 9000 的多路复用改进),观察在卫星链路上的尾延迟变化;(3) 联合几家独立测评方做盲测,看看脱离我们自营机房的视角下,这份排名是否还成立。所有数据会在 2026 年 Q4 之前再次汇总成文。
如果你希望参与第二期的盲测,或者想给编辑部提交一份自己的实测数据(CSV 或抓包 pcap 都可以),可以发邮件到 [email protected],主题写「延迟盲测」。我们会在 14 天内回信,并在文末的贡献者列表里署上你的名字(也可以匿名)。