VPN连接建立到底在做什么
点击客户端的连接按钮后，状态图标往往要经过几秒甚至十几秒才会变绿，这段等待时间对应的正是一次完整的VPN连接建立过程：客户端依次完成节点寻址、传输层连接、密钥协商、身份验证和虚拟网卡配置，全部阶段成功后，图标才会切换为绿色。
第一步：寻址与传输层连接
整个连接过程可以拆解成几个前后衔接的阶段，不同协议的具体实现略有差异，但大体顺序是一致的：
- DNS解析或节点选择：确定要连接的服务器地址
- 传输层连接：TCP完成三次握手，或UDP直接开始发送数据包
- 密钥协商：双方在公开网络上生成一份只有彼此知道的会话密钥
- 身份验证：确认服务器（有时也包括客户端）的身份没有被冒充
- 虚拟网卡与路由配置：操作系统建立隧道接口，把流量导入加密通道
- 首包确认：一段测试流量成功往返，客户端才会把状态标记为已连接
DNS解析与节点选择
客户端发起连接前，首先要确定连接哪一台服务器。对于按域名接入的线路，这一步是标准的DNS解析，把域名换算成可路由的IP地址；不少客户端还会在此基础上做一次轻量测速，在多个可选节点里挑一个延迟较低、负载较轻的入口，这也是为什么同一账号在不同时间连接，分配到的服务器可能不一样。节点选择策略通常写在本地配置或控制服务器下发的列表里，与后面的加密协商是完全独立的两个环节。
传输层握手：TCP三次握手与UDP的直接起步
如果隧道协议基于TCP传输，客户端要先完成经典的三次握手：SYN、SYN-ACK、ACK，确认双方都具备收发能力后才能往上层传数据，这一步单独就要消耗一次网络往返。而更多现代VPN协议——包括WireGuard和大多数IKEv2实现——默认走UDP，没有前置握手，客户端直接把第一个协商包发出去。省下的这次往返，正是UDP类协议连接速度普遍更快的原因之一，代价是丢包、乱序需要上层协议自己处理。
第二步：密钥协商与身份验证
如果说上一步只是打通了一条能收发字节的通道，这一步要解决的才是VPN真正的核心问题：如何在一条谁都能监听的网络链路上，协商出一份只有客户端和服务器知道的密钥，并确认对方不是冒充的。
密钥交换：在公开网络上生成共享密钥
这一步普遍依赖Diffie-Hellman密钥交换及其椭圆曲线变体ECDHE。巧妙之处在于，双方各自生成一个随机数，只公开交换计算后的结果，即便通信过程被完整监听，也无法仅凭公开信息反推出共享密钥。相比早期TLS版本里用服务器公钥加密传输密钥的RSA方式，ECDHE多了一个重要特性——前向保密：就算服务器私钥今后泄露，过去被截获的流量依然无法被回溯解密。这也是TLS 1.3废弃RSA密钥交换、只保留(EC)DHE类算法的原因。
身份验证：证书链在核实什么
密钥协商解决的是保密性问题，但没有解决另一个问题：此刻连接的到底是不是真正的服务器。如果没有身份验证环节，中间人完全可以伪装成服务器，把整套密钥交换流程重新做一遍。基于TLS的协议会校验服务器证书——是否由受信任的证书颁发机构签发、域名是否匹配、有效期是否在范围内，层层验证形成一条信任链。WireGuard换了一种思路，不依赖证书体系，而是提前在双方配置里登记对方公钥，连接时用私钥签名证明身份，验证逻辑更轻量，但需要提前完成一次公钥交换。
把不同协议、不同场景下的握手过程换算成网络往返次数，更容易直观比较连接速度的差异：
| 握手类型 | 典型往返次数(RTT) | 是否需要重新验证身份 | 相对耗时 |
|---|---|---|---|
| TLS 1.2 完整握手 | 2 RTT | 是 | 基准水平 |
| TLS 1.3 完整握手 | 1 RTT | 是 | 明显更快 |
| TLS 1.3 会话恢复(PSK) | 0-1 RTT | 否，复用此前凭证 | 最快 |
| WireGuard Noise握手 | 1 RTT | 是，流程轻量 | 快 |
| IKEv2完整握手 | 2 RTT(IKE_SA_INIT+IKE_AUTH) | 是 | 中等 |
| IKEv2 MOBIKE重连 | 约1 RTT | 否，仅更新地址 | 快 |
第三步：隧道成型与断线重连
密钥协商和身份验证通过之后，剩下的工作是把这条逻辑上的加密通道，真正接入操作系统的网络栈，并在之后可能出现的短暂掉线中尽快恢复。
虚拟网卡、路由表与重连时的会话恢复
客户端会创建一块虚拟网络接口（常见命名如tun0、utun，或WireGuard自己的接口），从服务器地址段拿到内网IP，并修改路由表，把流量指向这块虚拟网卡。协议栈随后发送探测流量，确认数据包能经隧道跑通一个来回后，图标才会真正变绿。此后若因网络切换或短暂丢包断线，多数现代协议提供会话恢复：TLS可用会话票据或PSK跳过完整证书验证，MOBIKE扩展只更新地址、不必重做IKE_SA_INIT和IKE_AUTH，WireGuard握手足够轻量。这些机制的共同点，是把建立信任这件事尽量只做一次。
对开发者意味着什么：长任务为何对重连速度敏感
这一层机制对使用Claude Code、Cursor这类AI编程工具的开发者尤其相关。一次长任务可能让Agent连续调用外部接口、拉取依赖、跑测试，持续几分钟到几十分钟，中途一旦VPN连接被网络切换或短暂丢包打断，如果客户端只能走完整握手——重新做密钥交换和证书验证，再等路由表重建，几秒中断很容易拖成十几秒甚至更久，足够让时间敏感的调用因超时失败，任务不得不从头重跑。这段耗时主要来自身份验证和密钥协商两步，而非传输延迟本身，能否复用会话、跳过完整握手，直接决定断线后是几秒回来还是几十秒回来。
总结
VPN连接建立要经过寻址、握手、密钥协商、身份验证、隧道接管几个阶段。重连快慢取决于能否跳过完整握手，NasaCode做了专项优化，让Claude Code、Cursor长任务掉线后能快速恢复。
