如何为低延迟选择 VPS 机房位置

有人花几个小时比较 vCPU 数量，最后却把服务器放在了错误的大洲。对于一切交互式的东西（shell、API、游戏、和交易所通信的机器人），位置往往比硬件更重要。好消息是：延迟主要是物理问题，所以你可以在付钱之前预测并测量它。

一句话说清物理原理

光在光纤中每毫秒约传播 200 公里。线缆不是直线铺设的，每台路由器还会增加一点延迟，因此一个可靠的经验法则是：实际距离每 100 公里，往返约 1 毫秒。

再多的 CPU 也解决不了 200 毫秒的往返。如果你的用户在东京，德国的服务器再快也会让人感觉慢。

“近”的含义取决于用途

网站或 API。 靠近大多数用户。CDN 能为静态文件掩盖距离，但首个 HTML 响应、登录、API 调用以及所有动态内容仍然要回到源站。

交易机器人。 靠近交易所的 API 服务器，而不是靠近你。你人在哪里并不重要；机器人每天要和交易所通信数百次。做套利时每几毫秒都很关键；而对于每天只下几单的机器人，30 毫秒毫无区别。更多内容见面向交易机器人的低延迟 VPS。

调用模型 API 的 AI 智能体。 位置几乎无关紧要。模型要花几秒钟才能回答；30 毫秒的网络只是噪声。按价格和隐私来选。

游戏服务器。 靠近玩家。低于约 60 毫秒对大多数游戏来说都很流畅；竞技类射击游戏则要求低得多。

远程桌面和 SSH。 靠近你自己。在 150 毫秒的延迟下打字是一种折磨。

自己动手测

从你自己的电脑，或者从靠近用户的服务器，检查到候选位置的路径：

mtr -rwc 50 example.com

mtr 会显示每一跳的丢包和延迟：比单次 ping 有用得多，因为它能揭示延迟是在哪里增加的。

在 VPS 上，按阶段拆分测量你真正依赖的服务：

curl -o /dev/null -s -w 'dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  total %{time_total}s\n' \
  https://api.example.com/health

connect 大致等于一次网络往返，tls 加上了握手，total 包括服务器自身的处理时间。如果 connect 是 2 毫秒而 total 是 900 毫秒，问题就不在距离。

EQVPS 适合哪些情况

我们的服务器位于德国和芬兰，每次下单都可以选择位置。这能很好地覆盖全欧洲的用户，较好地覆盖中东，并且非常适合欧洲的交易所和 API 端点。芬兰距离西欧远几毫秒，离北欧和波罗的海国家稍近一些；对大多数负载来说两者都可以。

坦白说：我们在亚洲和美洲没有机房。如果你的用户在那里，欧洲的服务器会让每次往返增加 80–250 毫秒，你应该选择离他们更近的托管地点。

简短版

1. 先确定服务器最常和谁通信：用户、交易所、API，还是你自己。
2. 把它放在那个对象附近，按每 100 公里约 1 毫秒估算。
3. 用 mtr 和 curl -w 测量，而不是相信地图。
4. 不要为了解决距离问题去花钱买更快的 CPU。

如果你在为同一台机器纠结选 NAT 套餐还是独立 IP 套餐，那是另一个问题：这里有一个只需回答一个问题的测试。