搬瓦工 BWH 15 个机房实测：从杭州阿里云发起

搬瓦工 BWH 15 个机房实测：从杭州阿里云发起（2026-09-24）

同一台搬瓦工 VPS（kvmv5-20g-1g-1t-ca-cn2gia，20G 套餐）依次迁移到当时全部 15 个可选机房，

每到一个机房就从浙江杭州 · 阿里云 BGP 机房的一台 ECS 发起同一套测试。

测试时间：北京时间 2026-09-24 09:07—10:52（工作日上午，平峰）。

下表所有数字都由脚本从每项测试的原始输出生成，没有手工抄录。

一、测试环境与方法

• 测试点：中国浙江杭州，阿里云 cn-hangzhou 的 ECS（公网带宽上限远高于被测值，测试中实测上行可达 1.8 Gbps）。
  
  这是数据中心 BGP 多线，不是家庭宽带：去程走哪家运营商由阿里云按目的地选路，
  
  所以表里的「去程线路」反映的是阿里云的选路，不等于电信 / 联通 / 移动家宽用户实际会走的线路。


• 被测 VPS：同一台，按顺序迁移；迁移后磁盘不变、IP 改变。每个机房的 IP 见下表。


• 每个机房测这些（顺序固定，全部由杭州发起，回程除外）：
  
  
  
  1. 路由：NextTrace 去程（杭州 → VPS）与回程（VPS → 杭州测试机公网 IP），与 Ping 同时进行；
  
  
  2. Ping：150 次、间隔 0.2 秒（30 秒）。「丢包」「抖动」都取自这 150 包；抖动用 mdev 和第 95 百分位延迟（p95）表示；
  
  
  3. iperf3：单连接（P1）和 8 连接（P8），上传 / 下载各 10 秒（丢弃开头 2 秒起速段）。
     
     上传 = 杭州 → VPS，下载 = VPS → 杭州；取接收端汇总速率；
  
  
  4. HTTP：curl 从 VPS 下载 1GB 文件，限时 30 秒，按实际下载字节 ÷ 实际耗时换算 Mbps。
  
  
  
  


• 线路标签是按 AS 链机械判定的摘要（例如同时出现 AS4809 与 AS4134 记为「CN2 GT」），以 AS 链和原始路由为准。


• 上传项因流量不够部分未测试：测试机出站流量有限，上传只测了前 5 个机房，从第 6 个机房（JPOS_1）起写「未测试」，其余各项照测。

二、机房与时间（北京时间）

三、综合对比（上传项因流量不够部分未测试）

上 = 杭州 → VPS，下 = VPS → 杭州；Ping、丢包、抖动取自同一组 150 包；HTTP 为 30 秒限时平均；「未测试」= 该项没有测。

路由 AS 链（按跳序去重）

四、各机房分析

AS 号对照（只列能确认的）：AS58461 浙江电信、AS4134 电信 163 骨干、AS4809 电信 CN2、AS56041 浙江移动、AS9808 移动 CMNET、

AS58453 中国移动国际 CMI、AS58807 中国移动 CMIN2、AS4837 联通 169、AS9929 联通 A 网（CUII）、AS10099 联通国际 CUG、

AS37963 阿里云、AS25820 IT7 Networks（搬瓦工上游）、AS17676 SoftBank、AS6939 Hurricane Electric、AS1299 Arelion、

AS174 Cogent、AS3214 xTom、AS6327 Shaw、AS8966 Etisalat。

东京 JPTY_1 —— 本次全面第一。 去程阿里云选了浙江移动 → CMNET → 中国移动国际 CMI 直达东京；回程走联通国际 CUG → 联通 A 网（9929）回上海。

延迟 36.6 ms、150 包零丢包、抖动 0.05 ms；单连接下载 622 Mbps、8 连接下载 1914 Mbps、HTTP 657 Mbps（唯一一个 30 秒内下完 1GB 的机房）；

单连接上传 792 Mbps、8 连接上传 1205 Mbps。唯一要留意的是 8 连接下载时发送端重传 10.2 万次 —— 吞吐仍然最高，但多连接满速时线路有明显拥塞重传。

大阪 JPOS_1 —— 延迟低但不稳。 去回程都走电信 163 → SoftBank。延迟最低 38.5 ms，但平均 49.3、最高 60.7 ms，抖动 4.1 ms，150 包丢 6 个（4%）；

单连接下载 433 Mbps、8 连接下载 301 Mbps、HTTP 204 Mbps。和天津联通晚高峰的公开测试里大阪丢包 7% 的结论一致：日本想要稳，选东京不选大阪。

美西 CN2 GIA-E 三个机房（USCA_6 / USCA_9 / USCA_SJC5）—— 稳，速度接近。 延迟 134~139 ms，零丢包，抖动 ≤0.11 ms；

单连接下载 171~181 Mbps，HTTP 都在 170 Mbps 上下。三者的差别在路由：

• USCA_6：去回程都经电信 CN2 骨干（59.43.x），国内段经 163 接入（从阿里云 BGP 出发时常见），8 连接下载 155 Mbps；


• USCA_9：去程阿里云选了移动 CMIN2，回程走联通 CUG → 9929，8 连接下载 347 Mbps，是美西里最高；


• USCA_SJC5：去程移动 CMIN2，回程电信 CN2，延迟 134.0 ms 为美西最低，8 连接下载 138 Mbps。
  
  USCA_6 的单连接上传只测到 3 Mbps，而同一轮 8 连接上传 1606 Mbps、USCA_9 与 SJC5 的单连接上传都在 220 Mbps 左右，判断为那一次单连接测试的偶发异常。

弗里蒙特 USCA_FMT —— 非 CN2 机房里最好。 去程电信 163 直达，回程 HE → 联通 169。延迟 144.4 ms、零丢包，单连接下载 184 Mbps、8 连接下载 178 Mbps、HTTP 169 Mbps，

从杭州测和 GIA-E 机房几乎没有差别（平峰时段）。

温哥华 CABC_6 / 洛杉矶 USCA_8 / 温哥华 CABC_1 —— 中等。 延迟 157~182 ms、零丢包，HTTP 129~148 Mbps；8 连接下载只有 33~81 Mbps，多连接反而不如单连接。

纽约 USNY_8（CN2 GIA-E）—— 美东里可用。 195.5 ms、零丢包，HTTP 122 Mbps。纽约 USNY_6 —— 不推荐：215 ms、丢包 7/150，HTTP 53 Mbps，8 连接下载 9 Mbps。

阿姆斯特丹 EUNL_9（联通精品）—— 从杭州测表现差。 去程阿里云选了联通 169 → CUG 经法兰克福、伦敦到阿姆斯特丹；回程却走电信 CN2（法兰克福 → 上海，NextTrace 标注「CN2→163」）回浙江。

去回程不对称，延迟 161.6 ms、丢包 4/150、抖动 2.05 ms；单连接下载 44 Mbps、HTTP 36 Mbps。

这和天津联通晚高峰的公开测试结论相反（那边它是综合首选）—— 它的优势在联通用户回程，从阿里云（回程落到电信）看不到。

洛杉矶 USCA_2（AO） 178 ms、零丢包，但 HTTP 37 Mbps、8 连接下载 15 Mbps，吞吐差。

阿姆斯特丹 EUNL_2 302 ms、丢包 11/150（7%），HTTP 16 Mbps，本次最差。

迪拜 AEDXB_1 去回程都经中国移动国际 CMI，243 ms、零丢包，HTTP 94 Mbps —— 远，但稳。

五、按使用场景选择（仅针对本次：杭州阿里云 BGP 出发、工作日上午）

六、测试局限

• 单点、单时段：只有杭州阿里云一个测试点、一个工作日上午（平峰）。晚高峰、家宽、其他城市的结果可能明显不同 ——
  
  天津联通晚高峰的首选 EUNL_9，在本次反而表现差，就是测试点不同带来的差别。


• 每项只测一次、每次 10 秒；Ping 只有 150 包（30 秒），「稳定性」是短时采样，不代表全天。


• HTTP 限时 30 秒：除 JPTY_1 外都没下完 1GB，取的是 30 秒内的平均速度。


• 上传项因测试机出站流量不够，部分未测试：从 JPOS_1 起的 10 个机房没有测上传，USCA_SJC5 的 8 连接上传也未测试，表中写「未测试」。


• 路由标签是按 AS 链机械判定的；NextTrace 的地理位置与 AS 标注可能个别误标，中间不应答的跳（*）不代表丢包。

七、结论

从杭州阿里云出发，东京 JPTY_1 是本次唯一在延迟、丢包、单连接和多连接吞吐上全面领先的机房；

要美国，USCA_9 / USCA_SJC5 / USCA_6 三个 CN2 GIA-E 机房都稳（零丢包、HTTP 约 170 Mbps），差别主要在回程走哪家的骨干；

非 CN2 的 USCA_FMT 在平峰时段和它们不相上下。欧洲两个机房、纽约 USNY_6、洛杉矶 USCA_2 本次不推荐。

这些结论只对「杭州数据中心、工作日上午」成立；家宽用户请结合自己的运营商与晚高峰实测。