公共 VPN 列表显示在线，你的客户端却说不行

你打开目录，按速度排序，选了一个标记为在线的节点，客户端却在连上之前就放弃了。严格来说，列表并没有撒谎。它报告的是别人在另一个网络、更早时刻对一项随时可能被志愿者关闭的服务所做的探测结果。理解这道落差，就能把令人沮丧的搜寻变成一串可以在任何候选节点上运行的简短检查。

列表究竟测了什么

公共目录保存的字段包括最后检查时间、观测到的往返时延、会话数，有时还有协议列表。这些字段描述的都是项目自己视角下最近一次成功的观测，而不是你的数据包到达时节点的真实状态。

新鲜度比数字更重要。四分钟前检查过的节点和四小时前检查过的节点可能显示同一个绿色标记，而其中只有一个还接近记录中的状态。要看时间戳，而不是颜色。

志愿者运营带来了监控无法修复的第二个变化来源。运营者可能在重启笔记本、带宽耗尽、更换运营商，或者干脆合上盖子。列表条目只是一个候选，把它当成服务等级协议就是范畴错误。

看客户端的阶段，而不是转圈

每个 VPN 客户端都要经过同样的大致顺序：解析域名、建立传输连接、协商安全、完成认证，然后配置隧道并传输数据。每个阶段的失败都会留下不同的证据，而转圈动画什么也不显示。

从域名解析开始。如果主机名无法解析，关于该节点是否可用就什么也没有测到，因为连接从未离开你的机器。接下来是传输：TCP 或 UDP 交换被拒绝或超时，说明端点在那个端口上没有应答，这是关于节点的真实发现。然后是协商与认证，证书错误、配置文件过期或加密套件不匹配都会在这里失败，而节点本身完全健康。只有隧道配置好之后，路由或 DNS 故障才可能解释最后一步。

以屏幕还放得下的最高详细级别阅读客户端日志，记下最后一条成功的行。诊断就从那一行开始，它通常比目录显示的任何内容都更有信息量。

每次尝试只改一个变量

用同一个客户端、同一个接入网络和同一种配置文件格式比较候选节点，只更换端点。否则失败可能出在你这边，你却会把它归咎于节点。

两次尝试就足以建立模式，第三次可以确认。如果节点 A 在传输阶段失败，而节点 B 在认证阶段失败，你面对的是两个互不相关的问题，而不是一份过期的列表。

当所有节点都以同样方式失败

第一阶段普遍失败，指向的是你这一侧：无法应答的解析器、拦截该协议的本地防火墙，或者只允许网页流量的网络。目录无法报告这一点，因为它的探测不是从你的座位发出的。

有意识地测试被塑形的网络。有些接入网络只放行通往网页的 HTTPS，丢弃其他协议，于是列表虽然准确，每个候选看起来都像死了。把浏览器打开页面的结果和一次原始连接尝试对比，不到一分钟就能区分这两种情况。

在失败发生的那一步去读它

在终端里复现这次尝试，让各个阶段可见。下面三条命令分别解析域名、测试端口是否有应答，并打印 OpenVPN 配置文件里的协商行：

dig +short node.example.net
curl -s --max-time 5 telnet://node.example.net:443
openvpn --config node.ovpn --verb 4 2>&1 | grep -iE "TLS|AUTH|PUSH"

如果端口有应答，而协商行报告证书问题，说明节点还活着，你的配置文件过期了。如果端口完全不应答，这条记录就是失败的候选，正确的做法是换下一个，而不是调试你的客户端。用一行短笔记下阶段，下一次尝试就会从知识开始，而不是从希望开始。