更近的 VPN 出口并不自动更快

有三个条件决定更近的出口是否有用：你流量的远端究竟在哪里，从出口到那个远端的路径是什么样，以及你的测量反映的是应用而不是隧道。地理只说明第一条，而且只是大致说明。地图上没有任何东西能告诉你某个网络会从某个城市怎么路由。

附近的服务器是合理的先验假设，而不是测量结果。

延迟要端到端地测

你的流量经过三段：从你到 VPN 端点，穿过隧道，再从出口前往目的地。距离影响第一段和第三段，隧道还会增加一点处理。地图上很短的一跳，在网络里仍可能是很长的路由，因为服务商在两个邻近城市之间选择的路径可能绕经第三座城市。把国家标签只当作关于第一段的提示。

出口之后的路往往是更大的一项，尤其当目的地坐落在另一个大洲，或者藏在从意外地点作答的 CDN 后面时。这就是为什么位于目的地自身网络上的出口，常常胜过只是离你更近的出口。

挑两个候选，只改一个变量

让目的地、你的接入网络和传输方式保持不变，然后用一个近处出口对比一个合理的备选。记录端点本身而不是国家，因为同一标签下的两个出口可能位于不同网络。如果测速工具在你的地址变化后悄悄换成了另一个测量主机，也要记下来，因为这会让比较失去意义。一次只改一处，这就是全部方法。

备选出口获胜，说明这条特定路径适合这项特定任务。它并不指明哪一环该负责，而且排名可能在一周内反转。

仔细读 ping 的输出

ping 和 traceroute 能在一定限度内为比较提供信息。VPN 主机可能忽略诊断包，同时把应用流量转发得很好。中间跳的慢响应并不能证明这一跳转发所有东西都慢，尤其是后面的目的地响应正常时。要按目的地判断，把中间的数字当作背景而不是证据。

IP 查询里出现意外的城市，与延迟是不同的问题。地理位置可能不准，也可能落后于地址变更，而不一致本身并不能证明泄漏。要单独比较观测到的公网地址。

让端点匹配任务

稳定的慢和间歇的尖峰是同一套外衣下的两个问题。前者可能让某个端点不适合任何交互式用途，后者通常可追溯到本地无线、丢包或忙时。当正是上传让链路感觉像死掉时，先看负载下的排队，再去寻找遥远的出口。大文件传输能容忍延迟，而那种延迟会毁掉一次对话。

留一个可用的备选，并在网络或任务变化时重新测试。周二的观察不是端点的永久排名。

为眼前的任务做选择，并记下你测了哪个出口、从哪里测、对的是哪个目的地。