Vultr机房怎么选：33个官方ping主机双源实测，哪个对国内最快

Vultr 机房怎么选，中文圈流传最广的那份指南第一步就让你 ping sgp-sg-ping.vultr.com 来测新加坡。这个域名不存在。硅谷的 sjc-ca-us-ping.vultr.com 也一样，两个都解析不到。官方页面上写的是 sgp-ping.vultr.com 和 sjo-ca-us-ping.vultr.com。

照着错地址测，你只会以为是机房挂了。

Vultr 机房怎么选，卡住人的地方通常不是没有地址，是地址不对、数字没有、套餐还可能买不到。2026-10-20 上午，两个中国大陆探测源把 33 个官方 ping 主机全打了一遍，同一轮、同一条命令。这一轮数据能省掉你自己 ping 的功夫，但它只解决三分之一的问题。

一、Vultr 机房怎么选，先接受一个前提：它没有中国大陆优化线路

Vultr 卖的是本地化对等，机房跟当地运营商和交换中心对接，让本地用户访问快。33 个机房里没有 CN2 GIA、9929、CMIN2 这类回国优化线路。

这一点决定了选机房的含义。在别的商家那里，选机房是挑一条好线路；在 Vultr 这里，是在一堆都不快的线路里找绕得最少的那个。

数字上能看出来。广东源最快的是大阪的官方 ping 主机，163.823 ms；北京源最快的是东京的官方 ping 主机，110.278 ms。这是 33 个机房里的最好成绩，也就这个水平。想要三十毫秒的国内访问手感，Vultr 给不了，这不是机房选得对不对的问题。

所以顺序要反过来：先看你从哪个口岸出海，再看机房。

理由在同一张表里。33 个机房里，北京源更快的有 24 个，广东源更快的只有 9 个。最刺眼的是新加坡，官方 ping 主机在广东源 342.495 ms、在北京源 180.351 ms，两源差 162.144 ms。同一个机房，南北两个方向差出将近一倍。照着别人的榜单下单，等于拿别人的口岸替自己做决定。

二、33 个机房、33 个官方 ping 主机：先把地址搞对

33 这个数字以 2026-10-20 的 Vultr 官方机房列表 为准。

官方页面用的是哪几个名字

官方给纽约的标签是 New York Area，主机名前缀 nj-us；旧金山湾区写作 San Francisco Bay Area，前缀 sjo-ca-us，机房名 Silicon Valley，中文习惯叫圣何塞。城市名和前缀不是一一对应，按城市拼会拼错。

下面七个是最容易搞混的，主机名和解析 IP 都是本轮实测解析成功的：

大阪用 osk，米兰用 mxp，曼彻斯特用 man-uk，檀香山用 hon-hi-us。这四个和城市名对不上，照着抄就行。

网上流传的两个错误地址

sgp-sg-ping.vultr.com 和 sjc-ca-us-ping.vultr.com，在探测源上返回 Name or service not known，两个都不解析。这是本轮实测的结果，你可以自己 nslookup 一遍。

范围要说准：那份指南里 hnd-jp-ping、lax-ca-us-ping、sel-kor-ping、fra-de-ping 这些都对，错的只有新加坡和硅谷这两个。整份清单不是全错，别把话说大。

机房数按官方页面核对

17 个、30 个、32 个这三个数字在中文内容里都还在流通，没有一个是当前值。2026-10-20 官方页面写的是 33 regions、33 cities，33 个主机名全部解析成功并且回包，没有一个是空的。判断依据只有一条：官方页面上的 regions 数，加上每个 region 都能解析出一个 ping 主机。

三、实测方法与它测不到的东西

两个探测源与命令

采样时间 2026-10-20 09:10:41，北京时间。

探测源一 cn-probe-1，103.39.226.31，中国广东，电信 AS4816，单线。探测源二 cn-probe-2，8.140.30.240，中国北京，阿里云 AS37963，BGP 多线。

对每个机房官方公布的主机名解析出的地址，两个源各跑 ping -c 20 -W 3，取 ping 自带的 min/avg/max/mdev。路由用 tracepath -n -m 30，取了六个代表机房。

这两个源合起来不是电信、联通、移动各测一条。广东那个是电信单线，北京那个是阿里云 BGP 多线，两个源只能说明两个方向，拼不出一个全国延迟。北京源在 BGP 里选哪条出口，同一轮里对不同目标都不一样：去东京和洛杉矶走 202.97 段，去新加坡、法兰克福、圣保罗、约翰内斯堡走 219.158 段。这本身是数据，但拿它推联通多快、移动多快是过度解读。

ping 主机不等于你买到的那台实例

这条必须放在总表前面，因为它决定了下面所有数字怎么读。

我们测的是 Vultr 官方公布的 <city>-ping.vultr.com，那是官方专门放出来的测试机。它代表该机房对外的网络出口水平，不代表你买到的那台实例的延迟。同一机房不同网段的实例，可能落在不同的上游。

换句话说，表里的数字是这家机房这个出口的水平，不是你手上那台机器的承诺。要判断实例，只能买了之后自己 ping，或者开工单要 looking glass。

三条边界

只有两个源，只有去程，只有一轮采样。这三条限制了结论的强度，但不影响横向比较：33 个机房面对的是同一条命令、同一个时刻、同样的 20 个包。

四、33 个机房双源实测总表

每一行的官方主机名就是上一节核过的写法，可以直接 ping -c 20 复现。延迟单位 ms，丢包列写作广东源 / 北京源。最后一列是北京减广东，正数表示北京源慢，负数表示北京源快。

广东方向的极差是 238.869 ms，一头是大阪的官方 ping 主机 163.823 ms，另一头是约翰内斯堡的官方 ping 主机 402.692 ms。北京方向是 325.301 ms，从东京的官方 ping 主机 110.278 ms 到约翰内斯堡的官方 ping 主机 435.579 ms。北京方向拉得更开，一头更快一头更慢，两头都是它。

两源差最大的是新加坡，官方 ping 主机在广东 342.495 ms、北京 180.351 ms，差 162.144 ms。最小的是墨西哥城，官方 ping 主机广东 226.696 ms、北京 226.562 ms，差 0.134 ms。墨西哥城这个数字有意思：它离两个源都远，远到两个方向的差距被抹平了。

这张均值表里有一行值得停一下：广东源到北美 11 个机房官方 ping 主机的均值 225.033 ms，比亚洲 8 个的 252.713 ms 还低。从广东出海，美西比东南亚近，这不是错觉。北京源反过来，亚洲 172.280 明显优于北美 202.492。

五、33 个机房按四组读表：亚洲近岸 / 北美 / 欧洲 / 其他

分组不按官方大洲，按到中国大陆的距离和出海方向。每组只回答三件事：这一组的共同特征、组内谁值得进候选、谁直接排除。

亚洲近岸（8 个）

东京、大阪、首尔、新加坡、孟买、德里 NCR、班加罗尔、特拉维夫。

地理最近的一组，也是最分裂的一组。大阪的官方 ping 主机两源都稳，163.823 ms 和 176.198 ms，两源 0.0% 丢包，是整张表里少有的两头都不难看的一个。东京反过来，官方 ping 主机在北京源 110.278 ms，是全表最快，但北京源丢包 20.0%，广东源 234.226 ms 也不算好。同一个日本，两个机房两种命运，选东京还是大阪，先看你在南方还是北方。

新加坡是全场两源差最大的地方，官方 ping 主机广东 342.495 ms、北京 180.351 ms。差别在路由上：广东源从 202.97 出去以后接了 62.115 段，一路涨到 350 上下；北京源从 219.158 出去，中间经过 203.208 段，落回来 180 出头。地理上四千公里的距离，广东这边绕出了跨洲的延迟。

印度三城彼此也不一样。孟买的官方 ping 主机北京源 140.664 ms，是这一组北京侧第二好的数字；班加罗尔的官方 ping 主机广东源 345.977 ms，和新加坡一个量级。特拉维夫官方归在亚洲，实际在地中海东岸，官方 ping 主机广东 246.665 ms 带 10.0% 丢包。

想知道日本、韩国、新加坡各自还有哪些商家可选，那是另一件事：日本 VPS 机房怎么选、韩国 VPS 机房怎么选、新加坡 VPS 机房怎么选 讲的是同一地区换商家，这篇讲的是同一商家换机房。

本组进候选的是大阪、首尔和孟买（北京侧），直接排除的是班加罗尔和特拉维夫，理由是班加罗尔的官方 ping 主机在广东 345.977 ms，已经和南美一个量级，特拉维夫的官方 ping 主机在广东源还带 10.0% 丢包，两个都换不来对应的本地价值。

北美（11 个）

硅谷、西雅图、芝加哥、多伦多、亚特兰大、迈阿密、墨西哥城、新泽西、檀香山、洛杉矶、达拉斯。

这一组数量最多，结论也最反直觉：对广东源来说，北美 11 个机房官方 ping 主机的均值 225.033 ms，比亚洲 8 个的 252.713 ms 还低。原因是广东出海到美西走的是直连跨太平洋，而到东南亚反而要绕。

美西三个要分开说。硅谷的官方 ping 主机 167.164 ms / 157.394 ms，两源 0.0% 丢包，是整张表里唯一一个两源都在 170 以内且没有丢包的机房。西雅图的官方 ping 主机 198.599 ms / 163.054 ms，同样干净。洛杉矶最分裂，官方 ping 主机广东 256.822 ms、北京 155.730 ms，两源差 101.092 ms，广东侧是美西三个里最慢的一个。洛杉矶在中文圈的名气最大，数字反而不支持它。

美东和中部合起来看。芝加哥的官方 ping 主机两源 206.849 / 202.624，是中部最均衡的一个。新泽西 229.916 / 234.609，广东侧带 5.0% 丢包。亚特兰大和多伦多的官方 ping 主机数值接近，但都带丢包：亚特兰大广东 15.0%、北京 5.0%，多伦多北京 15.0%。迈阿密的官方 ping 主机广东源 226.531 ms 看着正常，底下是 85.0% 的丢包，这个均值只统计回来的那几个包，参考价值很低。

檀香山官方归北美，实际在太平洋中间，官方 ping 主机 247.987 ms / 229.736 ms，两源都带丢包。墨西哥城的官方 ping 主机 226.696 / 226.562，两源差 0.134 ms，是全场最均衡的一个，对分散在美洲的访客是个不错的落点。

美西与美东各自的横向对比在 美西 VPS 机房怎么选 和 美东 VPS 机房怎么选 里，那两篇换的是商家，坐标不一样。

本组进候选的是硅谷和西雅图，直接排除的是迈阿密，理由是广东源 85.0% 的丢包让官方 ping 主机 226.531 ms 这个均值失去意义，均值只反映成功回包的那部分。

欧洲（9 个）

法兰克福、斯德哥尔摩、阿姆斯特丹、曼彻斯特、伦敦、巴黎、华沙、米兰、马德里。

这一组对国内用户基本是都慢，真正要问的是组内有没有明显更差的，以及它们对欧洲访客值不值。

法兰克福是广东侧最快的，官方 ping 主机 200.869 ms，比北京源还快 32.540 ms。斯德哥尔摩反过来，官方 ping 主机在北京源 187.166 ms，是欧洲组北京侧最快，广东源 214.379 ms。阿姆斯特丹、曼彻斯特、伦敦、巴黎、华沙五个挨得很紧，两源差也都在很小的范围内，选哪个更多看用户在哪，不看延迟。

马德里的官方 ping 主机是组内最慢的，广东 286.863 ms，北京源还带 10.0% 丢包。米兰的官方 ping 主机 268.780 / 218.813，两源差 49.967 ms，是欧洲组里南北分歧第二大的。

欧洲这一组的价值不在回国，在当地访客。国内用户为了欧洲用户建站，法兰克福或阿姆斯特丹是常规答案；只为自己 SSH 用，这一组没有一个是好选择。欧洲 VPS 机房怎么选 里有各家欧洲机房的横向对照。

本组进候选的是法兰克福，直接排除的是马德里，理由是官方 ping 主机在广东 286.863 ms，是组内最慢，北京源还有 10.0% 丢包，两头都不占优。

其他（5 个）

圣保罗、圣地亚哥、墨尔本、悉尼、约翰内斯堡。

这一组的判断标准不是延迟，是有没有必要为了本地用户付这份延迟。

墨尔本的官方 ping 主机 292.403 ms / 238.982 ms，是这一组唯一两源都在 300 以内的。悉尼的官方 ping 主机就难看多了，广东 392.888 ms、北京 231.549 ms，两源差 161.339 ms，广东侧比约翰内斯堡只快一点。澳大利亚两个机房，从广东过去都不轻松，从北京过去差别很大。

南美两个的官方 ping 主机差不太多。圣保罗 350.058 / 347.511，圣地亚哥 354.511 / 362.422，后者北京源还带 5.0% 丢包。约翰内斯堡的官方 ping 主机 402.692 / 435.579，两个方向都是全表最慢，北京源还有 5.0% 丢包。

这五个机房的存在意义是服务本地用户。国内用户选它们，只有在目标客户确实在南美、澳洲、非洲时才成立，否则延迟这一项就足够否掉。

本组进候选的是墨尔本，直接排除的是约翰内斯堡，理由是官方 ping 主机在 402.692 ms 和 435.579 ms 两个方向都是全表最慢，除非你的用户就在南非。

六、路由实测：从 202.97 和 219.158 出海，后半程接到了谁

路由这一段看的是经过谁，不是有多快。跳 RTT 和 ping 均值量的不是同一段路程，直接相减没有意义。本轮六条 tracepath 只覆盖广东源的 202.97 段和北京源的 219.158 段，223.120 段一次都没出现。

电信 163（AS4134 / 202.97 段）

广东源全程走 202.97。到东京是 202.97.12.17（7.015 ms）、203.215.237.130（124.734 ms）、120.88.54.98（234.793 ms），再到 209.222.31.145（238.815 ms）。出海以后那两跳把 RTT 从 7.015 ms 拉到 234.793 ms，绕路就发生在这一段。

到新加坡是同一条 202.97 出口，202.97.43.122 之后接上 62.115 段，一路涨到 350.133 ms。163 的出海点在北上广，出去以后接谁的网，决定了后半程。同一个 163 出口，去新加坡的官方 ping 主机是 342.495 ms，去东京是 234.226 ms，差别出在出海以后接的那一段，不在 163 本身。

联通 4837（AS4837 / 219.158 段）

北京源到新加坡、法兰克福、圣保罗、约翰内斯堡四个方向都从 219.158 出去。到法兰克福是 219.158.18.70、219.158.10.26、219.158.98.6（131.360 ms），接 DE-CIX 的 80.81.196.21（179.692 ms），再落到 108.61.225.49（185.072 ms）。到新加坡是 219.158.4.50（46.729 ms）之后直接跳到 219.158.40.194（268.125 ms），再经 203.208 段回来。

4837 在美西方向被大量使用，原因不复杂：国际段容量大，落地机房多，机房侧接它的成本低。它的短板是国内段各省接入质量不一致，这一点两个源看不出来。

移动 CMI 这一轮没测到。北京源虽然是 BGP 多线、理论上可能选到 CMI，但这一轮的目标里没走 223.120 段，所以这条路径不给任何判断，只把结论留空。

只有两个源，推不出全国结论

广东电信单线加阿里云北京 BGP 多线，这就是全部。北京源同一轮里对不同目标走不同出口：去洛杉矶走 202.97，去新加坡走 219.158。这说明北京源不是一个固定的网络身份，它是阿里云 BGP 选出来的结果。

所以这张表能回答的是两个方向上的差距，回答不了联通用户快不快、移动用户快不快。那需要另外的探测源，本轮没有。

七、同一套餐在不同机房能不能买到：Vultr 的计费、套餐与机房可用性

选机房之前有个前置问题，很多人是付款前一刻才撞上的：你看中的那个机房，根本不卖你要的那档套餐。

先纠正一个误解：Vultr 不是一机房一价

同一档位（Cloud Compute Regular）在多数机房同价。这是它和 RackNerd 那类一机房一价商家的结构差异：RackNerd 每个机房一张价目表，Vultr 是一张价目表铺到多数机房。RackNerd 机房怎么选 那篇里能看到另一种结构长什么样。

但区域定价确实存在

官方页面的说法是，某些位置可能因区域成本不同而定价不同。这句不是免责套话，不能当成全都同价来读。反过来写成都不同价也是过度断言，我们手上没有一份完整的不同定价清单。

落点只有一个：以控制面板为准。看到的价格才算数，Vultr 官方价目页 上的数字是起点，不是终点。

可用档位按机房过滤

真正劝退的地方在这里。同一个套餐，换个机房可能根本买不到，部署页里那一项是灰的。

已核实的一个例子：大阪机房只开 AMD EPYC 和 Intel Xeon 高性能系列，入门档选不了。这条记录来自 2023 年，本轮没有在控制面板里逐项复核，读的时候先按以控制面板为准。High Frequency 和 Optimized Cloud Compute（General Purpose、CPU、Memory、Storage Optimized）覆盖的机房更窄，这个方向是确定的，具体到哪几个机房本轮没核到。

圣保罗、约翰内斯堡这类边缘位置是否上全档位，本轮也没核到。能给的只有一句：下单前先在部署页把机房和套餐一起选一遍，灰的那一项就是答案。

HF 不是 Regular 的升级版同款

High Frequency 用的是 NVMe 加更高主频，是另一个产品档，不是 Regular 换个盘。跨机房比延迟的时候把 HF 的机器混进 Regular 的表里，等于换了变量还宣称单变量对照。

这篇测的是官方 ping 主机，不涉及实例配置，所以不受这条影响。但你如果自己拿两台机器对比，得先确认它们是不是同一档。

出网超量全球统一 $0.01/GB

官方 High Frequency 页写的是 any overage priced at a low $0.01/GB rate worldwide。这是另一件事，和上面几条不冲突：套餐价格按机房可能不同，超量单价全球统一。

换机房到底怎么算钱

流传的换机房一美分不要信，来源不明，也解释不了快照和存储的费用。

实际机制是新建实例、把快照迁过去、删掉旧实例，全程按小时计费。费用取决于新实例开了多久、快照占多大、旧实例还剩多少小时。想省钱的做法是先把快照做好，新机器验证没问题再销毁旧的，别反过来。

以账单为准，这句话在 Vultr 这里不是客套。

八、按业务场景选机房

建站与独立站

读者在海外，就近选。读者在国内，Vultr 不是合适的选择，这一条得说在前面。亚洲机房看着近，广东源到亚洲 8 个机房官方 ping 主机的均值 252.713 ms，比北美还高，近不等于快。

读者在欧美的话，硅谷的官方 ping 主机两源 0.0% 丢包，167.164 ms 和 157.394 ms，是美西里最干净的落点；欧洲访客多就法兰克福。

外贸 B2B

客户分散在欧美和中东，选全球路由均衡的点比选最快的点重要。墨西哥城的官方 ping 主机两源只差 0.134 ms，说明它到两个方向的距离几乎一样，这种均衡在客户分散时是优点。法兰克福的官方 ping 主机在广东侧 200.869 ms，是欧洲组最好，对西欧和中东的覆盖也够。

流媒体与内容分发

不承诺解锁，也不承诺原生 IP 必过风控。能说的只有：IP 归属和网络稳定性会影响平台识别，具体规则由平台制定，商家和我们都决定不了。要判断只能自己拿目标业务试。

AI 推理与 API 服务

看的是出网带宽和套餐档位，不是延迟。超量 $0.01/GB 全球统一，但 HF 与 Regular 的端口规格和流量池不是一回事，先定档位再选机房。机房选在用户附近的意义，在这里比 SSH 手感大得多。

游戏加速与低延迟中转

看 mdev 和丢包，不看均值。迈阿密的官方 ping 主机在广东源丢了 85.0%，就是典型：官方 ping 主机的均值 226.531 ms 看着正常，实际大部分探测包没回来。东京北京源 20.0% 同理，官方 ping 主机 110.278 ms 这个全表最快的数字，是在丢掉五分之一探测包的前提下得到的。

做中转的话，两源 0.0% 丢包的机房才值得考虑，大阪、硅谷、西雅图、法兰克福、斯德哥尔摩都在这个名单里。

九、哪些 Vultr 机房其实不适合中国大陆用户

33 个是可选项数量，不是推荐数量。真正能进中国大陆用户候选池的是个位数，其余要么延迟高一个量级，要么丢包不可接受，要么根本不该为了国内访问去选。

判断依据有四条，都能在表里查。

两源同时偏慢。圣保罗的官方 ping 主机 350.058 / 347.511、圣地亚哥 354.511 / 362.422、约翰内斯堡 402.692 / 435.579，三个机房两个方向都在 347 以上。这类机房不是某一个源不好，是两头都不好，换口岸也救不回来。

有明确丢包。这一条的样本量要交代清楚：每个目标每个源 20 个包，n=20 时一个包就是 5.0%，所以 5.0% 属于噪声，不足以支撑结论。真正值得复核的是下面这七个：

另外还有十个 5.0% 的记录，首尔、德里 NCR、墨西哥城、新泽西、达拉斯、圣地亚哥、悉尼、约翰内斯堡，加上亚特兰大和檀香山的北京侧，都只等于丢一个包，当信号看可以，当结论不行。

ICMP 丢包也不等于 TCP 丢包。部分机房和边缘路由器会对 ICMP 降优先级甚至限速，探测包被丢掉时，TCP 转发未必受同样影响。本轮只做了 ICMP 采样，没有做 TCP 复测，上面这七个数字应该读成需要复核，不是已确认的链路质量。

路由绕行。新加坡的官方 ping 主机在广东侧 342.495 ms 是典型：地理四千公里，实际从 202.97 出去接 62.115 段绕了一大圈，比到美西还慢。悉尼的官方 ping 主机在广东侧 392.888 ms 同理。判断方法是跑 tracepath，看相邻两跳之间有没有从几毫秒突然跳到一百多毫秒，那就是绕路发生的位置。

套餐不开。大阪只开高性能系列这一条，意味着你看中的入门档在那里买不到。买不到比更贵更常见，也比更贵更难提前发现。

四条筛完，剩下的候选基本就是大阪、首尔、硅谷、西雅图、法兰克福这几个，加上洛杉矶和东京这两个带条件的。

十、Vultr 机房 vs 各区域通用选型：两篇怎么分工

分工很简单：这篇是同一商家换机房，区域篇是同一地区换商家。

想知道 Vultr 在东京这个点表现如何，看这篇的亚洲组，官方 ping 主机的数字是 234.226 ms 和 110.278 ms。想知道日本还有哪些商家、各自的东京机房什么水平，看日本那篇。两篇的坐标不一样，结论也不能互相搬。

香港是个例子。Vultr 的 33 个机房里没有香港，为了对比硬拉进来会混淆变量。要看香港本地机房的选择，中国香港 VPS 机房怎么选 是另一套数据，那边测的是香港本地商家，延迟量级和这篇不是一个世界。

同样的问题在美西、美东、欧洲、韩国、新加坡上都成立。这篇给的是 Vultr 内部的横向排序，那几篇给的是区域内的商家排序。两个排序都做完，才有得选。

十一、下单前六项核验

第一项，机房在不在 33 个里，官方主机名对不对。地址写错的人不少，sgp-sg 那种拼法传了几年。

第二项，你要的档位在这个机房卖不卖。部署页把机房和套餐一起选一遍，灰的就是没有。

第三项，出网超量单价和流量池。$0.01/GB 是全球统一的，但每个档位送的流量不一样。

第四项，计费方式。按小时计费，销毁即停，这是 Vultr 相对年付商家的优势，别把它浪费在长测上。

第五项，系统盘和快照。要换机房，快照是唯一路径，开机前就想好盘要多大。

第六项，你的用户在哪。别按自己 ping 出来的数字选，自己的手感和用户的体验经常不是一回事。

前五项在控制面板里都能查到，第六项只能自己想清楚。查完再下单，比下完单再发现套餐是灰的要省事。当期活动可以扫一眼最新优惠与活动。

十二、常见问题

Vultr 哪个机房对国内最快？

分源看。北京源最快的是东京的官方 ping 主机 110.278 ms，但它带 20.0% 丢包；广东源最快的是大阪的官方 ping 主机 163.823 ms，两源 0.0% 丢包。33 个机房里北京源更快的有 24 个，广东源更快的只有 9 个，所以「最快」这个问题得先讲清是哪个方向。要一个两头都不难看的答案，是大阪。

Vultr 日本和新加坡怎么选？

日本两个机房分裂得厉害。大阪的官方 ping 主机 163.823 ms 和 176.198 ms，两源均衡；东京的官方 ping 主机 234.226 ms 和 110.278 ms，广东侧明显吃亏。新加坡是全场两源差最大的一个，官方 ping 主机广东 342.495 ms、北京 180.351 ms，差 162.144 ms。广东出海选大阪，北京出海可以考虑东京但要复核那 20.0% 的丢包，新加坡只在你的用户确实在东南亚时才成立。

Vultr 洛杉矶还是东京？

洛杉矶的官方 ping 主机 256.822 ms（广东）、155.730 ms（北京），东京的官方 ping 主机 234.226 ms 和 110.278 ms。北京源东京更好，广东源东京也好过洛杉矶。洛杉矶的价值在美洲落地和到美西用户的距离，不在回国这一段。为了国内访问选洛杉矶，数字不支持。

Vultr 各机房价格一样吗？

多数机房同价是常态，同一档位在多数区域价格一致。但区域定价确实存在，官方说某些位置可能因区域成本不同而定价不同。所以两个方向的断言都不对：说全都一样忽略了区域定价，说都不一样也不符合多数机房的实际。以控制面板显示为准。

Vultr 换机房要多少钱？

没有固定的一美分这种说法。机制是新建实例、迁移快照、删除旧实例，按小时计费，费用取决于新实例开了多久、快照多大。想控制成本就先做快照、验证新机器、再销毁旧的，实际金额以账单为准。

Vultr 的 ping 主机能代表我买到的机器吗？

不能。<city>-ping.vultr.com 是官方专门放出来的测试机，代表该机房对外的出口水平。同一机房不同网段的实例可能落在不同上游，延迟会有出入。要判断实例只能买了之后自己 ping，或者开工单要 looking glass 地址。

为什么有的机房在部署页里选不到？

套餐档位按机房过滤。大阪只开 AMD EPYC 和 Intel Xeon 高性能系列，入门档在那里不存在。High Frequency 和 Optimized Cloud Compute 覆盖的机房更窄。碰到这种情况不是页面出错，是那个组合不卖，换档位或者换机房。

十三、Vultr 机房怎么选：按出海口岸给答案

先定口岸，再排除，最后比延迟。

广东出海，首选大阪，官方 ping 主机 163.823 ms，两源 0.0% 丢包。想要更低的绝对值，硅谷的官方 ping 主机 167.164 ms 也在这个量级，而且两源都干净。这两个是广东侧唯一一组又稳又不算慢的。

北京出海，东京的官方 ping 主机 110.278 ms 最快，但 20.0% 的丢包得自己复核；不想担这个风险，大阪的官方 ping 主机 176.198 ms 更稳，孟买的官方 ping 主机 140.664 ms 也可以看。

两头都要兼顾，大阪、首尔、硅谷是三个不需要附加条件的答案。洛杉矶和东京属于带条件的选项，前者要你的用户在美洲，后者要你在北方且能接受丢包。

Vultr 机房怎么选，最后落在三步上：先定口岸，再按丢包和路由排除掉一半，最后才比延迟。顺序反过来，你会在一个本来就不该选的机房里纠结二十毫秒。

数据是 2026-10-20 上午一轮的，晚高峰会变，换季会变，机房扩容也会变。要拿它做决定，隔一段时间自己再 ping 一遍，比记住任何一张表都可靠。想横向比价，VPS 测评汇总 按商家筛；要看还有哪些商家在卖这些地区的机房，主机商列表 更全。

本次测试的局限

只有两个源。广东电信 AS4816 单线和阿里云北京 AS37963 BGP 多线，不代表全国，更不代表你的家宽。两个源只能说明两个方向。

只有去程。tracepath -n 反映的是探测源到目标这一个方向，回程路径可能完全不同，本轮没有测回程。

只有一轮采样。全部数据跑在 2026-10-20 上午，每个目标每个源 20 个 ICMP 包，属短时抽样，没有晚高峰样本，不足以刻画长期稳定性。

ping 主机不等于实例。测的是 Vultr 官方公布的测试机，同一机房不同网段的实例可能落在不同上游，你买到的那台机器延迟会有出入。

未测带宽与 CPU。没有做吞吐、磁盘 IO、CPU 跑分，也没有做 TCP 层和业务层实测，所有结论都停在 ICMP 层。

未覆盖 Vultr 全部套餐档位。Cloud Compute Regular、High Frequency、Optimized Cloud Compute 各自覆盖哪些机房，本轮只核到大阪一个例子，其余按以控制面板为准处理。