如何為低延遲選擇 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 方案，那是另一個問題：這裡有一個只需回答一個問題的測試。