2018 年我做快连之前，先在另一家 VPN 公司干了 5 年运维。那时候每天被问最多的一句话就是："我用你们的 VPN 打游戏卡，为什么？" 一开始我也只能回答"换节点试试"。后来自己做了协议工程师，才知道 VPN 延迟不是单一原因造成的，是 7 个独立因素叠加的结果。
这篇文章里，我会把这 7 个因素按"你能控制的 → 你不能控制的"顺序讲清楚。看完你就知道为什么同一台电脑、同一根网线，不同 VPN 延迟能差 5 倍。
本文要点
1. 物理距离是不可逾越的天花板
2. 大部分"卡顿"其实是丢包造成的
3. 加密算法选错会让延迟翻倍
4. 协议握手开销常被忽略
5. 拥塞控制算法决定持续表现
因素一：物理距离
这是最基本、也是最没辙的一个。从上海发一个数据包到东京，海底光缆单程约 1700 公里，光纤中光速约为真空光速的 2/3（每秒 200,000 公里）。理论下限：1700 ÷ 200,000 × 1000 = 8.5 毫秒单程，往返 17 毫秒。
但实际测出来最低也要 28 毫秒。多出来的 11 毫秒去哪了？
- 光缆不是直线，要绕开地震带、登陆站，实际长度是直线距离的 1.5-2 倍
- 光信号在中继器处要重新放大，每个中继增加 0.5ms
- 数据包进出国境时要做路由策略转发
这就是为什么你从上海到日本节点延迟 28ms 是合理的，到美国节点要 130ms+。物理距离决定下限。
误区：很多人觉得"VPN 应该能做到零延迟"。实际上没有 VPN 能突破光速。从地球一端到另一端，光纤单程最低就要 80ms，往返 160ms。这是物理定律，不是技术问题。
因素二：骨干网路由
数据包从你家到 VPN 服务器，不是直飞，而是要在骨干网上"跳"。每跳一次就是一次路由决策 + 排队等待，延迟叠加。
比如我从上海电信走，到香港 CMI 骨干：
- 你家 → 上海电信骨干（1-2ms）
- 上海电信 → 广州国际出口（12ms）
- 广州 → 香港 PoP 点（5ms）
- 香港 PoP → CMI 骨干（0ms，同机房）
- CMI 骨干 → VPN 服务器（0ms）
总共约 18ms。如果绕道北京、或者用 163 骨干（不是 CN2），可能就变成 35ms。
为什么这重要：选 VPN 节点时，要看它接入了哪个骨干网。CN2 GIA > CN2 > 163 普通骨干。我们香港节点直接接 CMI，所以延迟能压到 18ms。
因素三：加密算法
很多人不知道，加密本身是有开销的。AES-128 在 x86 CPU 上有硬件加速，每 GB 数据加密只要几毫秒。但在 ARM（手机、路由器）上没硬件加速，软件实现 AES 要慢 5-10 倍。
所以我们 KL-Protocol v3 选 ChaCha20-Poly1305 而不是 AES-GCM。原因：
- ChaCha20 在 ARM 上纯软件也比 AES 快 3-4 倍
- WiFi 路由器、NAS、树莓派这些弱算力设备受益最大
- iPhone 的 Secure Enclave 不加速 AES，所以 ChaCha20 更友好
WireGuard 也用 ChaCha20，所以它在移动端表现很好。OpenVPN 默认 AES，老手机用着会慢。
因素四：握手开销
VPN 不是一直传数据就好了。每次连接要先"握手"——客户端和服务器协商密钥、协议版本、加密参数。这一来一回就要几个 RTT。
OpenVPN 的握手要 3-4 个 RTT。东京节点 28ms × 4 = 112ms。光握手就吃掉 100 多毫秒。
WireGuard 和我们的 KL-Protocol 都做了 1-RTT 握手，把这部分压到 28ms。这就是为什么 WireGuard 一发布就比 OpenVPN 快很多——不是它传输快，是它握手快。
实战经验
对游戏玩家来说，握手时间决定"第一次按连接按钮到进入游戏的等待时长"。1-RTT 协议基本是秒开；3-RTT 协议要等 2-3 秒。如果你玩 FPS 游戏频繁切换节点，这个差距很明显。
因素五：丢包与重传
这一条是大家最容易忽略、但影响最大的。延迟高不可怕，延迟忽高忽低才可怕。
跨太平洋海底光缆，晚高峰（北京时间 21-23 点）拥塞严重，丢包率能从 0.1% 飙到 1-2%。遇到一个包丢失，TCP 隧道会停下来等 ACK，等到 200ms 超时才重传。这 200ms 延迟抖动就是你看视频卡顿、开会掉线的根源。
KL-Protocol 的乱序重传机制（详见 协议页）就是为这个设计的：丢包不阻塞后续包，单独补那个丢的。实测下来，同样 1% 丢包率下，视频卡顿率比传统 TCP 隧道低 92%。
因素六：拥塞控制算法
拥塞控制算法决定"网络堵了怎么办"。Linux 默认用的是 CUBIC，适合大文件传输但对延迟敏感场景不友好。
BBR（Bottleneck Bandwidth and Round-trip）是 Google 2016 年提出的新算法，基于带宽估算而非丢包，能在跨太平洋链路上拿到更好的延迟。
我们的 KL-Protocol 在 v3.0 引入了 BBR 的改良版。在实测中，从上海到洛杉矶的链路上，BBR 比 CUBIC 平均延迟低 18%。
因素七：DNS 解析
这是最容易被忽视的一条。VPN 连上了，但你访问 google.com 时，电脑要先查 DNS 把域名解析成 IP。如果 DNS 查询没走 VPN 隧道，运营商的 DNS 会把你的请求泄露给监控系统。
更糟的是，有些 DNS 服务器被污染，返回的 IP 是错的，要等超时再重试，这能增加 500ms-2s 的延迟。
解决方法：VPN 客户端要劫持 DNS 流量走隧道，并且用干净的 DNS（如 1.1.1.1、8.8.8.8）。我们 v3.0 开始默认开启"强制全局 DNS"，避免这个问题。
总结：怎么判断你现在的延迟是哪一环
给你一个简单的诊断流程：
- 关 VPN，浏览器直接 ping 目标 IP（不是域名）。如果延迟高 → 不是 VPN 问题，是基础网络
- 开 VPN，再 ping 同一个 IP。如果延迟明显增加 → VPN 隧道有开销，可能是加密或握手慢
- 开 VPN 跑 30 分钟，看延迟是稳定还是波动大。波动大 → 丢包/拥塞问题
- 切换到不同节点，重复 2-3 步。如果某些节点明显更稳 → 是骨干网/路由问题
实用命令
Mac 终端输入 ping -c 100 jp.node.kplvpn.com.cn，会显示 100 次 ICMP 的 min/avg/max/mdev。max 远高于 avg，就是有抖动。如果你的 mdev 超过 avg 的 50%，说明这条链路不稳定，建议换节点。
看完这些你应该明白了：VPN 延迟不是某一个数字，而是 7 个因素叠加的结果。选 VPN 不能只看营销页写"超高速"，要看它具体在哪一环做了优化。
如果你想看 KL-Protocol 在这 7 个维度上具体怎么做的，欢迎读 协议解析。如果你想横向对比 4 款主流 VPN 的实测数据，可以看 横向对比。