海外服务器线路对比：一台机器三条长途腿，25 条 AS 路径实测

2026 年 10 月 27 日 06:02–06:08 UTC，我们从美西圣何塞一台 AS402169 节点出发，对 15 个地区各取一个目标，跑了 20 包 ICMP 加一次带 AS 标注的 TCP/443 traceroute；随后又在东京、法兰克福、新加坡、伦敦四个城市各补测三家不同运营商的机器，合计 25 条可见路径。结果把「线路」这个词拆开了：出口只有一家，TATA（AS6453）；长途却按目的地分成三条腿——GTT（AS3257）13 条、TATA 自营 8 条、NTT（AS2914）3 条。同一台机器到不同地区，实测延迟占理论光速下限的比例从 50.5% 到 82.6%，差 1.6 倍；新加坡同城两个目的地相差 25.1 ms，原因不是距离，而是其中一个走 TATA、另一个走 GTT。所以「这家线路好不好」这个问法在结构上就问错了，正确的单位是「你的机房 × 目的地城市 × 目的网络」这个三元组。

Meta Description: 2026-10-27 实测 25 条 AS 路径：出口 TATA，长途分给 GTT 13 条、TATA 8 条、NTT 3 条；15 地区光速占比 50.5%–82.6%，含同城换承运商对照。

关键词：海外服务器、线路对比、AS 路径、traceroute、光速占比、国际带宽、地区选择

一、先给结论：你能选的只有第一段

把一条跨境链路切成三段看，一切都清楚了。

第一段是入口，也就是你的机房接哪家 transit。这一段是商家替你选的，也几乎是你唯一能通过「换商家」改变的部分。本轮这台机器接的是 TATA，所有 25 条路径的第 6 跳都是同一个 TATA 边缘路由器 216.6.52.164，延迟 3–5 ms——它就挂在同一个都会区里。

第二段是长途，也就是横跨太平洋或大西洋的那一跳。这一段不由商家决定，由 BGP 按目的地实时选出来的：去欧洲、去南美、去新加坡、去澳洲走 GTT；去日本、去韩国走 NTT；去香港、去印度、去迪拜、以及去 AWS 的所有目的地走 TATA 自己的骨干。

第三段是末段，对方网络接谁。新加坡那个 25.1 ms 的差距就出在这里——同样落在新加坡，AWS 的入口走 TATA，Vultr 的入口走 GTT，两家在同一个城市里的可达延迟差了 25 ms。

所以你买到的「线路」永远只是第一段加一个「长途候选池」。候选池里到底谁上场，取决于你用户的运营商和你的目的地接在哪家 Tier-1 上。这不是文字游戏：下一节的数据会显示，同一个城市内换一个目的网络，延迟能差 53 ms。

二、「线路」这个词对不上号的三个原因

在动手测之前，先把三个天天被混着用的概念分开，否则后面所有对比都是空的。

第一个混淆：套餐名 ≠ 路径。「CN2 GIA」「9929」「CMI」「国际 BGP」描述的是入口段和特定运营商的互联关系，它们只在「你的用户在中国大陆、并且走那家运营商」时才有意义。对一个新加坡用户，你的 CN2 GIA 入口一文不值，他连过来走的还是普通 transit。同一台机器对不同用户是不同质量的线路，这一点在地区选择的语境里经常被忽略。

第二个混淆：机房位置 ≠ 网络位置。 机房坐标决定的是物理距离，网络位置由 AS 路径决定。本轮香港目标就是活例子：TATA 骨干在 100.9 ms 就把包送到了香港侧的 AS6453 路由器，但最终目标 152.9 ms 才响应——中间 50 ms 花在末段和云内，跟「香港离美西 11,162 km」这个事实没关系。

第三个混淆：一次测量 ≠ 一条线路的属性。 我们过去几篇已经证明延迟会随时间漂移（10-23）、同城机房会离散（10-22）。AS 路径同样会变：同样的目的地，40 天前这台机器走的是 Arelion，10 月中旬换成 TATA 加 GTT 的组合。所以任何「某地区延迟 X ms」的结论都必须带时间戳，否则不可复现。

三、这次怎么测的：口径、命令与三条边界

测量分两轮，都在同一台机器上发起：

• 机器：38.55.134.58，San Jose, CA，AS402169（Uscloud Inc），出口第一跳 transit 为 TATA AS6453。
• 第一轮：15 个地区，每地一个目标（Vultr 各区域 ping 主机 10 个 + AWS S3 区域端点 5 个）。每目标 ping -c 20 -i 0.3，随后 traceroute -T -A -p 443 -n -q 1 -m 22。
• 第二轮：东京、法兰克福、新加坡、伦敦四个城市，各选三家不同运营商的机器（Vultr / AWS / Hetzner 或 Sakura），同一套命令，专门用来隔离「同城、不同目的网络」这一个变量。

光速占比的定义：理论最低 RTT = 两地大圆距离 ÷ 100 ms/千公里（光纤中光速约 20 万 km/s，一来一回所以除以 200,000 再乘 1000，简化成每千公里 100 ms 的单程换算），再算 理论值 ÷ 实测平均 RTT。这个比值不衡量「快」，只衡量「绕没绕路」：100% 意味着包沿直线跑，50% 意味着多跑了一倍路程。

三条边界必须写在前面，否则数字会被误用：

1. 单观测点。所有 RTT 都是「从圣何塞出发」的，换成从香港出发，排序会完全不同。
2. ICMP 是控制面。很多路由器对 ICMP 限速或丢弃，本文只把 AS 序列当作「经过谁」的证据，不把中间跳的 RTT 当链路延迟；RTT 一律取端到端 ping 的统计值。
3. 目标不等于地区。每个地区只取了一个目标，它代表的是「该目标接的那家网络」，不是整个城市。这正是第八节的实验要说明的事。

四、15 个地区：延迟、光速占比与承运商

下表按光速占比从高到低排列，距离为圣何塞到目标城市的大圆距离，RTT 为 20 包平均值。

三个读表要点：

第一，光速占比不是「越快越高」，而是「越大越直」。 东京 100.9 ms、占比 82.6%，是这一批里最直的一条；迪拜 258.3 ms、占比 50.5%，意味着包实际走了大约 26,000 km 的路——相当于绕了一趟欧洲。距离只差 4,700 km，延迟却多了 157 ms，这是绕行，不是「迪拜比较远」。

第二，短距离的占比没有意义。 洛杉矶只有 493 km、理论 4.9 ms，实测 9.9 ms，占比 49.8%——但绝对值只有 5 ms 的差，其中大部分是设备与排队开销。凡是理论值低于 10 ms 的行，别看占比，看绝对差值。

第三，mdev 比 avg 更能说明「这条线稳不稳」。 新加坡 avg 193.1 ms 看起来比悉尼 149.9 ms 差一档，但它真正的异常是 mdev 28.91 ms、极差 168.6–272.3 ms——同一批 20 个包里最慢的比最快的多跑了 103 ms。这种曲线不是距离造成的，是队列。第十节单独拆这一条。

五、承运商分流：25 条路径里只出现了 4 张网

把每条路径中间段出现的 AS 号归并，25 条可见路径的分布是这样的。

这张表最值得注意的是两件事。

一，所谓「国际带宽」背后只有少数几张骨干网。 25 条路径覆盖 15 个地区，长途段只出现了 3 家承运商。这意味着两件事同时成立：不同商家之间的「骨干质量」差异其实很小（大家都在用同一批 Tier-1），但同一家承运商在不同城市对上的表现可以差很多（新加坡的 GTT 就是坏的）。所以按「商家」评价线路，颗粒度太粗；按「承运商 × 城市对」评价，才对得上实测。

二，选择权不在你手里。 同一台机器的同一个出口，去东京（Vultr）走 NTT、去东京（AWS）走 TATA——区别只在目的网络是谁。你既不能要求「这次走 NTT」，也不能在买机器时指定长途承运商。你能做的只有两件：换一个接不同上游的机房，或者换一个目的地（比如把源站放到用户更近、且落在「好承运商」覆盖范围内的城市）。

入口的细节值得单独看一眼。 全部 25 条路径里，只要路径可见，第 6 跳都是 216.6.52.164（AS6453），延迟 3–5 ms。也就是说这台机器的「线路」在物理上只有一个出口，所有地区共享这条 100G 级别的上联。这条上联一旦拥塞或维护，15 个地区同时受影响——这是个被忽视的单点，比「线路等级」更值得写进架构文档。

六、绕行的铁证：迪拜为什么比班加罗尔慢 54 ms

迪拜 258.3 ms、班加罗尔 203.8 ms，迪拜比班加罗尔「近」1,000 km，却慢了 54.5 ms。光速占比也印证了这不是测量噪声：50.5% 对 69.0%。

答案在 AS 序列里。迪拜这条路径的关键三跳是：

 9  63.243.218.9      [AS6453]  133.967 ms
10  64.86.143.83      [AS6453]  133.901 ms
11  195.219.16.129    [AS6453]  133.943 ms
17  52.95.189.5       [AS16509] 255.493 ms

195.219.16.129 这个地址不是第一次出现——它同样出现在法兰克福（137.6 ms）和伦敦（140.2 ms）两条路径上，位置都在第 11 跳。换句话说，去迪拜的包先被送到了 TATA 的欧洲骨干，然后再从欧洲往东南飞 120 ms 到波斯湾。路线是「美西 → 欧洲 → 迪拜」，不是「美西 → 中东」。

这就是光速占比的用处：只看 258 ms 你会以为「迪拜就是远」；算一下占比 50.5%，再对一下 AS 序列，你会发现它比理论值多跑了整整一倍，而多出来的那一段完全可以由「换一个在欧洲或中东有直连的机房」消掉——如果你用户真在中东，把源站放在法兰克福反而可能比放在美西快。

同类现象还有香港那个 50 ms 的末段：TATA 在 100.9 ms 就把包送到香港侧的 AS6453 路由器（209.58.61.35），但 AWS 端点 151.6 ms 才回 ICMP。城市到了，机房没到，中间那 50 ms 是云厂商自己的入口策略和内部转发。

七、同城换一个目的网络，延迟差多少

第二轮的四个城市，每个城市三家运营商，同一套命令、同一分钟窗口。

四个城市，同一个源，四种结果。这组数据的价值在于它把「地区」和「目的网络」这两个变量分开了：

• 东京差 53.2 ms，但承运商可见的两家（NTT 106.3、TATA 103.1）只差 3.2 ms。真正慢的是 Sakura 那条——16 跳全静默，只在末端看到 AS9370 自己。这不是「Sakura 在日本很远」，而是「Sakura 的入口不接我们这条路径的上游」，包得绕到一个能互通的地方再进。
• 新加坡差 25.1 ms，两家都可见：AWS 走 TATA（180.87.180.2，101.5 ms 到达亚洲侧），Vultr 走 GTT（141.136.110.158，进亚洲时就已经 235 ms）。同城同分钟，一个 167.6、一个 192.7。
• 法兰克福只差 7.9 ms、伦敦只差 3.5 ms，说明在欧洲这两个城市对上，GTT 和 TATA 的落地质量基本等价——换承运商不必然改善，要看具体城市对。

所以「这个机房到新加坡 190 ms」这种说法，缺了主语。准确的说法是「这个机房到接 GTT 的新加坡网络 192.7 ms，到接 TATA 的新加坡网络 167.6 ms」。

八、新加坡的 25.1 ms 是怎么来的：一次可复现的归因

把两条路径的亚洲段落并排放，差值的来源一目了然。

有意思的是 GTT 那一跳的 ICMP 回显 235.4 ms，比它下一跳的 169.0 ms 还高——典型的路由器控制面限速，不能当作链路延迟。但它暴露了一个事实：GTT 在这条「美西 → 东南亚」的城市对上，去程与回程不是同一条，去程先到一个高延迟的节点，回程走另一条。这正是我们之前那篇去回程不对称实测里描述过的形态，只不过那次是运营商侧的最后一公里，这次是 Tier-1 侧。

对选型的意义很直接：如果你的用户主要在东南亚，而候选机房到新加坡的路径是 GTT 承运，那么 190 ms 是常态、168 ms 是换一条路径之后的收益；能不能换，取决于机房的 BGP 有没有第二条上游，而不取决于你买的是「几级线路」。

九、min 与 avg 的分离：比平均延迟更好用的一个指标

新加坡那 20 个包，min 168.6、avg 193.1、max 272.3、mdev 28.9。换算一下：avg 比 min 高 14.5%，max 比 min 高 61.5%。同一批包、同一个目的地、同一分钟内发出，最慢的一个比最快的多花了 103.7 ms。

这个形态有三种可能，可以按下面的顺序排除：

判据很简单：先看 min，再看 mdev。min 决定了这条路径的物理下限，mdev 决定了它能不能用来跑实时业务。迪拜 min 257.6、mdev 1.06，是一条又长又稳的线——不适合实时语音，但适合批量同步，因为延迟可预测。新加坡 min 168.6、mdev 28.9，是一条短但不稳的线——平均下来比迪拜好得多，可一旦赶上抖动，单次请求的尾延迟会飙到 270 ms，比迪拜的稳定 258 ms 更伤用户体验。

这就是「平均延迟选地区」最容易翻车的地方：两个地区的平均值可能只差 30 ms，但尾延迟差 100 ms 以上。做实时业务时，把 max 和 mdev 放进选型表，比多测十个地区更有用。

十、「线路等级」的溢价，到底买的是哪一段

既然长途只有三四家承运商、而且不由商家决定，那多花的钱买到了什么？只买到两段：入口的可达性，和末段的优先级。

币种与口径说明：以上为 2026 年 10 月公开询价与整机套餐折算的区间参考，不是逐 SKU 报价；同一档线路在不同商家、不同承诺带宽（95 计费 vs 固定）下差异可达 3 倍，下单前以购买页为准。专线价格按 1 Gbps 以内小带宽折算，大带宽单价会显著下降。

看懂这张表的关键是：溢价的乘数效应集中在第一段和第三段，跟第二段无关。 你多付 20 倍单价买「中国大陆优化」，买的是你的机房到中国大陆几家运营商的那一段互联质量；包一旦出了这个入口，进了 Tier-1 骨干，它和便宜线路走的是同一批路由器——本文的 25 条路径就是证据。

这也解释了一个常见困惑：为什么同一家商家、「同一条线路」，有人测出 130 ms、有人测出 190 ms。因为两个人所在的省份、用的运营商不同，落到的是不同的入口互联点；入口后面那段是共享的，前面那段是人各有命的。

十一、地区 × 承运商：一张可以直接拿去比价的矩阵

把本文实测和过去几篇的结论压成一张表。这里的「承运商注意点」是这一轮实测里真正会改变结论的东西，不是通用建议。

请把「实测锚点」这一列当成起点而不是标准答案：它是从圣何塞出发的数字，你的源站在别处，排序会变。真正的用法是拿同一套命令在你自己的候选机器上复测一遍，然后对着「承运商注意点」这一列去确认——差异是不是由承运商造成的。

十二、五步判读法：把一次 ping 变成可用的选型证据

下面这套流程，每台候选机器花 3 分钟，就能得到比商家宣传页可靠得多的结论。两条命令，第一行测延迟分布，第二行测路径归属。

ping -c 20 -i 0.3 <目标IP>
traceroute -T -A -p 443 -n -q 1 -m 22 <目标IP>

第一步，算光速占比。 目标城市的大圆距离 ÷ 100 得到理论下限（ms），除以实测平均 RTT。低于 60% 就要怀疑绕行，而不是接受「这个地区就是这么远」。

第二步，看 min 与 mdev。 avg 比 min 高 15% 以上、mdev 超过 10 ms，说明这条路径有队列或拥塞，尾延迟会很难看；如果 min 高而 mdev 小于 2 ms，那是一条又长又稳的线，适合批量任务。

第三步，读 AS 序列。 traceroute -A 输出的方括号就是 AS 号。把中间段出现的 AS 归并，你就知道这条路径由谁承运；同一目的地出现两家以上承运商（比如 AWS 走 TATA、Vultr 走 GTT），说明这个城市有备选路径，值得为「换一家」多花点时间。

第四步，同城换一个目的网络复测。 这是本文最推荐的一步，也是最容易被跳过的一步。同一个城市至少测两家不同运营商的机器，差值就是「目的网络选择」的代价。东京 53.2 ms、新加坡 25.1 ms 都是这么测出来的。

第五步，跨时段复测一次。 早上和晚上各一次，两次的 avg 差超过 10% 就别把这次的数字写进容量规划。延迟会漂（10-23 已实测），AS 路径也会变（40 天内这台机器从 Arelion 换到了 TATA + GTT）。

跟商家沟通时，要这三样东西，而不是问「你们是什么线路」：

1. 到目标城市的 mtr -T -P 443 截图（不是 ping 截图，mtr 能看到每一跳的丢包与 AS）；
2. 机房的 BGP 上游列表（有几家 transit、有没有 IX 接入）；
3. 同机房其他客户到同一目标的实测值（用来判断是不是你这台机器的个例）。

拿不出这三样的商家，通常也确实不知道自己卖的是什么。

十三、七条避坑

1. 别用「地区平均延迟」做决策。 本文 15 个地区里，同一城市内换目的网络的差异最高到 53.2 ms，比「香港 vs 新加坡」这种跨地区差异还大。
2. 别把中间跳的 RTT 当链路延迟。 GTT 那一跳回显 235.4 ms，而它下一跳只有 169.0 ms——路由器 ICMP 限速会系统性地骗你。
3. 别看占比判断短距离。 理论值低于 10 ms 的行（同城、同区域），占比没有意义，只看绝对差。
4. 别信「双线/多线」等于「处处都快」。 多上游买的是冗余和选路自由，不是每个城市对的低延迟；迪拜那条路径全程 TATA 自营，一样绕欧洲。
5. 别忽略末段。 香港 TATA 100.9 ms 到港、AWS 端点 151.6 ms 响应，中间 50 ms 与距离无关，只能靠测具体机房发现。
6. 别拿一次测量当属性。 记录测量时间、源站位置、目标 IP。缺任何一项，数字都不可复现。
7. 别为了「线路」换掉「位置」。 位置错了，换多贵的线路都补不回来——迪拜用户的最优解可能是法兰克福，而不是美西加钱。

总结

这一轮 25 条路径把「线路」这个词拆成了三段，也把三个常见结论证伪了。

第一，「这家线路好/差」不是有效判断——同一台机器的 25 条路径由 3 家承运商分担，商家的选择权只到入口为止，长途由 BGP 按目的地决定。第二，「某地区延迟 X ms」缺少主语——同城换一个目的网络，东京差 53.2 ms、新加坡差 25.1 ms，比很多跨地区差异还大。第三，「光速占比低就是线路差」也不对——迪拜 50.5% 是路径绕经欧洲（AS 序列里 195.219.16.129 与法兰克福、伦敦路径共用同一跳），不是带宽不足；换一个在欧洲有直连的机房，比在美西加钱买「高级线路」有效得多。

可操作的部分只有三件事：算光速占比找绕行，看 min/mdev 分离队列，读 AS 序列确认承运商。三条都用系统自带命令，一台机器三分钟能跑完，比任何宣传页都可靠。

🚀 需要海外服务器？ 通过 6.chengzicloud.cloud 购买，覆盖香港/新加坡/日本/美国等全球区域，同城多机与跨区域组合可选，测试后满意再付款，30 天无理由退款保障。

相关阅读

• 海外服务器城市对延迟矩阵：36 个城市对的互联质量
• 海外服务器同城机房延迟离散度实测
• 延迟基线会漂：海外服务器地区选择的时间维度实测
• 海外服务器线路对比的最后一公里：21 个运营商节点实测
• 海外服务器机房等级与线路等级的认证口径
• 海外服务器跨地区迁移成本量化

本文由 6.chengzicloud.cloud 提供，点击访问首页了解更多