亚洲访问美西实测：日本最快 99ms、华纳云只有 1.7Mbps——和到欧洲正好相反

上一篇讲的是亚洲到欧洲（香港到欧洲、亚洲各地到欧洲）。这篇补上另一半：同样的 8 台亚洲机器，到美西（洛杉矶）是什么表现。结论和欧洲篇正好互补——去欧洲最快的香港/马来西亚，在美西方向反而一般；去欧洲最慢的日本，去美西只要 99ms。

测试时间：2026-10-26 22:5x–23:1x（一次性实测，非长期监控）。

系列文章：亚洲各地访问欧洲 · 亚洲访问美西

先给结论（按到美西延迟排序）

四个结论：

1. 到美西最快的是日本：justg 99.5ms、GreenCloud 108.9ms，比香港（143–146ms）快 35–45ms，比马来西亚（173ms）快 70ms+。
2. 到美西和到欧洲的排名几乎相反：日本到美西 99ms、到欧洲 238–257ms；马来西亚到欧洲 155ms、到美西 173ms；香港在两边都算中等偏上。
3. 华纳云的问题被定位了：到美西也只有 1.7/1.8 Mbps。这证明了上一轮的判断——不是「欧洲路径差」，是这台机器自身出口被限速/整形（两篇旧文已更正）。
4. 一台机器不可能两头都最优：日本强在美西、弱在欧洲；马来西亚反过来；香港是「两边都能打但不拔尖」。

图一：到美西 vs 到欧洲（同一批机器）

• 实色=到美西，浅色=到欧洲；同一台机器的两根柱子相差越大，说明方向差异越大。
• 日本两台：99/257、109/238 —— 到欧洲的柱子是到美西的 2.2–2.6 倍。
• 马来西亚：173/155 —— 唯一一根「欧洲比美西还短」的柱子。
• 香港三台：143/188、146/194、146/152 —— 到美西略好，但差距不大。

图二：到美西的吞吐

测法：iperf3 到 LAX.Pro，2 条流 × 60M 上限、3 秒（数字是下限，打满 120 说明还能更高）。

• 日本两台、DMIT 香港、evoxt 韩国都打满 120M 上限；
• 马来西亚 104/93、荫云 59/64，中等；
• vps.cat 24/57 被 30M 端口限制；
• 华纳云 1.7/1.8 Mbps，到美西和到欧洲一样差。

图三：同一台机器，两个方向的延迟

对角线 = 两边一样快；点在对角线上方 = 到欧洲更慢。

• 日本两台远在上方（欧洲慢一倍多）；
• 韩国两台也在上方；
• 香港三台靠近对角线（略偏欧洲慢）；
• 马来西亚在对角线下方（欧洲更快）——这就是「东南亚更适合做欧洲入口」的直观证据。

路由：亚洲 → 美西都怎么走

两个值得注意的点：

• GSL（AS7578）是日韩到美西的关键上游：justg、GreenCloud、荫云、华纳云去程都出现它，洛杉矶段延迟 99ms 左右。
• 华纳云的路径其实很绕（新加坡→香港→台北→东京→美西），但延迟 146ms 并不差；它的瓶颈是吞吐，不是路径长度。

怎么选（亚洲 → 美西）

自己怎么复测

ping -c 20 <美西目标IP>          # 延迟
nexttrace -T <美西目标IP>        # 看是否经 GSL / NTT / DMIT 骨干
iperf3 -c <美西IP> -p 5201 -P 2 -b 60M -t 3 -f m   # 吞吐（服务端先 iperf3 -s）

本页数据由 tools/make-asia-us-charts.py 生成；香港/欧洲篇的复测脚本是 tools/measure-hk-eu.sh。

口径与声明

• 数字为 2026-10-26 22:5x–23:1x 一次性实测；跨境路由会变，以你实测时点为准。
• 延迟：ICMP 20 包平均；吞吐：iperf3 2 流 × 60M 上限、3 秒，数值为下限。
• 路由为 nexttrace/traceroute 快照；部分节点屏蔽 TTL，路径由反向（洛杉矶 → 亚洲）探测还原。
• 更正说明：前两篇里把华纳云判为「欧洲路径/整形问题」，本次补测到美西同样只有 1.7/1.8 Mbps，已更正为「机器自身出口被限速/整形」。
• 机器链接：vps.cat HK-D4 · DMIT HKG.AN5.EB · 华纳云 香港三区 · evoxt 马来西亚 · GreenCloud 6666 JP · justg 东京 · evoxt 韩国 · 荫云 韩国双ISP
• 本站不代售、不编数；测不了的项目写「未测」，原始输出留档在服务端。