VPN「连上要等好几秒」和「连上后传得快不快」是两个不同指标：前者是握手、密钥交换和 DNS 预热带来的一次性建立耗时，后者是隧道稳定后的吞吐量。以 2026 年 9 月常见实现看，握手快的协议不一定吞吐更高，测速时应把两者分开记录。

两个指标分别是什么

一个可独立引用的定义句：连接建立耗时是从点击连接到隧道可以转发第一个数据包之间的时间，主要由网络往返次数和认证步骤决定。

一个可独立引用的定义句：吞吐量是隧道建立后单位时间内实际成功传输的数据量，常用 Mbps 表示，受带宽、丢包、加密开销和节点负载影响。

维度连接建立耗时稳定吞吐量
发生时间每次连接或重连时一次隧道建立后持续
主要单位毫秒到秒Mbps
主要决定因素往返延迟 × 往返次数、认证方式、DNS链路带宽、丢包、拥塞控制、节点负载、加密开销
体感表现「点连接后转圈」「打开第一个网页慢」「下载快不快」「视频清不清晰」
常见误判把等待时间当作网速用第一次测速代表长期水平

延迟也是第三个独立指标，它描述单个往返所需时间，读法见 VPN 延迟怎么看。

首次连接的时间花在哪里

一次典型连接大致经过以下阶段：

  1. 解析节点地址：客户端先把节点域名解析成 IP。本地 DNS 缓存为空时，这一步本身就要一到数个往返；
  2. 握手与密钥交换：双方交换公钥材料，协商会话密钥。每多一次往返，就多一个 RTT 的等待；
  3. 认证：用户名密码、证书或令牌校验。部分服务在这一步还要访问账号服务器；
  4. 配置下发与路由建立：分配隧道内地址、写入路由表和 DNS 设置，操作系统创建虚拟网卡；
  5. 首个应用请求：浏览器通过隧道重新解析网站域名，再完成 TCP/QUIC 与 TLS 握手，才开始加载页面。

一个可独立引用的定义句：握手往返次数乘以到节点的往返延迟，大致决定了密钥交换阶段的最短耗时。

例如到节点 RTT 为 150 毫秒时，两次往返的握手至少需要 300 毫秒。再叠加 DNS、认证和首个网页的 TLS 握手，「从点击到网页出现」花 1 到 3 秒并不罕见。

不同协议的握手往返

协议（以 2026 年 9 月常见实现为例）典型握手往返说明
WireGuard1 个往返握手消息固定且简短，基于预先配置的公钥
IKEv2/IPsec通常 2 个往返证书链较长或使用 EAP 认证时可能更多
OpenVPN（TLS 模式）多个往返先建立 TLS 会话再交换密钥，证书链较长时更慢
基于 TLS/QUIC 的代理协议1 到数个往返取决于是否复用连接、是否启用 0-RTT

具体差异见 WireGuard 与 OpenVPN 对比 和 IKEv2 与 WireGuard 对比。表格只描述握手往返，不代表建立后的吞吐排名。

建立后的吞吐由什么决定

隧道建立后，握手不再参与每个数据包的传输。此时影响吞吐的是：

  • 本地与链路带宽：家宽套餐、Wi-Fi 信号、运营商到节点的国际出口；
  • 丢包与拥塞控制：轻微丢包就会让 TCP 主动降速，带宽时延积大的远距离路径更明显；
  • 封装与 MTU：每个包多出的外层头会减少有效载荷，MTU 设置不当还会引发分片或卡住，见 MTU 不匹配；
  • 加密开销：以 2026 年常见设备看，带硬件加速的桌面处理器通常不是瓶颈；低功耗路由器或老旧手机上可能成为上限；
  • 节点负载与共享带宽：高峰时段多人共用同一出口，可分到的带宽会下降；
  • 传输层：隧道走 TCP 还是 UDP 会影响丢包时的表现，见 VPN 用 TCP 还是 UDP。

重连与会话恢复

连接建立耗时不只在第一次出现。切换 Wi-Fi 与蜂窝网络、休眠唤醒、NAT 映射过期后，客户端都可能需要重新握手。

部分协议支持在一段时间内复用会话或自动续期密钥，重连比首次连接更快。保活包可以减少 NAT 映射过期导致的意外重连，机制见 Keepalive 与断线重连。经常出现「每次切换网络都要等几秒」时，先看的是重连与保活，而不是吞吐量。

怎样公平地读测速结果

做法为什么
连接成功后等待 5 到 10 秒再测避开路由建立、DNS 冷缓存和 TCP 慢启动的影响
同一时段、同一设备、同一测速目标排除高峰拥堵、设备性能和目标服务器差异
每个条件测 3 次以上，记录中位数单次结果波动大，最高值和最低值都不具代表性
连接耗时、延迟、下载、上传分列记录四个指标反映不同问题，不能合成一个分数
先测不开 VPN 的基线判断下降来自隧道还是本地网络
注明测试时间和网络环境结论只对当时的条件成立

记录示例：2026 年 9 月，家庭宽带，同一台 Windows 11 电脑，先测直连基线，再连同一节点，等待 10 秒后连续测 3 次，分别记录连接耗时、RTT、下载与上传 Mbps。

常见误解

误解 1：点连接后等得久，说明这个节点网速慢。
等待时间主要来自握手往返和认证，到节点距离越远，等待越长。它与建立后的吞吐量没有固定关系。

误解 2：握手最快的协议，下载也一定最快。
握手只发生在建立阶段。建立后的吞吐由带宽、丢包、MTU 和节点负载决定，同一协议在不同网络下差别可能很大。

误解 3：第一次测速结果就是真实水平。
第一次测速常受 DNS 冷缓存、TCP 慢启动和客户端初始化影响，应在预热后多次测量取中位数。

评估一个节点前先这样做

  1. 分开记录三件事：连接建立耗时、预热后的 RTT、预热后的下载与上传吞吐；
  2. 每项在同一时段测 3 次以上，写上日期、设备和网络环境；
  3. 连接耗时明显偏长时，先看到节点的 RTT 和 DNS 解析，再看协议握手；
  4. 吞吐偏低时，按带宽、丢包、MTU、节点负载的顺序排查，并与直连基线对照；
  5. 频繁重连时，优先检查保活与网络切换设置，而不是更换节点。