01先看线路优势：优化在哪些运营商上？

东京、新加坡 Premium 的优势，是三家运营商各有对应的优化回程。电信流量进入 CTGNet 并可见 CN2，联通经过 AS9929，移动经过 CMIN2（AS58807）。这比笼统的“三网直连”更具体：能够看出不同运营商分别使用什么网络。

同样在东京，Cloud / Mini 对应的是 SoftBank 节点，回程先经过 SoftBank，再进入电信 163、联通 4837 或移动 CMI。新加坡 Edge 则在这次三条记录中都先经电信 163，再交接目标运营商。它们与 Performance 的优化方向不同，不宜混为一谈。

欧洲需要按运营商看。法兰克福 Premium、伦敦 Premium 的电信可见 CTGNet / CN2，联通经 CUG 后进入 4837，移动为 CMIN2；本次联通、移动终点延迟约 120–138 ms。圣何塞 Premium 也可见电信 CN2、联通 9929、移动 CMIN2，适合在需要美国位置时纳入比较。

02Premium 是网络名字，买套餐还要对应产品系列

不同城市的命名并不统一。东京 Premium 对应 Performance，阿姆斯特丹 Premium 却对应 Cloud；法兰克福 Premium 还被 Performance、Cloud、Mini 共用。因此，不能把所有 Cloud 一概当成普通线路，也不能把所有 Mini 自动归到低端网络。

下表按官网各系列提供的测试入口对应。共用一个入口表示官方提供同一节点供参考，不表示各套餐的带宽额度、流量、CPU 或独立实例性能完全相同。

城市 / 测试网络官网对应系列
东京 Premium / SoftBankPerformance / Cloud、Mini
新加坡 Premium / EdgePerformance / Edge
法兰克福 Premium / 普通节点Performance、Cloud、Mini / Nano
阿姆斯特丹 Premium / 普通节点Cloud / Storage、Nano
大阪 IIJEdge、Cloud
圣何塞 Premium / 悉尼各自对应 Cloud、Mini
香港 / 伦敦 / 杜塞尔多夫 / 塔林各自对应 Cloud

0315 个节点的三网回程，放在一起看

这里的回程指测试节点向国内目标发送数据的方向。CN2、9929、CMIN2 描述可见的网络；163、4837 分别对应本次出现的 AS4134、AS4837。CUG 表示联通国际网络 AS10099，并不自动等于整段路径已经确认 9929。

CMIN2 与 CMI 分开记录：AS58807 对应 CMIN2，AS58453 对应 CMI。看见 CN2 骨干也不足以单独判断 GIA 等级，表格只写原始路径能够支持的内容。

数据有效期：2026-11-01。三网目标分别为上海电信 DNS、北京联通主机、北京移动 DNS；箭头表示可见网络交接，省略不响应的中间跳。
测试节点电信回程联通回程移动回程
东京 PremiumCTGNet / CN2CUG / 9929CMIN2
东京 SoftBankSoftBank → 163SoftBank → 4837SoftBank → CMI
大阪 IIJIIJ → 163 · 本次高延迟IIJ → 4837IIJ → CMI
新加坡 PremiumCTGNet / CN2CUG / 9929CMIN2
新加坡 Edge163163 → 联通163 → 移动
香港 CloudGSL / Zayo → 163GSL / Zayo → 4837GSL / Lumen → CMI
法兰克福 PremiumCTGNet / CN2CUG → 4837CMIN2
法兰克福 NanoTata → 163Tata → 4837Tata → CMI
伦敦 PremiumCTGNet / CN2CUG → 4837CMIN2
阿姆斯特丹 PremiumCTGNet / CN2 · 本次高延迟CUG / AS10099CMIN2
阿姆斯特丹 Storage / NanoCTGNet / CN2 → 163CUG / AS10099CMIN2
杜塞尔多夫 CloudLumen → 163Orange → 4837Arelion → CMI
塔林 CloudRETN → 163RETN / Orange → 4837RETN → CMI
圣何塞 PremiumCN29929CMIN2
悉尼 Cloud / MiniGSL / SoftBank → 163GSL / SoftBank → 4837GSL / Lumen → CMI

04延迟是多少？用同一组目标做有限比较

45 条记录都收到了目标回复。下面统一取每条路由终点 2–3 个有效响应的中位数，保留一位小数；不使用中间跳代替终点，也不把单次测试写成长期平均。三个目标分别是上海电信 202.96.209.133、北京联通 61.135.169.125、北京移动 221.130.33.52。

东京 Premium 在这批三个目标的记录中均最低。新加坡 Performance 的联通、移动明显低于本次 Edge，而两者的电信终点接近。这正说明线路优化带来的差别要按运营商看，不能用一个总分代替。

单位 ms；终点响应中位数，非网页加载时间。* 为本次显著高延迟样本，保留实测值，原因未确定。各节点并非同步连续测试，不能推导长期排名、吞吐或丢包率。
测试节点上海电信北京联通北京移动
东京 Premium28.4 ms51.8 ms55.5 ms
东京 SoftBank102.9 ms156.7 ms82.9 ms
大阪 IIJ708.1 ms *108.9 ms83.8 ms
新加坡 Premium67.0 ms81.4 ms76.3 ms
新加坡 Edge69.1 ms256.1 ms152.7 ms
香港 Cloud316.8 ms372.3 ms100.8 ms
法兰克福 Premium160.9 ms120.3 ms119.5 ms
法兰克福 Nano161.6 ms305.8 ms233.4 ms
伦敦 Premium171.2 ms134.8 ms138.0 ms
阿姆斯特丹 Premium674.1 ms *132.2 ms126.8 ms
阿姆斯特丹 Storage / Nano174.9 ms336.5 ms224.1 ms
杜塞尔多夫 Cloud175.6 ms187.3 ms248.1 ms
塔林 Cloud243.2 ms238.4 ms168.2 ms
圣何塞 Premium124.0 ms158.7 ms151.1 ms
悉尼 Cloud / Mini265.4 ms321.7 ms154.0 ms

05香港、大阪和阿姆斯特丹，为什么要看具体结果？

香港 Cloud 的电信、联通路径经过 GSL 与 Zayo，终点中位数约 317、372 ms；移动经 GSL、Lumen、CMI，约 101 ms。主机名和地理标签提示有较长的跨区转接，但不能仅凭 IP 定位确定每一段物理路线。对电信、联通的延迟敏感业务，这次香港样本没有体现出地理距离近的优势。

大阪 IIJ 的电信终点约 706–714 ms，联通和移动分别约 109、84 ms。它是一条真实的高延迟记录，但一次 ICMP 路由不足以认定电信长期不可用，或推断具体故障原因。

阿姆斯特丹 Premium 的电信终点为 640–715 ms，前面部分节点只有约 168 ms，而临近终点已经出现高值。可能涉及路径、负载或探测响应差异，现有记录不能确认是 ICMP 限速。表中保留终点结果，没有用较低的中间跳替换。

阿姆斯特丹 Storage / Nano 虽然也可见 CUG 和 CMIN2，但本次联通、移动终点仍高于 Premium 节点。线路名称说明经过的网络，不能保证同名骨干在不同节点、时段都获得相同延迟。

06把线路结果落到具体套餐

先确定访客的主要运营商和所需机房位置，再对照网络系列。以大陆访问为主时，东京、新加坡 Performance 可以优先比较；欧洲用途则同时考虑业务所在地以及本次联通、移动的差异。不能用这份国内回程数据推断海外用户体验。

最后再按应用需要比较内存、CPU、磁盘、月流量和付款周期。DNS 与公网主机不是家庭宽带，官方测试节点也不是每个配置的独立实例；本文反映 2026 年 11 月 1 日的样本，站内套餐价格与库存另按对应资料展示。