一、对比评测该看哪七个维度，才不会只看到参数表
网上的「日本VPS与欧美VPS对比评测」绝大多数是同一个套路：贴三张跑分截图，给一个延迟数字，最后写一句「综合来看日本节点更适合国内用户」。这种评测的问题是它只测了商家想让你看到的部分，而且测完之后你依然不知道该买哪一台。
一套完整的对比评测至少要覆盖七个维度，缺一个就可能做出错误决定：
维度一：延迟与抖动。 决定页面打开速度和实时业务体验。这一项必须区分白天和晚高峰，只测一次等于没测。
维度二：CPU 性能与超售。 决定编译、加密、跑模型这类计算密集任务的速度。要看的是持续性能而不是峰值。
维度三：磁盘 IOPS 与延迟。 决定数据库和文件系统的响应速度。这一项在老评测里被严重低估。
维度四：IP 质量与属性。 决定平台风控能不能过、能不能解锁特定地区内容。
维度五：端口速率与流量配额。 决定大流量业务能不能跑得动。
维度六：线路质量与路由路径。 决定晚高峰的稳定性。
维度七：长期稳定性。 决定这台机器能不能放生产环境。
这七个维度里，第四和第七是最容易在短评里被遗漏的，而它们恰恰是决定「能不能真用」的。 一台跑分漂亮但 IP 被大量平台风控的机器，对跨境业务的价值接近零；一台配置普通但连续运行半年不掉线的机器，价值反而高得多。
做评测前必须先做一件事：确定评测基线。 也就是先明确你的业务约束——访客在哪、峰值并发多少、月流量多少、是否需要特定地区 IP。没有基线的评测，测出再多数据也无法转化成决策。
还有一条方法论上的纪律，比测什么更重要：一次只改一个变量。 评测两台机器时，如果连同时段、同测试目标、同网络环境都不对齐，你测出来的差异里就混进了「时段差」「目标差」「本地网络差」这些噪声。正确做法是：在同一个十分钟窗口内交替测试两台机器，每轮测 5 分钟，交替三轮取中位数。 这一步会让评测时间翻倍，但能让结论的可靠性完全不同。
还有三项必须排除的干扰源：
本地网络。 你的家用宽带、办公室 Wi-Fi、公司专线本身的丢包和抖动会直接叠加到结果里。最可靠的做法是用一台境外的 VPS 作为测量点去 ping 被测机器，或者至少在同一个本地网络上交替测两台。
测速目标的选择。 用公共测速节点测试时，那个节点本身可能拥塞。优先用被测商家自己机房的 Looking Glass 节点测端口，用第三方节点测跨境链路。 这两件事要分开测，混在一起得出的数字没有解释力。
测试期间的宿主机活动。 宿主机在做 RAID 校验、快照、备份时，性能会有明显波动。同一项测试连续做三次，三次结果的极差超过 20% 就说明环境不稳定，需要换时段重测，而不是取平均值掩盖问题。
二、延迟怎么测才不会被宣传数字带偏
先算物理下限，再看实测值，这是唯一可靠的判断方法。 光在单模光纤中的有效传播速度约每秒 20 万公里，由此可以算出任何一对城市之间的往返延迟下限：
| 城市对 | 距离（公里） | 往返物理下限（毫秒） |
|---|---|---|
| 东京 — 国内主要城市 | 约 2100 | 21.0 |
| 大阪 — 国内主要城市 | 约 1900 | 19.0 |
| 首尔 — 国内主要城市 | 约 900 | 9.0 |
| 香港 — 国内主要城市 | 约 2500 | 25.0 |
| 伦敦 — 国内主要城市 | 约 9000 | 90.0 |
| 洛杉矶 — 国内主要城市 | 约 10000 | 100.0 |
| 新加坡 — 国内主要城市 | 约 2600 | 26.0 |
这张表能直接戳破大部分宣传数字。 任何说「美西回国延迟 80 毫秒」的页面，要么测的是单向，要么测点不在那个城市。健康的实测值应该落在「物理下限 + 20 到 60 毫秒」区间内：低于下限说明测法有问题，远高于上限说明路由绕行严重。
具体的测法与判定阈值：
# 基础延迟与抖动
ping -c 30 <服务器IP>看输出里的 min/avg/max/mdev 四栏。 mdev（标准差）小于 30 毫秒算稳定，大于 50 毫秒说明抖动明显，对实时业务是硬伤。
必须分时段测。 下面这个循环跑满 12 小时，把数据攒下来对比：
for i in $(seq 1 12); do
echo "=== $(date +%H:%M) ==="
ping -c 20 -q <服务器IP> | tail -2
sleep 3600
done判定阈值：晚高峰 20:00 到 23:00 的平均延迟不高于白天的 1.5 倍，丢包率小于 1%。 超过这个比例，说明这条线路在晚高峰拥塞。
常见误区：用一次 ping 的结果下结论。 单次测量可能恰好遇到运营商调度抖动，样本量太小时误差可以到几十毫秒。至少 30 个包、至少两个时段，才有比较意义。
三、CPU 和内存怎么测：超售是这里的主要坑
CPU 评测要用持续压测，不要用单次跑分。 常见的 yabs、Geekbench、跑分脚本测的是几秒内的峰值能力，而超售恰恰发生在持续负载下——商家把一台物理机的 CPU 切给更多虚拟机，平时看着很足，人多了就抢。
持续压测的做法：
# 用 stress-ng 持续加压 10 分钟，同时采样
stress-ng --cpu 4 --timeout 600 --metrics-brief &
watch -n 5 "cat /proc/loadavg"判定阈值：压测期间 load average 不持续超过 CPU 核心数 × 1.5，且不出现明显掉速。 如果压测中途速度掉下来，说明这台机器的 CPU 是共享超售的。
更实用的做法是看 steal time（被虚拟化层偷走的时间）：
top -b -n 1 | grep Cpu
# 或
vmstat 1 10st 列（steal）持续大于 5% 说明宿主机超售明显，大于 15% 说明严重超售。 这个数字是判断超售最直接的证据，比任何跑分都可靠。
内存评测要盯的是「谷值」而不是峰值。 跑满负载后的空闲内存、swap 使用量、OOM 记录才反映真实情况：
free -h
swapon --show
dmesg | grep -i "out of memory" | tail -5判定阈值：跑满业务后 swap 使用量应低于 512 MB，dmesg 里不能有 OOM 记录。 有 OOM 记录说明内存配额低于宣称值。
这里要讲清楚一个常见报错：机器看着有 4 GB 内存但跑什么都报内存不足。 常见原因有三个：一是商家给的内存是「BURST」型，压力大时会被回收；二是宿主机 swap 被占满，你的内存实际用到了宿主机 swap；三是 hypervisor 本身有额外开销，4 GB 的容器实际可用约 3.5 GB。遇到这种情况，先跑 free -h 看 buff/cache 和 available 的差值，再看 dmesg 里的 oom-killer 记录，能定位到是哪种。
四、磁盘 IOPS 怎么测：这一项最容易被忽略
磁盘测试用 fio，不要用 hdparm。 hdparm 只测顺序读的瞬时速度，对数据库毫无参考价值；fio 能模拟真实负载。
随机读测试（数据库最关心）：
fio --name=randread --filename=/tmp/testfile --size=1G \
--rw=randread --bs=4k --iodepth=32 --numjobs=1 --runtime=30 --group_reporting判定阈值：4K 随机读 IOPS 大于 1000、延迟小于 10 毫秒，才算 SSD 级别的表现。 如果只有几百 IOPS 或者延迟几十毫秒，那它就是机械盘或者被限速的共享存储。
同时要测写入延迟，这项对数据库最致命：
fio --name=randwrite --filename=/tmp/testfile --size=1G \
--rw=randwrite --bs=4k --iodepth=32 --numjobs=1 --runtime=30 --group_reporting判定阈值：4K 随机写延迟小于 20 毫秒。
常见报错一：测试时提示 fio: error opening /tmp/testfile: Permission denied 或者磁盘写满。 前者是权限问题，用 sudo 或者换到有写权限的目录；后者说明你的磁盘配额比标称的小——这时候顺便测一下真实可用空间：
df -h / && sudo dd if=/dev/zero of=/tmp/fill bs=1M count=1024 oflag=direct 2>&1 | tail -2常见报错二：测试结果飘忽忽高忽低。 这通常是因为测试文件落在共享存储上，或者宿主机在做备份、快照、RAID 重建。遇到这种情况，换个时间段重测三次取中位数，并在午夜和白天各测一轮，差值大就说明宿主机层面有干扰。
必须提醒的一点：这些测试都会产生大量磁盘写入。 买来第一天就做全盘压测，有的小商家会因为这个判定你「滥用资源」而做出不利的处理。建议先用 dd 写 1 GB 试写，确认能写通，再做完整 fio 测试。
五、IP 质量怎么测：这一项决定业务能不能存活
IP 是 VPS 里最不可见的资源，也是最影响业务成败的资源。 同一台机器，配置一样，IP 类型不同，价值可以差十倍。
几种 IP 类型的实际差别：
数据中心 IP（普通 IP）。 IP 归属地是机房所在地，属于某个数据中心运营商。绝大多数场景够用，但部分平台的风控会识别数据中心 IP 段并加强验证。
原生 IP（Native IP）。 IP 登记信息与机房所在地一致，运营商层面的「本土感」更真实。做日本本土账号、接日本本地支付渠道时，原生 IP 能显著减少验证触发率。
双 ISP（Dual ISP）IP。 住宅和数据中心两条线路都提供，兼具稳定性和住宅属性。渠道库里 sixtynet 的 Residential 系列就是这个路子，官网公开简介写明主做「住宅 IP VPS、双 ISP 住宅 IP」。
住宅 IP（Residential IP）。 归属于真实的宽带用户段，住宅属性最强。但住宅 IP 的代价是稳定性差、可用性波动、部分平台识别得更准。
评测 IP 的具体命令：
# 归属地与运营商
curl -s ipinfo.io/json
# 或
curl -s ip-api.com/json判定阈值：country 和 city 必须与预期一致，org 字段应当是目标机房的运营商，而不是代理或转售商。 org 显示为某数据中心但你买的是「住宅 IP」，这就是货不对板。
看黑名单与信誉：
# 检查常见黑名单
curl -s https://api.blocklist.de/api.php
# 反查同段其他 IP 的历史
curl -s "https://api.ipapi.is/?q=<服务器IP>"判定阈值：主要黑名单零命中，同 IP 段内没有大量已被标记的地址。
最后一项实测是业务侧的： 用目标平台的注册流程走一遍，看是否触发验证码或人工审核。这是唯一有效的验收方式，因为平台的风控规则不公开。
必须说清的一个风险：IP 更换政策比 IP 质量本身更重要。 一台机器 IP 质量完美但被封后要等一周才能换，对跨境业务是灾难。下单前必须问清：能否更换 IP、免费还是收费、多久能到账、能否指定更换的段。
还要区分「IP 干净」和「IP 原生」这两个完全不同的概念，很多人会混用。 「干净」指的是这个 IP 没有出现在任何黑名单、没有历史滥用记录——这是结果，可以通过检测工具直接验证。 「原生」指的是 IP 的登记信息与机房所在地一致——这是归属属性，查 IP 归属地数据库就能看出来。 一个 IP 可以干净但不原生（比如美国机房分配到的 IP 登记在另一个国家），也可以原生但不干净。评测时必须分开验证：黑名单查「干净」，归属地查「原生」，两个都过才算过关。
关于「住宅 IP 能解锁更多内容」这个说法，要加一个技术前提。 住宅 IP 的住宅属性确实更接近真实用户，但内容平台的识别能力也在同步提升，住宅 IP 段被批量标记的情况同样存在。所以判断住宅 IP 好不好，唯一有效的方法是你自己去目标平台走一遍注册或访问流程，看是否触发验证。 任何声称「买了住宅 IP 就能过某平台」的推荐都应该被谨慎对待。
最后一个必查项：IPv6 和 IPv4 的配比。 部分商家在宣传里写「双栈」，但实际分配情况差别很大：
ip -6 addr show scope global
curl -s https://api64.ipify.org判定阈值：如果你打算用 IPv6，分配的 IPv6 地址数量应当足够你的业务使用；如果你只打算用 IPv4，就直接确认 IPv4 数量——渠道库里 justg 的 RosCloud 系列是每台配 1 个 IPv4，属于干净的配置。
六、带宽和流量怎么测：端口标称值几乎全是虚的
先理解一个换算，它能解释绝大多数测速困惑。 端口速率和流量配额是完全独立的两个约束：
| 机型 | 月价 | 端口 | 月流量 | 端口满速 30 天理论上限 | 上限/配额 |
|---|---|---|---|---|---|
| RosCloud-01 | 19.99 美元 | 500 Mbps | 1024 GB | 约 147.3 TB | 147 倍 |
| RosCloud-03 | 39.99 美元 | 500 Mbps | 3072 GB | 约 147.3 TB | 49 倍 |
| RosCloud-05 | 59.99 美元 | 500 Mbps | 5120 GB | 约 147.3 TB | 29.5 倍 |
| LAX-STARTER | 年付 200 美元（折合 16.67 美元/月） | 2000 Mbps | 5000 GB | 约 589.4 TB | 121 倍 |
| LAX-MICRO | 年付 400 美元（折合 33.33 美元/月） | 4000 Mbps | 10000 GB | 约 1178.7 TB | 121 倍 |
| LAX-MEDIUM | 年付 800 美元（折合 66.67 美元/月） | 10000 Mbps | 20000 GB | 约 2946.8 TB | 151 倍 |
结论：这些机型的端口能力都远超流量配额，瓶颈永远是配额而不是端口。 所以评测带宽时，不能只测端口峰值。
测端口兑现率（测到同机房或邻近机房的 iperf3 节点）：
iperf3 -c <测速目标> -t 30
iperf3 -c <测速目标> -t 30 -P 8判定阈值：单流不低于标称速率的 80%，8 并发不低于 60%。 单流低但并发能跑满，说明是单连接限速而非端口共享。
测跨境链路的真实吞吐（这才是访客能感受到的）：
# 服务器端
dd if=/dev/urandom of=/var/www/html/test.bin bs=1M count=512
# 本地端
curl -o /dev/null -w "speed: %{speed_download} B/s, total: %{time_total}s\n" http://<服务器IP>/test.bin判定阈值：512 MB 文件下载时间不超过 130 秒（对应约 4 Mbps 实际吞吐），且 1 MB 首字节在 2 秒内。
测流量的真实消耗，看你的业务会不会超配额：
# 服务器上实时看网卡累计流量
watch -n 10 "cat /proc/net/dev | grep -E 'eth0|ens'"跑满一周，就知道你的业务在真实峰值下一个月会用掉多少 GB。
关于「不限流量」必须加一句：不限流量的套餐通常对单端口速率设了上限，标称 1 Gbps 实际可能只有 100 Mbps。 评测这类机器时必须问清单端口限速值，否则测出来的结论毫无意义。
七、线路评测：路由追踪怎么看才专业
路由追踪不是看跳数，是看路径特征。 命令如下：
traceroute -T -p 443 <服务器IP>
mtr -T -P 443 -r -c 100 <服务器IP>用 -T -p 443 而不是默认的 ICMP，因为很多中间节点对 ICMP 限速，会导致中间跳显示星号，看起来像断了其实通着。-p 443 走的是实际业务端口，结果才有参考价值。
看三件事：
第一，回程的 ASN 归属。 出现 AS4809 是电信 CN2，AS9929 是联通精品网，AS58807 是移动精品网，AS4134 是普通电信国际出口。回程走哪条，直接决定了晚高峰稳不稳。
第二，是否存在绕路。 正常路径的跳数应该和物理距离相称。如果去程 12 跳到香港，回程却要 18 跳经美国再回来，说明路由不对称，这种情况在晚高峰会明显恶化。
第三，延迟尖峰的分布。 用 mtr -r 的报告模式看每一跳的丢包率和延迟方差。中间某一跳丢包 30% 但后续跳正常，通常是那一跳的 ICMP 限速，不是真的丢包；但如果最后一跳也丢，那是真丢。
常见报错一：mtr 报 mtr: Failed to resolve host。 说明 DNS 没配或容器里没有 /etc/resolv.conf，改用 IP 直接测即可。
常见报错二：traceroute 全是星号。 先用 mtr 换成 TCP 模式再看，如果 TCP 模式通而 ICMP 不通，那只是中间节点屏蔽了 ICMP，线路本身没问题。
另外要理解一个机制：路由不是固定的。 运营商会根据流量负载调整路由，这正是晚高峰和白天路由可能不同的原因。所以一次 traceroute 的结果不能代表全天表现。
八、稳定性评测：72 小时连续运行要看什么
短测看不出稳定性，这是新手评测最大的盲区。 很多机器跑分时一切正常，用几天就掉线、内存泄漏、磁盘错误。
启动一个 72 小时的连续监控：
# 每分钟记录一次系统状态
while true; do
echo "=== $(date) ===" >> /tmp/stability.log
uptime >> /tmp/stability.log
free -m | head -2 >> /tmp/stability.log
df -h / | tail -1 >> /tmp/stability.log
ping -c 10 -q <你的本地IP> | tail -2 >> /tmp/stability.log
sleep 60
done判定阈值：72 小时内 uptime 的负载无异常尖峰、可用内存无持续下降（排除 cache）、磁盘使用率无异常增长、从外部 ping 的丢包率始终低于 1%。
特别关注内存是否持续下降。 如果可用内存在 72 小时里单调下降且 swap 持续增长，这是应用层内存泄漏或 hypervisor 回收异常的信号，跟评测机器配置无关，是这台机器本身的状态问题。
还要主动测试故障恢复能力：
# 模拟服务崩溃，看守护进程能否拉起
systemctl list-units --type=service --state=running
# 重启后的自启动是否生效
systemctl is-enabled nginx判定阈值：重启后所有服务自动拉起，systemd 处于 enabled 状态。 这一项在生产环境里的价值远高于跑分。
最后一条稳定性相关的评测内容：售后响应。 这条无法技术评测，但可以实测——在工作时间提一个工单，记录首次响应时间。 判定阈值：普通工单 2 小时内有首次响应。这个数字在你真出故障时的价值，远超过跑分高出的那几百兆赫兹。
九、评测表怎么填：一份可直接复制的模板
在填表之前，先把 Looking Glass 用起来——这是商家公开的、最容易被忽略的免费资源。 Looking Glass 是商家放在各个机房的测速节点，通常提供一个网页，你在网页上选择目标机房和测试类型，它直接帮你从那个机房里发起测试。
它的价值在于消除了两个最大的干扰源： 第一，测试点就在目标机房内部，测出来的就是机房内部的带宽能力，没有公网路由的损耗；第二，同一个 Looking Glass 可以同时测试多个机房，这让你能横向比较同一家商家的日本节点和欧美节点，消除了「不同商家网络质量差异」这个变量。
用 Looking Glass 测什么：
第一项：同机房内各节点之间的互联带宽。 在 Looking Glass 里选「上海到大阪」这类测试，观察带宽数值。判定阈值：机房内部互联应达到端口标称值的 80% 以上。 如果连机房内部都跑不满端口，那你的用户更不可能跑满。
第二项：Looking Glass 上挂着 iperf3 节点的话，直接用它测端口兑现率：
iperf3 -c <Looking Glass提供的iperf3节点> -t 30
iperf3 -c <Looking Glass提供的iperf3节点> -t 30 -P 8第三项：路由路径。 如果 Looking Glass 提供 traceroute 入口，直接看日本节点到欧美节点之间的实际路径，这能让你判断这家商家的国际出口质量，而不用自己买机器才能知道。
第四项：多机房对比。 同一家商家的日本、新加坡、法兰克福、洛杉矶节点各测一次，如果某个机房明显拖后腿，说明那个机房的宿主机或上游有问题，而不是整家商家的问题。
必须说明 Looking Glass 的局限：它测的是机房的出口能力，不是你家里到机房的真实体验。 它能帮你排除掉最糟糕的情况（同机房都跑不满），但不能替代真实的跨境链路测试。两项都要做，缺一不可。
把上面的方法整理成一张表，评测日本和欧美节点各一台时逐项填写：
| 评测项 | 测试命令 | 判定阈值 | 日本节点实测 | 欧美节点实测 |
|---|---|---|---|---|
| 平均延迟（白天） | ping -c 30 |
不超物理下限 60 毫秒 | 待填 | 待填 |
| 平均延迟（晚高峰） | 同上，20:00-23:00 | 不超白天的 1.5 倍 | 待填 | 待填 |
| 延迟抖动 | ping 的 mdev 值 | 小于 30 毫秒 | 待填 | 待填 |
| 晚高峰丢包 | ping -c 100 -i 0.2 |
小于 1% | 待填 | 待填 |
| CPU steal | vmstat 1 10 的 st 列 |
小于 5% | 待填 | 待填 |
| 内存谷值 | free -h 的 available |
无 swap 增长、无 OOM | 待填 | 待填 |
| 4K 随机读 IOPS | fio --rw=randread --bs=4k |
大于 1000 IOPS | 待填 | 待填 |
| 4K 随机写延迟 | fio --rw=randwrite |
小于 20 毫秒 | 待填 | 待填 |
| 磁盘真实可用空间 | df -h 加 dd 实写 |
不低于标称的 90% | 待填 | 待填 |
| 端口兑现率 | iperf3 -c 单流与 8 并发 |
单流 80%、并发 60% | 待填 | 待填 |
| 跨境实际吞吐 | curl 下载 512 MB |
1 MB 首字节 2 秒内 | 待填 | 待填 |
| 回程 ASN | mtr -T -P 443 |
记录并确认线路名 | 待填 | 待填 |
| IP 归属与运营商 | curl -s ipinfo.io/json |
国家城市与预期一致 | 待填 | 待填 |
| 72 小时丢包与内存趋势 | 循环脚本 | 丢包 1% 以内、内存无泄漏 | 待填 | 待填 |
| 工单首次响应 | 工作时间提工单 | 2 小时内 | 待填 | 待填 |
这张表最重要的地方在于「待填」两列——它把「我看测评觉得 A 好」变成了「我有 15 项数据支撑选 A」。
填完之后你会发现，选谁不取决于某个跑分最高，而是取决于你的业务卡在哪一项。 静态站卡在延迟，下载站卡在流量单价，数据库卡在磁盘 IOPS，跨境业务卡在 IP 质量和更换政策。
再补一条关于价格对比的纪律：填表时把价格统一换算成「月价」，并把年付机型除以 12。 渠道库里 sixtynet 的 LAX-STARTER 是年付 200 美元，折合 16.67 美元/月；RosCloud-01 是月付 19.99 美元。不统一口径就比价，很容易被年付的首年折扣误导。 其余没有结构化价格数据的商家，以官网当日报价为准，不要拿模糊区间去算单位成本。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 zenlayer 当前机型与价格
- 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 justg 当前机型与价格
- 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 digitalvirt 当前机型与价格
- 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 zgovps 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十、常见问题
问题一？ 日本VPS与欧美VPS对比评测到底应该看哪些指标？七个维度：延迟抖动、CPU 超售、磁盘 IOPS、IP 质量、带宽与流量、线路路由、长期稳定性。 只看跑分和延迟的评测，漏掉了最影响业务存活的三项。
问题二？ 延迟多少算正常？先算物理下限再加 20 到 60 毫秒。 东京下限 21 毫秒、洛杉矶 100 毫秒、新加坡 26 毫秒。低于下限的测量值不可信，远高于上限说明路由绕行。
问题三？ 端口标称 500 Mbps，为什么实测只有 100 多？三个可能：端口是共享的、单连接有 TCP 限速、或者测试目标在远端走了公网。 用 iperf3 测到同机房或邻近机房可以排除第三个原因。
问题四？ 怎么判断商家是不是超售？看 vmstat 的 st 列。 持续大于 5% 就是明显超售，大于 15% 是严重超售。这个数字比任何跑分都直接。
问题五？ 磁盘测出来很慢，是机器问题还是测试方法问题？先确认用了 fio 而不是 hdparm，再确认测试文件不在共享存储上。 如果 fio 的 4K 随机读 IOPS 只有几百，那它就是机械盘或被限速的共享存储。
问题六？ 跑分工具报错了怎么办？最常见是 fio 权限不足和磁盘写满，前者加 sudo、后者换目录并顺手用 dd 实测真实可用空间。 mtr 报 DNS 解析失败就直接用 IP 测。
问题七？ IP 怎么判断是不是原生？用 curl -s ipinfo.io/json 看 country、city、org 三个字段。 org 应当是目标机房的运营商，而不是代理或转售商。再结合业务侧走一遍目标平台的注册流程，这是唯一有效的验收。
问题八？ 评测要花多少钱？软件成本为零。 唯一花钱的是「先月付一台跑完整评测」这件事本身，而这一台月付的钱，是你整个决策里最便宜的一笔保险。 渠道库里入门档是 19.99 美元/月（RosCloud-01）或年付 200 美元折合 16.67 美元/月（LAX-STARTER）。
问题九？ 评测完发现两个都不达标怎么办？先看卡在哪一项。 延迟不达标就是线路问题，配置不达标就是档位问题，IP 不达标就是换商家的问题。三类问题的处理方式完全不同，别混着抱怨。
问题十？ 为什么别人的评测结论和我测出来的不一样？因为测试时段、网络位置、运营商、测试目标机不同。 晚高峰和白天的结果可以差一倍以上，任何不带测试时段说明的评测数据都不该直接采信。
价格与配置均来自渠道库快照（2026-11-06 06:12），其余商家以官网当日报价为准。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
