Vultr东京机房怎么样？最新的全面实测数据

Vultr 在日本一共有两个数据中心，一个在东京，一个在大阪。我个人用得最多的是 Vultr东京机房，前前后后也开过不少台机器，跑过不同的业务。

很多人想了解 Vultr 东京机房现在还能不能用？线路有没有绕路？晚高峰到底炸不炸？

正好手头的一台东京准备清退了，干脆趁这个机会重新跑一遍完整的测试。下面这篇文章，我会从基础性能、网络延迟、三网路由走向、实际下载速度几个方面。

Vultr东京机房测试机

这次测试用的是 Vultr 东京机房最基础的 Cloud Compute 方案，也是大多数人入门会选的那档，具体配置如下：

CPU / 内存	硬盘	流量	价格
1 vCPU / 1 GB	25 GB	1.00 TB / 月	$5.00/mo

选这个配置来测，主要是因为它最有代表性，大部分人拿来建站、跑轻量服务，基本都从这档起步。如果这个配置的网络和性能表现过得去，更高配置只会更好，不会更差。

机房位置选的是 Tokyo，也就是 Vultr 东京机房。配置方面没什么特别要展开说的，Vultr 的方案很透明，官网上都列得很清楚。接下来直接看实测数据，这才是你最关心的部分。

Vultr 基础性能测试

配置到手，第一件事当然性能测试。我分别跑了 CPU、内存和磁盘三项测试，下面逐个说。

CPU 性能

先看一下 CPU 型号：

root@001:~# lscpu | grep "Model name"
Model name:                              Intel Core Processor (Broadwell, no TSX, IBRS)

Vultr 东京机房这台分配到的是 Intel Broadwell 架构的处理器，不算新，但在这个价位的 VPS 里也算常见。用 sysbench 跑了 60 秒的单核计算测试：

root@001:~# sysbench cpu --time=60 run
CPU speed:
    events per second:   863.19

General statistics:
    total time:                          60.0004s
    total number of events:              51794

Latency (ms):
         min:                                    1.14
         avg:                                    1.16
         max:                                    2.34
         95th percentile:                        1.21

每秒 863 次事件处理，对于 1 核 5 美元的方案来说，属于中规中矩的水平。延迟也比较稳，95 分位在 1.21ms，说明 CPU 调度没什么明显的争抢，同宿主机的超售情况不算严重。

拿来跑个人博客、轻量 API 服务这些，完全够用；但如果你要跑编译或者计算密集型任务，1 核 Broadwell 确实会有点吃力，这不是 Vultr 的问题，是这个价位的通病。

内存

root@001:~# free -h
               total        used        free      shared  buff/cache   available
Mem:           951Mi       186Mi       437Mi       2.0Mi       328Mi       621Mi
Swap:          2.3Gi          0B       2.3Gi

实际可用内存 951MB，系统自身占了 186MB，剩余可用 621MB 左右。Vultr 还给配了 2.3G 的 Swap，这点比有些厂商厚道，至少在内存偶尔吃紧的时候不会直接 OOM 被杀进程。

sysbench 内存读写测试：

root@001:~# sysbench memory run
Total operations: 41434930 (4142229.11 per second)

40463.80 MiB transferred (4045.15 MiB/sec)

内存吞吐达到了 4045 MiB/s，这个成绩在同级别 VPS 中表现不错，日常使用完全不会成为瓶颈。

磁盘 I/O

磁盘性能是很多人容易忽略但实际体验影响很大的一项。我用 fio 分别测了随机读写和顺序读写。

4K 随机读写（最贴近日常使用场景）：

root@001:~# fio --name=randrw --rw=randrw --bs=4k --size=512M --numjobs=1 --runtime=60 --time_based --group_reporting

   READ: bw=16.7MiB/s (17.5MB/s), io=1000MiB (1048MB), run=60001-60001msec
  WRITE: bw=16.7MiB/s (17.5MB/s), io=1001MiB (1050MB), run=60001-60001msec

4K 随机读写都在 16.7MiB/s 左右，IOPS 读 4265、写 4271，读取平均延迟 219 微秒。这个数据跑数据库查询、WordPress 之类的动态站点是没问题的。

1M 顺序读写：

root@001:~# fio --name=seqrw --rw=readwrite --bs=1M --size=512M --direct=1 --numjobs=1 --iodepth=1 --group_reporting

   READ: bw=128MiB/s (134MB/s), io=242MiB (254MB), run=1895-1895msec
  WRITE: bw=142MiB/s (149MB/s), io=270MiB (283MB), run=1895-1895msec

顺序读 128MiB/s，顺序写 142MiB/s。备份数据、传文件这类大块读写的场景下，速度完全够用。

性能小结

把关键数据整理成一张表，方便你直观对比：

测试项目	测试结果	评价
CPU 型号	Intel Broadwell	略老，但该价位常见
CPU 单核跑分	863 events/s	中规中矩
可用内存	951 MiB（含 2.3G Swap）	标称 1G，实际给足
内存吞吐	4045 MiB/s	表现不错
4K 随机读 IOPS	4265	日常够用
4K 随机写 IOPS	4271	日常够用
顺序读	128 MiB/s	正常水平
顺序写	142 MiB/s	正常水平

整体来看，Vultr 没什么惊喜，但也没有明显的短板。CPU 虽然是老架构，但胜在稳定不超售；磁盘 I/O 在 VPS 里算中等偏上的水平。日常建站、跑服务都没压力，不需要担心。

接下来我们看更关键的部分——网络表现，这才是很多选择 Vultr 东京机房最关注的。

Vultr 东京机房的网络表现

说实话，选 Vultr 东京机房，大多数人最关心的就是网络。硬件性能各家差距不大，但网络质量直接决定了你的实际使用体验。这次我从带宽、延迟、丢包率、路由走向几个维度都测了。

带宽测试

先看 Speedtest 跑出来的带宽数据：

测试节点	上传速度	下载速度	延迟
Speedtest.net	3398.65 Mbps	8776.86 Mbps	0.36 ms
Tokyo, JP	8691.95 Mbps	8019.57 Mbps	1.08 ms
Taipei, CN	6734.04 Mbps	4984.10 Mbps	30.51 ms
Hong Kong, CN	1697.14 Mbps	6265.47 Mbps	48.58 ms
Singapore, SG	3650.22 Mbps	3847.91 Mbps	78.02 ms
Los Angeles, US	2535.49 Mbps	2291.94 Mbps	111.74 ms
Suzhou, CN	604.31 Mbps	179.36 Mbps	136.80 ms
Montreal, CA	381.46 Mbps	381.37 Mbps	161.08 ms
Amsterdam, NL	380.93 Mbps	2760.81 Mbps	224.20 ms
Paris, FR	1137.32 Mbps	2681.48 Mbps	238.40 ms

带宽方面没什么好挑的，Vultr 东京机房给的带宽确实大方。东京本地节点上下行都轻松跑到 8Gbps 以上，到中国台北和中国香港也分别有 5-6Gbps 的下载。

但你也注意到了——到苏州（大陆节点）下载只剩 179 Mbps，上传 604 Mbps。和周边地区对比一下，差距还是很明显的。带宽大归大，关键得看到国内的实际效果。

国内延迟

这是我比较在意的一项。直接看三网 Ping 的结果：

说真话，看到这组数据我是有点失望的。

三网平均延迟都在 200ms 左右，而我去年测的时候，Vultr 东京机房的平均延迟大概在 150ms 上下。一年时间涨了 50ms，这个退步幅度不算小。

联通表现相对好一点，杭州联通能跑到 78ms，勉强算能用；电信和移动就比较拉胯了，尤其是部分内陆省份，动不动就 300ms 以上，南昌电信甚至飙到 577ms，这个延迟已经很难接受了。

丢包率

丢包是比延迟更影响体验的指标。延迟高顶多慢一点，丢包严重的话，连接直接就不稳定了。

这次测出来的平均丢包率是 14.78%。

说实话，这个数字偏高了。虽然有部分节点表现还算稳定，丢包接近 0，但整体被一些表现差的节点拉高了均值。如果你是晚高峰用的话，体感可能还会更差一些。

对比去年的测试数据，丢包率也是明显上升的。

路由走向

为了搞清楚延迟变高的原因，我又跑了一下路由追踪。

结果发现，路由走的 NTT 线路到日本。NTT 是日本最大的网络运营商，带宽和稳定性在日本本土没问题，但问题是 NTT 到中国大陆的互联质量一直不算好，走的国际出口经常拥堵。

我对比了之前的路由记录，走向基本没变化。既然路由没变，延迟和丢包却变差了，大概率是 NTT 到国内的互联口更拥堵了，或者中间某段链路的容量没有跟上。

网络小结

把网络部分的核心数据汇总一下：

指标	实测数据	评价
本地带宽	上行 3.4Gbps / 下行 8.7Gbps	很充裕
到港台地区延迟	30-48ms	很好
到国内三网平均延迟	约 200ms	偏高，不如去年
丢包率	14.78%	偏高
路由线路	NTT	非优化线路

Vultr 东京机房的带宽很足，在日本本地以及亚太周边地区（港台、新加坡）的表现很出色。但如果你的目标用户在中国大陆，或者你需要从国内连过去操作，这个机房目前的体验并不理想。

如果你明确需要一台对国内友好的日本 VPS，可能得考虑那些提供中国优化线路的厂商，比如 DMIT 日本机房，走的是 CN2 GIA 这类回程优化线路，到国内的延迟和稳定性会好很多。

如果你的业务主要面向日本、东南亚，或者做外贸站、跑海外服务，那 Vultr 东京机房的网络完全够用，大带宽反而是优势。选什么机房，归根结底还是看你的流量从哪来、到哪去。

额外测试

除了前面的性能和网络，我还跑了几个常用的综合脚本，这里把结果贴出来，供你参考。

Bench.sh 综合测试

磁盘 I/O 三次平均 348.7 MB/s，印证了前面 fio 的测试结论，SSD 性能在这个价位属于正常水平。另外注意一下，默认 TCP 拥塞控制已经是 BBR 了，不需要额外手动开启。

这里有个重大的变化，去年 Vultr 使用的是 KVM 虚拟化技术，今年我测试竟然是 MICROSOFT，如果介意的可以考虑其他商家，例如 Kamatera，是老牌商家也支持按小时付款。

IP 质量检测

跑了一下 IPQuality 脚本，看看这个 IP 的纯净度和风险评级：

IP 整体风险不算高，大部分数据库给的都是低风险评级，只有 IPQS 给了高风险分，IPQS 对 Vultr 整个 AS 段都不太友好，不用太在意。黑名单方面，439 个数据库中 0 个黑名单。

25 端口被封了，这也是 Vultr 的老规矩，默认不让发邮件，想做邮件服务的话需要另外找方案。

流媒体解锁

流媒体方面，Netflix、YouTube Premium、Amazon Prime Video 都能解锁日区，主流 AI 服务（ChatGPT、Gemini、Claude）也全部正常。只有 Disney+ 和 Reddit 被禁了。

如果你主要是看 Netflix 日区或者用 AI 服务，Vultr 东京机房这个 IP 目前是可以的。

测试总结

跑完这一轮测试，我对 Vultr 东京机房的整体评价是：硬件够用，带宽充裕，但国内方向的网络体验不如去年。具体来说：

• 性能方面，$5/月的方案拿来跑个人项目、轻量建站完全够用，CPU 虽然是 Broadwell 老架构，但运行稳定，磁盘 I/O 也在合理水平，不拖后腿。
• 带宽方面，本地和亚太周边的表现很能打，东京本地跑到 8Gbps+，到港台地区也有 5-6Gbps，这是 Vultr 的强项。
• 国内网络方面，三网平均延迟 200ms 左右，丢包率接近 15%，比去年的数据退步明显。NTT 线路到国内的质量确实在下降，这点没什么好洗的。

所以，如果你的业务面向日本本地、东南亚或者其他海外地区，Vultr 东京机房依然是一个性价比不错的选择，大带宽、按小时计费、随开随删，用起来很灵活。

想试试 Vultr 东京机房的，可以直接去 Vultr 官网注册，开一台最低配的跑跑测试，不满意随时删掉。如果你有信用卡，点击这里领取 $300 体验金，新用户验信用卡可领。

常见问题解答（FAQ）