VPN 服务器在线时长：这个数字没有告诉你的事

一份公开节点列表 显示某台服务器的在线时长以周计，于是你选中它，可第一次连接就失败了。这不是虚假宣传，而是向一个衡量其他东西的数字问了错误的问题。在线时长通常表示某个进程、容器或机器自上次启动以来运行了多久，那是发布方基础设施的属性，而不是你到它的路径的属性。把它当作可靠性，与把汽车的里程表当作路况报告是同一类错误。

这个数字衡量什么

在配有现代服务管理器的宿主机上，计数器锚定在一个你确实能读到的事件上：该单元进入活动状态的时间戳，或机器的启动时间。其余都是在这个锚点上做的算术，而锚点的定义因发布方而异。一份列表可能在守护进程重启时清零，另一份在机器重启时清零，第三份则在想要干净图表的操作员手动重置时清零。

systemctl show -p ActiveEnterTimestamp --value openvpn-server@server
uptime -s
systemctl is-active openvpn-server@server

那三条命令回答三个不同的问题，而只显示一个数字的目录无法告诉你它用的是哪一条。因此，在你知道各自以什么为清零点之前，比较两份列表的原始计数器根本算不上比较。

进程可以在线，而路径已经断掉

守护进程在监听。证书有效。该进程已经存活二十三天。这些都不能保证来自你网络的报文能到达它，因为可达性是整条路径的属性：提供商的上行链路、其网络与你网络之间的对等互联、共享中转链路上的拥塞，以及你自己连接前面的防火墙。

服务器也可能在线却毫无用处，原因却在别处。一个接受的客户端远超其带宽承载能力的节点，会显示很长的在线时长，也会带来糟糕的体验，因为计数器并不衡量容量或争用。高在线时长的节点最常以这种方式让人失望：什么都没坏，只是全都忙。

反过来情形也值得记住。一小时前刚重启的节点现在可能完全健康，而按最大数字排序会悄悄把它排除。在线时长不是质量评分，而把它当作质量评分，筛选的是年龄而不是适配度。

新鲜度：报告比你的尝试更旧

公开目录是根据周期性检查生成的页面，而不是实时遥测。你读到的在线时长是在上次刷新时算出的，而你要发起的连接发生在其后。在此期间，提供商可能让一条链路失效、更换证书、迁移地址或下线某个节点，而页面会一直报告最后一次已知的良好状态，直到下一次抓取。

这个空档也会朝相反方向起作用。被报告为宕机的节点可能在报告生成几分钟后就已恢复，所以立刻换一个节点重试并不总是更好的选择。

实用的规则是：每一份被报告的字段都是关于过去的断言。用它来缩小候选清单，然后在你真正关心的时刻，用你自己做的测量去验证。

该测什么

先确定你需要节点提供什么，再针对它测试。如果你需要可达性，向监听端口发起一次 TCP 连接尝试，一秒内告诉你的信息就比任何计数器都多。如果你需要能工作的隧道，就去协商一条。如果你需要可用的吞吐量，就传输真实的数据并测量它，因为连接时间和吞吐量是不同的属性，握手快并不能说明后者。

nc -vz -w 5 vpn.example.net 1194
curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' https://vpn.example.net/
mtr -rwc 20 vpn.example.net

与其相信一次尝试，不如重复测试。可靠性是随时间和条件变化的分布，一次成功的连接只是大小为一时的一个样本。在你实际使用连接的那些小时里做几次尝试，都会以很大的差距胜过多份公开数据。

在不被误导的情况下读公开节点列表

在线时长也不携带任何关于人们通常想要 VPN 提供什么的信息：证书的有效性、出口由谁运营、适用什么 DNS 策略，以及运营方是否保存连接记录。这些是彼此独立的断言，需要彼此独立的证据，而一个很长的计数器不是其中任何一项的证据。节点可以稳定数月，却仍然不适合一项隐私要求。

列表真正起作用的地方是缩小候选范围。按你知道自己需要的条件排序，过滤掉与任务无关地区的节点，然后测试剩下的三四个。记录每次尝试失败在哪一步，而不是只记一个“行或不行”，因为“TLS 握手失败”和“已连接但没有吞吐量”会导向完全不同的结论。

测量路径性能的框架也以更严格的形式提出了同一点：先定义指标、条件和方法，再收集数字。应用到节点列表上，这意味着在线时长字段只是背景。你自己做的测量才是决定。