VPN 连接超时：DNS、传输、协商还是登录

“连接超时”是 VPN 客户端能打印出的最含糊的错误。它的意思是某个操作错过了期限，而从名称解析到登录应答的每个阶段都有期限。只显示最后一条消息的客户端让各阶段看起来一模一样，于是人们提高超时、更换端口、重装配置文件，按这个顺序，却什么也没学到。比较各阶段更快：每个阶段失败的位置不同，每种失败留下的证据也不同。

四个阶段，四种不同的失败

即使客户端把顺序藏起来，它也固定不变：名称必须解析，必须向得到的地址建立传输，协议必须协商其参数与密钥，账户必须通过认证。OpenVPN 的 连接故障排查指南 对自家客户端也按同样顺序，其他客户端也大体遵循。第二阶段的超时和第四阶段的超时，除了屏幕上那个词以外毫无共同之处。

在日志里找最后一条表示进展的行，而不是错误之前的最后一行。多数客户端会打印解析出的地址、建立的套接字、开始的握手或认证请求，而那一行之后的阶段就是超时的阶段。

名称解析在任何接触之前就失败

如果端点从未解析出来，客户端就没有可连接的对象，也没有发生任何传输工作。这种失败通常是瞬间的，而不是完整超时，这就是把它与其他情况区分开来的最省事办法。用系统解析器和第二个解析器测试名称，在断定服务器宕机之前比较两个答案。

从论坛帖子复制来的旧地址是看似服务器问题的超时的常见原因，因为该地址现在属于别的东西或什么都不属于。使用运营方当前的配置文件，而不是替换一个曾经可用的地址。ping 没有回应在任何方向都不是证据：许多端点丢弃 ICMP，却服务得很好。

传输建立等待一个不会到来的数据包

当 DNS 正常而客户端仍然耗尽整个超时，传输层就是嫌疑对象。在 TCP 上可以直接测试端口；Test-NetConnection 在 Windows 上或nc -vz 在 Linux 上，它会告诉你是否有东西接受连接，这比 ping 更有用。在 UDP 上无法用同样方式测试，因为该层没有需要完成的握手，这种不对称导致许多错误结论。

TCP 测试能证明的东西有限：接受 443 端口的服务不一定是 VPN 监听者，只有 UDP 的端点没有可接受任何东西的 TCP 端口。把配置文件从 UDP 改写为 TCP 不会在另一端创建监听者；它只改变你的客户端等待什么。如果网络过滤该协议，改动只会在同一阶段产生另一种超时。

强制门户在这一阶段值得单独检查。在门户授权设备之前，出站流量会去往门户，隧道尝试只是挂起。先在浏览器里完成门户，然后再重试，门户仍待处理时不要修改配置文件。

协商和登录意味着服务器作出了应答

一旦隧道到达服务器，客户端开始握手，错误性质就变了。这里的停滞关乎兼容性，而不是可达性：协议版本不匹配、对方不接受的加密或数据通道设置，或者期待服务器不提供的功能的配置文件。OpenVPN 在主要版本之间多次移动协商默认值，以至于为某一代编写的配置文件可以到达服务器却仍然起不来。

认证是最后阶段，也最容易被误读。明确的拒绝就是应答，这意味着路径是通的，问题在身份、证书或账户状态。基于浏览器的单点登录流程是第三种情况：客户端在等你没做的操作，或在等它无法启动的浏览器，在你完成那一步之前什么都不会到来。

在改动重试之前先比较证据

保持设备和配置文件不变，每次只改一件事，从网络开始。如果同一配置文件在手机热点上能连、在酒店 Wi-Fi 上超时，变量是路径而不是服务器。如果到处都失败，变量是配置文件或端点。如果只在一天中的某个时段失败，记下时间戳，在假设任何负载问题之前与服务器侧事件比较。

对于你管理的服务，决定性的比较是尝试到底有没有到达。到达监听者然后停滞的连接属于协商阶段；从未出现在监听者视野中的则是传输或解析问题，再怎么调整重试也动不了它。服务器日志还能把被拒绝的登录和静默丢弃区分开，这正是身份修复与防火墙修复的差别。

记录客户端版本、配置文件名称、带时区的尝试时间，以及第一个有用的错误，而不是最后一行断开。分享摘录前先删除密钥和含凭据的材料。然后做一次有意义的修正并重试，因为更长的期限只对已记录的慢操作有帮助，对错误地址或被封锁的端口毫无用处。