某坛里发现一个比较有意思的案例:

从绿云 JP(三网 IIJ 优化)线路机 向 DMIT 传输文件时速度明显偏慢。

原本以为是带宽或磁盘性能问题,但通过 traceroute 排查后发现:

不仅没有走传统的日美直连路径,反而先进入中国骨干网,并在国内跨运营商后再出海到美国。


一、先说结论

通过两组 traceroute 可以总结出实际路径:

1
绿云JP → IIJ → 联通4837 → 电信163 → CN2 → DMIT(洛杉矶)

以及另一组软银优化线路:

1
日本VPS → 联通4837 → 电信CN2 → DMIT(洛杉矶)

最终都指向同一个事实:

日本 → 中国 → 美国

而不是:

日本 → 太平洋直连 → 美国


二、实测一:三网 IIJ 优化(绿云 JP)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
traceroute to x.x.x.x, 30 hops max, 52 bytes packets
1 x.x.x.x AS23959 [OWL-JP] 日本 东京都 东京 owl.net
6.87 ms / 19.83 ms / 15.67 ms
2 *
3 211.14.4.221 AS9607 [JPNIC-NET] 日本 东京都 东京 bbtower.co.jp
4 211.14.4.222 AS9607 [JPNIC-NET] 日本 东京都 东京 bbtower.ad.jp
5 172.29.0.10 * RFC1918
6 210.138.130.225 AS2497 [IIJ] 日本 东京 iij.ad.jp
7 58.138.98.73 AS2497 [IIJ] 日本 东京 IIJ
8 58.138.112.38 AS2497 [IIJ] 日本 东京 IIJ
9 202.232.1.158 AS2497 [IIJ] 日本 东京 IIJ
10 219.158.30.69 AS4837 [CU169] 中国上海 联通
11 219.158.19.86 AS4837 [CU169] 中国上海 联通
12 219.158.19.81 AS4837 [CU169] 中国上海 联通
13 219.158.8.250 AS4837 [CU169] 中国上海 联通
14 *
15 202.97.62.117 AS4134 [CHINANET] 中国上海 电信
16 *
17 *
22 x.x.x.x AS906 DMIT 洛杉矶

三、实测二:三网软银优化机器

1
2
3
4
5
6
7
8
9
10
11
12
13
traceroute to x.x.x.x, 30 hops max, 52 bytes packets
1 x.x.x.x AS147293 日本东京 nearoute.io
2 10.50.1.1
3 *
9 219.158.16.249 AS4837 中国上海 联通
10 219.158.6.185 AS4837 中国上海 联通
11 *
12 219.158.117.14 AS4837 中国上海 联通
15 59.43.80.146 CN2 中国电信
16 59.43.159.98 CN2 中国电信
17 59.43.39.206 CN2 中国北京 电信
19 193.41.248.129 DMIT 洛杉矶
21 x.x.x.x DMIT 洛杉矶

四、关键现象总结

两条线路呈现出高度一致的路径结构:

1
2
3
4
日本出口
→ 中国联通(4837)
→ 中国电信(163 / CN2)
→ 美国洛杉矶

并且在第二条线路中还出现了:

联通到电信 CN2 的跨运营商切换。


五、本质:国际流量“国内中转化”

这类线路的本质并不是传统意义上的日美直连优化,而是:

将中国骨干网作为国际流量中转节点使用。

换句话说:

表面是“日本到美国线路”,实际是“日本 → 中国 → 美国”的三段式路径。


六、为什么会出现这种路径?

1. 成本驱动

相比日本直连美国海底光缆:

  • 中国国际出口带宽更便宜
  • 运营商可以降低上游成本
  • 更容易做高性价比产品

本质是用更低成本换取可接受体验。


2. 中国骨干网具备中转能力

中国三大运营商:

中国联通(AS4837)
中国电信(AS4134 / CN2)

具备:

  • 大带宽国际出口
  • 稳定中美链路
  • 成熟骨干调度体系

因此被部分线路作为中转枢纽。


3. 回国体验优化的副作用

这种路径还有一个明显附带收益:

回中国访问速度非常快。

因为流量本身就在中国骨干网中流转。


七、为什么你会感觉变慢?

问题主要集中在三个方面:

1. 路径变长

日本 → 美国(理论最短路径)
变成 日本 → 中国 → 美国。


2. 跨运营商切换

联通 → 电信(163 / CN2)之间的切换
容易带来调度延迟与拥塞风险。


3. 国际优化方向不一致

这类线路的优化重点通常是中国用户体验,而不是国际低延迟。


八、为什么仍然被称为“优化线路”?

因为优化的目标不同。

商家优化的是:

  • 中国方向访问体验
  • 回国链路质量
  • 成本控制与稳定性

但并不等同于:

  • 日本到美国的直连优化
  • 国际路径纯净性
  • 低延迟跨洲通信

九、适用与不适用场景

适合

  • 面向中国用户的业务
  • 回国访问占比高
  • 建站、下载、代理用途

不适合

  • 游戏服务器
  • 金融或交易系统
  • 低延迟国际通信
  • 对路径稳定性要求极高的业务

十、一句话总结

所谓“三网优化日美线路”,本质是:

日本入口 + 中国中转 + 美国落地。


十一、结语

这类案例说明一个关键点:

优化线路不等于直连线路,必须通过实际 traceroute 才能判断真实路径。

否则很容易出现误判:

以为是国际直连,实际是在中国骨干网绕了一圈再出海。


一、背景

这台小米电视原本通过插在背面的 U 盘,在局域网中共享图片进行展示。但由于 U 盘损坏,而电视机经已嵌入墙体不方便拆卸,更换存储设备成本较高。

因此,改为采用一种更灵活的方式:

👉 通过 ADB(Android Debug Bridge)直接将图片传输到电视本地存储目录


二、方案原理

小米电视基于 Android 系统,可以通过 ADB 进行远程管理。

核心思路:

  • 通过 ADB 连接电视(局域网)
  • 将图片推送到系统截图目录 /sdcard/ScreenCapture/
  • 使用系统相册或应用读取该目录进行展示

三、环境准备

1. 开启电视 ADB 调试

在电视上开启:

  • 开发者选项
  • USB 调试 / 网络调试(ADB over TCP)

2. 获取电视 IP 地址

例如:

1
192.168.8.87

四、操作步骤

1️⃣ 连接电视

1
adb connect 192.168.8.87

首次连接会看到:

1
2
3
* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to 192.168.8.87:5555

说明连接成功。


2️⃣ 查看目标目录

1
adb shell ls -l /sdcard/ScreenCapture

作用:

  • 确认目录存在
  • 查看已有图片
  • 避免文件重复

3️⃣ 上传图片(核心步骤)

1
adb push "C:\Users\Administrator\test.png" /sdcard/ScreenCapture/

示例:

1
adb push "C:\Users\Administrator\2026.3.27.png" /sdcard/ScreenCapture/

成功提示:

1
1 file pushed

4️⃣ 确认上传结果

1
adb shell ls -l /sdcard/ScreenCapture

示例输出:

1
-rw-rw---- 1 root sdcard_rw 21751005 2026-03-27 14:27 2026.3.27.png

5️⃣ 删除旧图片

为了避免目录堆积,可以删除旧文件:

1
adb shell rm /sdcard/ScreenCapture/old.png

示例:

1
adb shell rm /sdcard/ScreenCapture/2025.12.26.png

本文整理了香港及国际主要运营商的骨干网测试 IP,适用于:

  • 网络延迟测试
  • 路由质量分析
  • 回程线路判断
  • 机房 / VPS 网络对比
  • BGP 线路研究

🌍 国际 Tier-1 骨干运营商

运营商 ASN 测试 IP
Tata Communications AS6453 180.87.112.142
NTT Communications AS2914 203.131.243.153
Lumen Technologies AS3356 4.69.208.58
Hurricane Electric AS6939 184.104.220.67
GTT Communications AS3257 103.232.19.186
PCCW Global AS3491 63.216.84.146
Telstra AS4637 202.84.156.58
Arelion AS1299 62.115.169.212
Cogent Communications AS174 205.199.1.17
Verizon AS9337 210.80.1.13
Zayo Group AS6461 64.125.24.21
Vodafone AS1273 195.2.14.77
RETN AS9002 87.245.232.73
Telecom Italia Sparkle AS6762 195.22.223.128
Orange AS5511 193.251.150.24
Singtel AS7473 203.208.150.37
Chunghwa Telecom AS3462 211.22.33.137
KDDI AS2516 111.87.5.185
Internet Initiative Japan AS2497 58.138.97.226

🇨🇳 中国大陆运营商骨干网

运营商 ASN 测试 IP
China Mobile International AS58453 223.120.2.118
China Mobile International CN2 AS58807 223.120.130.5
China Unicom AS4837 219.158.20.94
China Unicom AS9929 AS9929 218.105.10.126
China Unicom Global 普通线路 AS10099 203.160.84.242
China Unicom Global 精品线路 AS10099 203.160.92.78
China Telecom 163 骨干网 AS4134 203.215.232.3
China Telecom CN2 AS4809 203.8.25.187
China Telecom Global AS23764 203.19.32.131

🇭🇰 香港本地运营商

运营商 ASN 测试 IP
HGC Global Communications AS9304 223.19.54.1
HKT AS4760 218.102.20.42
Hong Kong Broadband Network AS9269 119.246.40.1
China Mobile Hong Kong AS137872 182.239.125.254

☁️ 云服务与 CDN 厂商

厂商 ASN 测试 IP
CDN77 AS60068 84.17.57.129
Cloudflare AS13335 103.22.203.79
Google AS15169 142.250.76.238
Microsoft AS8075 104.44.212.216
Akamai Technologies AS20940 23.77.215.46
Apple AS6185 17.253.85.204

在网络排障、代理分流、路由健康检测、mwan3 线路监测等场景中,
使用 HTTP 204 (No Content) 作为连通性判断是最干净可靠的方式。

HTTP 204 特点:

  • 无正文内容
  • 无跳转
  • 成功即代表网络畅通
  • 适合脚本自动化检测

下面整理目前常用且稳定的 204 服务。


一、国际 204 连通性服务

服务商 测试地址 协议 返回码 适用场景 备注
Google http://connectivitycheck.gstatic.com/generate_204 HTTP 204 出海检测 Android 默认检测
Google http://clients3.google.com/generate_204 HTTP 204 出海备用 老版本系统使用
Cloudflare https://cp.cloudflare.com/generate_204 HTTPS 204 测试 CF 访问 Anycast 全球
小米 http://connect.rom.miui.com/generate_204 HTTP 204 国内直连测试 MIUI 默认
华为 http://connectivitycheck.platform.hicloud.com/generate_204 HTTP 204 国内直连测试 鸿蒙/EMUI

二、非 204 常用的联网检测地址

⚠ 以下返回 200,但常用于系统检测

服务商 地址 返回码 说明
Microsoft http://www.msftconnecttest.com/connecttest.txt 200 Windows NCSI
Microsoft http://www.msftncsi.com/ncsi.txt 200 旧版 Windows
Apple http://captive.apple.com/hotspot-detect.html 200 iOS/macOS

三、使用场景

1️⃣ 测试是否成功出国

推荐:

1
http://connectivitycheck.gstatic.com/generate_204

如果失败,说明:

  • DNS 被污染
  • 代理未生效
  • 分流规则错误

2️⃣ 测试是否走 Cloudflare 网络

1
https://cp.cloudflare.com/generate_204

可用于:

  • 测试 CDN 是否可达
  • 测试代理是否能正常访问 CF

3️⃣ OpenWrt / mwan3 线路健康检测

推荐搭配:

线路 检测地址
国内宽带 小米 204
国外线路 Google 204
CDN优化线路 Cloudflare 204

四、命令行测试示例

1
curl -I http://connectivitycheck.gstatic.com/generate_204

成功返回:

1
HTTP/1.1 204 No Content

设置超时:

1
curl -I --max-time 5 http://connectivitycheck.gstatic.com/generate_204

五、自建 204 服务

如果你有 VPS / 家宽服务器,建议自建 204:

Nginx 示例:

1
2
3
location = /generate_204 {
return 204;
}

访问:

1
https://yourdomain.com/generate_204

优点:

  • 不依赖外部服务
  • 可用于代理出口检测
  • 可用于分流测试
  • 不会被墙或被限速影响

六、如何选择 204 服务?

目标 推荐
测试是否出国 Google
测试国内直连 小米 / 华为
测试 CDN Cloudflare
做健康检测 自建 204
做博客演示 Google + CF + 小米

本文基于 Cloudflare colo 实测数据、真实用户访问记录以及国内骨干网结构经验,对 中国移动 / 中国联通 / 中国电信 访问 Cloudflare(CF)时的实际出海方向进行整理与分析。

结论并不基于“理论最优”,而是当前真实网络环境下的结果


一、结论速览(给不想看细节的人)

运营商 主流命中 CF 节点 核心特征
中国移动 🇭🇰 香港(HKG) 最稳定,不爱绕路
中国联通 🇺🇸 洛杉矶(LAX) 城域网 AS 基本全绕美
中国电信 🇳🇱 阿姆斯特丹(AMS)为主 路由最复杂,与 AS 强相关

一句话总结:

移动走香港,联通绕美国,电信去荷兰;精品网才有资格直连香港。


二、判断依据:Cloudflare colo

Cloudflare 在 HTTP 响应头或调试页面中,会返回当前命中的边缘节点代号(colo),例如:

  • HKG → 香港
  • LAX → 洛杉矶
  • AMS → 阿姆斯特丹
  • SIN → 新加坡

这可以非常直观地反映:

你的请求最终是从哪个 CF 数据中心回来的。


三、中国移动(CMCC):几乎全走香港

实测现象

  • 绝大多数移动 IP 命中:colo=HKG
  • 常见 IP 段:120.231.*.*
  • 不论南北,不论城域

网络层面解释

  • 移动国际出口高度集中
  • 与 Cloudflare 在 香港互联质量极佳
  • 即便城域网拥有独立 AS,也很少被引导绕美

总结

移动是三家里访问 Cloudflare 路径最“正常”的运营商,延迟低、稳定性好。


四、中国联通(CU):绕美是常态

实测现象

  • 大量联通用户命中:colo=LAX
  • 上海 / 广州 / 浙江 / 其他省份表现一致

核心规律(非常重要)

1️⃣ 城域网有独立 AS

  • 100% 绕美(洛杉矶)
  • 与地理位置无关

2️⃣ 直连省网或 AS4837 骨干

  • 可命中 香港 CF 节点

3️⃣ 特殊情况

  • 浙江:HKIX → 13335
  • 北京:部分情况下直接黑洞(CF 不可达)

为什么联通这么“爱去美国”?

  • 联通国际出口历史结构问题
  • 城域 AS 与国际 Peer 关系弱
  • Cloudflare Anycast 在联通侧被“推”向美西

联通是三家里对 Cloudflare 体验最差的


五、中国电信(CT):最复杂,也最“讲身份”

中国电信的 Cloudflare 路径,高度依赖用户所处的网络层级


1️⃣ 普通家宽(当前主流)

  • 命中:colo=AMS(阿姆斯特丹)
  • itdog.cn 多地测试结果:100% 去 AMS

原因

  • 电信拥有直达欧洲的欧陆光缆
  • AMSIX 与 Cloudflare 直接 Peer
  • 去阿姆斯特丹的延迟 低于去美西

➡️ 从运营商角度看,这是一个:

成本最低 + 延迟可接受 + 稳定性高 的选择


2️⃣ 优化 IP / 特定 CF 域名

  • 命中:colo=SIN(新加坡)
  • 多见于:
    • 人为优选 CF IP
    • 特定 Anycast 命中

⚠️ 不具备普遍性,稳定性一般。


3️⃣ 精品网 / 专线 / AS4812

  • 命中:colo=HKG
  • 特点:
    • 直连 AS4134
    • 不走欧陆

只有“身份足够高”的电信用户,才能直连香港 CF。


六、按“是否拥有独立 AS”总结规律

中国移动

  • 城域 AS / 直连 9808:
    • 🇭🇰 香港(HKG)
  • 少数情况:
    • 🇺🇸 美国

中国联通

  • 城域 AS:
    • 🇺🇸 洛杉矶(LAX)
  • 省网 / 4837 骨干:
    • 🇭🇰 香港

中国电信

  • 普通家宽 / 城域 AS:
    • 🇳🇱 阿姆斯特丹(AMS)
  • 精品网 / 直连 4134:
    • 🇭🇰 香港

七、结语

Cloudflare 在国内的访问路径,并不是简单的“就近原则”,而是:

运营商策略 × AS 结构 × 国际 Peer 关系 × 成本控制 的综合结果。

如果你在使用 Cloudflare CDN、反代、Tunnel 或自建服务时发现:

  • 延迟异常高
  • 明明在国内却跑到欧美

大概率不是你的问题,而是运营商替你做了选择


本文仅反映当前阶段的网络现实,不排除未来因 Peer 调整而变化。

一、必要条件

  1. Cloudflare 账号需已绑定支付方式(SaaS 为付费功能)
  2. 拥有两个可完全管理的域名
  3. 回源域名必须托管在 Cloudflare
  4. 必须在 Cloudflare 中配置回源(Fallback Origin)

二、基本设定说明

  • 访问域名b.com(用户访问的域名)
  • 回源域名a.com(托管在 Cloudflare,用于回源)

三、场景一:a.com 在 CF,b.com 不在 CF

步骤

  1. a.com(CF)

    • 添加回源记录:

      1
      origin  A  1.2.3.4
    • 状态:橙云(Proxy ON)

  2. Cloudflare → SSL/TLS → Custom Hostname

    • Fallback Origin:origin.a.com
    • 添加 Custom Hostname:www.b.com
  3. b.com(非 CF 托管)

    • 添加 TXT 记录完成验证

    • 添加 CNAME 记录:

      1
      www  →  优选域名(如 www.visa.cn等)

四、场景二:a.comb.com 均在 CF(重点)

关键原则:Custom Hostname 的 DNS Target 不能经过 Cloudflare Proxy

步骤

  1. a.com(CF)

    • 添加回源记录(橙云):

      1
      origin  A  1.2.3.4
  2. a.com(CF)

    • 添加优选入口(DNS Target):

      1
      cdn  CNAME  优选域名(如 www.visa.cn)
    • 状态:灰云(DNS only)

  3. Cloudflare → SSL/TLS → Custom Hostname

    • Fallback Origin:origin.a.com
    • 添加 Custom Hostname:www.b.com
  4. b.com(CF)

    • 添加 TXT 记录完成验证

    • 添加 CNAME 记录:

      1
      www  →  cdn.a.com
    • 状态:灰云(DNS only)


五、关于使用优选 IP

若使用 优选 IP 而非优选域名:

  • 将 DNS Target 的 CNAME 改为 A 记录
  • 必须为 DNS only

一、Intel 平台触发电路的总目标

让 PS_ON# 被 Super I/O 拉低,使 ATX 电源工作,从而进入主板 S0 状态。

这需要三个核心角色共同参与:

组件 作用
ATX 电源 提供 5VSB 和主电源(12/5/3.3V)
Super I/O(SIO) 接收开机键、控制 PS_ON#
PCH(Platform Controller Hub) Intel 电源状态机核心(S5→S0)

整套系统是 Intel 平台的“典型触发设计”。


二、Intel 平台上电流程总览图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
+5VSB 上电

Super I/O 上电(仅依靠 5VSB)

FP PWRBTN# 按下

SIO → 将按键事件发送给 PCH

PCH 决定是否从 S5/S4/S3 唤醒

PCH 拉高 SLP_S5# / SLP_S4# / SLP_S3#
(退出睡眠/断电状态)

PCH 授权 SIO:可以开机

SIO 输出 PS_ON# = 0

ATX 电源启动 12V/5V/3.3V

ATX 输出 PG(Power Good)

PCH 接收到 PG → 释放 PLTRST#、CPURST#、VR_EN

CPU 进入 S0 → BIOS 运行

这就是 Intel 平台的标准触发模型(Power Sequence)


三、详细解释 Intel 上电的每个步骤

① ATX 电源先提供 +5VSB

主板断电状态下唯一有电的就是:

  • +5VSB → 供给 SIO、PCH 的 RTC/一些逻辑

Intel 规定:

只有 5VSB + SIO 正常工作,开机键才能被识别。


② Super I/O 接到前面板按钮

前面板开关(PWRBTN#)按下:

  • 信号由 FP Header → 直接进入 Super I/O
  • Super I/O 并不会自己决定开机
    它只会向 PCH 报告“有人按了按键”

③ PCH 是开机的总裁(S 状态机核心)

Intel 平台的电源状态完全由 PCH 决定:

状态 说明
S5 软关机,仅 5VSB
S4 休眠
S3 待机(内存供电)
S0 全工作

按钮事件到达 PCH 后,PCH 会判断:

  • 当前状态是否允许开机?
  • 是否要唤醒?
  • 是否要退出睡眠?

如果允许开机,PCH 会输出:

✔ SLP_S5# = 高

✔ SLP_S4# = 高

✔ SLP_S3# = 高

这些信号是 Intel 定义的电源域控制信号。

“桥输出 S3/S4”就是 **SLP_S3# / SLP_S4# / SLP_S5#**。


④ PCH 授权 Super I/O 发出 PS_ON#

PCH 不直接控制 ATX 电源。
真正拉低 PS_ON# 的是 Super I/O

但 I/O 必须等到 PCH 发出“允许上电”后才会执行。

Intel 规范认为:

只有当 PCH 的睡眠信号 SLP_Sx# 都变为高电平,SIO 才能拉低 PS_ON#。

所以流程是:

  • PCH:退出 S5/S4/S3
  • PCH:授权开机
  • Super I/O:PS_ON# → Low

⑤ ATX 电源启动并输出主电源

当 PS_ON# = 0:

ATX 开始输出:

  • +12V
  • +5V
  • +3.3V
  • -12V

并在稳定后输出:

✔ PG(Power Good)


⑥ PCH 接收到 PG 后,真正开始启动 CPU

PG 被送给 PCH(不是 CPU)。
之后:

  • PCH 拉高 CPUPWRGD
  • VRM 给 CPU 上电
  • PCH 释放 PLTRST#
  • CPU 复位完成 → 取指令 → 执行 BIOS

主机才真正开机。


四、Intel 平台触发电路的本质总结(关键逻辑)

一句话总结:

Intel 平台中,PCH 是开机状态机;I/O 是 PS_ON# 的执行者;ATX 电源根据 PS_ON# 启动。

拆成三句话:

  1. 按钮按下 → SIO 接收 → PCH 决策
  2. PCH 决定 S 状态(S5 → S0)并授权
  3. SIO 拉低 PS_ON# → ATX 启动 → PG → PCH 完成 CPU 上电

脚本检测

华为云华南-广州-友好用户环境节点,110.41.110.180。纯粹好奇友好用户环境而测,想看看友不友好。

IP质量

路由质量

网络质量

实测回程

  • 日本
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


My traceroute [v0.95]
ecs-ca13 (192.168.0.53) -> 132.226.7.1 (132.226.7.1) 2025-12-11T16:04:23+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. (waiting for reply)
2. (waiting for reply)
3. AS749 26.4.105.81 0.0% 273 6.1 3.5 2.8 9.8 1.0
4. AS749 26.4.73.106 0.0% 273 3.1 3.6 2.7 24.2 1.9
5. AS749 26.4.66.156 0.0% 273 2.4 3.3 2.1 21.6 3.6
6. (waiting for reply)
7. AS??? 172.16.66.114 0.0% 273 9.5 5.0 3.2 23.3 2.9
8. AS4134 121.14.60.41 54.8% 273 5.3 6.7 3.7 31.7 4.8
9. AS4134 113.108.208.174 0.0% 273 8.1 8.6 3.3 53.6 6.5
10. AS4134 113.96.4.53 43.6% 273 4.2 4.4 4.1 22.3 1.8
11. AS4134 202.97.93.81 88.6% 273 4.8 4.8 4.7 5.6 0.2
12. AS4134 202.97.66.241 30.9% 272 9.9 7.1 6.1 18.6 2.0
13. AS??? 203.86.97.18 39.0% 272 135.8 130.2 122.9 159.0 6.7
14. AS2914 ae-5.r32.tokyjp05.jp.bb.gin.ntt.net 93.4% 272 71.7 73.8 71.0 77.5 2.1
15. AS2914 ae-0.a01.tokyjp10.jp.bb.gin.ntt.net 40.1% 272 123.9 131.2 122.9 159.8 6.7
16. AS2914 ae-0.oracle-oci.tokyjp10.jp.bb.gin.ntt.net 39.5% 272 128.2 131.3 126.2 166.4 6.4
17. AS31898 140.91.206.162 33.9% 272 118.1 117.6 114.0 118.5 0.4
18. AS31898 132.226.7.1 38.7% 272 123.3 121.7 114.3 138.3 3.2


My traceroute [v0.85]
instance-20220225-1300 (0.0.0.0) Thu Dec 11 08:03:53 2025
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. AS31898 140.91.206.118 0.0% 124 0.3 3.3 0.2 349.9 31.4
2. AS2914 ae-0.oracle-oci.tokyjp10.jp.bb.gin.ntt.net 0.0% 124 1.1 3.1 1.0 41.8 5.5
3. AS2914 ae-33.a01.tokyjp10.jp.bb.gin.ntt.net 0.0% 124 1.8 2.5 1.0 40.1 4.9
4. AS2914 ae-17.r32.tokyjp05.jp.bb.gin.ntt.net 93.5% 124 2.0 4.1 2.0 10.6 2.7
5. AS2914 ae-0.a03.tokyjp05.jp.bb.gin.ntt.net 0.0% 123 1.3 4.4 1.1 41.3 6.4
6. AS2914 xe-3.chinanet.tokyjp05.jp.bb.gin.ntt.net 43.1% 123 110.7 111.7 110.3 128.2 2.8
7. AS4134 202.97.12.10 82.0% 123 110.9 110.9 110.4 114.4 0.8
8. AS4134 202.97.82.57 83.6% 123 120.8 133.3 112.6 396.0 62.1
9. AS4134 113.96.4.138 98.4% 123 121.4 121.2 121.0 121.4 0.0
10. AS4134 113.108.208.177 92.6% 123 123.4 121.4 114.8 124.9 3.8
11. AS4134 121.14.60.42 35.2% 123 123.7 130.5 114.9 531.3 54.2
12. ???
13. ???
14. ???
15. ???
16. ???
17. AS55990 ecs-110-41-110-180.compute.hwclouds-dns.com 32.4% 108 123.0 120.6 114.4 130.8 3.6


  • 坡县
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


My traceroute [v0.95]
ecs-ca13 (192.168.0.53) -> 8.219.240.150 (8.219.240.150) 2025-12-11T16:07:08+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. (waiting for reply)
2. (waiting for reply)
3. AS749 26.4.105.113 0.0% 107 7.8 3.5 3.0 7.8 0.6
4. AS749 26.4.73.106 0.0% 107 3.5 3.5 2.9 10.5 1.0
5. AS749 26.4.66.156 0.0% 107 2.2 4.1 2.1 21.2 4.3
6. (waiting for reply)
7. AS??? 172.16.66.114 0.0% 107 5.5 7.0 3.3 20.5 3.6
8. AS4134 121.14.60.41 72.9% 107 5.4 5.2 3.8 7.2 0.7
9. AS4134 183.60.190.1 0.0% 106 4.4 4.9 4.3 15.0 1.7
10. AS4134 113.96.4.153 87.6% 106 4.3 6.3 4.2 27.1 6.3
11. AS4134 202.97.94.134 82.9% 106 16.7 7.3 5.4 22.6 4.7
12. AS4134 202.97.12.17 67.6% 106 6.7 7.2 6.7 20.7 2.4
13. AS4134 202.97.27.238 9.4% 106 341.8 177.0 152.4 400.5 49.5
14. AS4134 218.30.53.45 91.5% 106 152.0 153.8 151.7 160.9 2.9
15. AS6453 if-ae-20-2.tcore2.sv1-santaclara.as6453.net 87.6% 106 384.4 381.2 371.2 389.2 7.4
16. AS6453 if-bundle-28-2.qcore1.kv8-chiba.as6453.net 67.9% 106 363.4 365.2 356.2 375.3 6.8
17. AS6453 if-bundle-2-2.qcore2.kv8-chiba.as6453.net 86.7% 106 355.3 347.6 337.5 355.9 6.7
18. AS6453 if-bundle-45-2.qcore1.svw-singapore.as6453.net 98.1% 106 360.3 363.7 360.3 367.1 4.8
19. AS6453 if-bundle-2-2.qcore2.svw-singapore.as6453.net 86.7% 106 355.2 344.9 336.4 355.2 7.8
20. (waiting for reply)
21. AS45102 8.219.240.150 0.0% 106 178.2 178.2 178.2 178.7 0.1



My traceroute [v0.94]
s877258 (10.1.159.175) -> 110.41.110.180 2025-12-11T08:09:59+0000
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. AS749 11.73.101.30 0.0% 105 3.2 1.3 1.2 3.2 0.2
2. AS749 11.73.41.26 0.0% 105 1.3 1.3 1.2 2.3 0.2
3. AS749 11.73.55.162 0.0% 105 1.2 1.3 1.2 2.8 0.3
4. AS749 11.94.97.134 9.5% 105 1.6 1.6 1.5 2.7 0.2
5. AS749 11.94.97.133 99.0% 105 1.9 1.9 1.9 1.9 0.0
6. AS??? 10.216.171.202 0.0% 105 2.1 12.4 1.8 200.9 32.8
7. AS??? 10.102.152.5 72.1% 105 2.4 2.1 1.9 3.5 0.3
8. AS??? 47.246.115.226 0.0% 105 15.6 3.7 2.0 34.4 5.0
9. AS10099 162.219.80.241 0.0% 105 5.9 4.4 2.9 17.5 2.4
10. AS??? 118.26.159.21 0.0% 105 2.5 3.0 2.4 16.6 1.9
11. AS4837 219.158.17.181 0.0% 105 42.6 42.9 42.2 56.4 2.0
12. AS4837 219.158.3.185 61.2% 104 36.6 36.6 36.3 41.3 0.8
13. AS4837 219.158.3.85 92.2% 104 43.3 44.8 43.3 49.7 2.3
14. AS17816 120.83.0.74 91.3% 104 43.6 44.8 43.5 54.8 3.7
15. AS17816 120.80.137.34 96.1% 104 6884. 7052. 6884. 7284. 170.6
16. AS136958 58.254.152.94 0.0% 104 53.6 45.6 44.3 60.4 3.1
17. (waiting for reply)
18. (waiting for reply)
19. (waiting for reply)
20. (waiting for reply)
21. (waiting for reply)
22. AS55990 ecs-110-41-110-180.compute.hwclouds-dns.com 0.0% 104 178.2 178.2 178.2 178.5 0.1
  • 香港
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
华为云香港服务器L实例


My traceroute [v0.95]
ecs-ca13 (192.168.0.53) -> 150.40.17.25 (150.40.17.25) 2025-12-11T16:13:17+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. (waiting for reply)
2. (waiting for reply)
3. AS749 26.4.105.81 0.0% 157 3.2 3.5 2.8 10.2 0.9
4. AS749 26.4.73.106 0.0% 157 2.9 3.1 2.7 10.1 0.8
5. AS749 26.4.66.156 0.0% 157 2.2 2.5 2.1 28.5 2.4
6. (waiting for reply)
7. AS??? 172.16.66.94 0.0% 157 2.8 4.7 2.7 25.8 3.9
8. AS4134 121.14.60.41 62.2% 157 4.9 5.2 3.8 13.7 1.6
9. AS4134 113.108.208.174 0.0% 157 9.7 8.4 3.3 65.7 7.1
10. AS4134 113.96.5.81 94.2% 157 3.7 4.7 3.7 9.9 2.1
11. AS4134 202.97.93.85 83.4% 157 4.9 4.9 4.9 5.4 0.1
12. AS4134 202.97.66.229 27.4% 157 5.9 5.9 5.8 6.3 0.1
13. AS4134 202.97.27.242 7.0% 157 155.8 188.0 154.9 462.5 77.2
14. AS4134 218.30.53.45 84.7% 157 154.1 154.1 151.3 160.2 3.2
15. AS6453 if-ae-20-2.tcore2.sv1-santaclara.as6453.net 14.1% 157 325.3 324.6 318.8 344.4 4.3
16. AS6453 if-bundle-28-2.qcore1.kv8-chiba.as6453.net 70.5% 157 318.8 318.2 317.6 318.8 0.3
17. AS6453 if-bundle-9-2.qcore1.hk2-hongkong.as6453.net 80.8% 157 321.4 321.8 321.3 322.4 0.4
18. AS6453 180.87.185.138 86.5% 157 165.2 165.4 165.1 168.4 0.7
19. (waiting for reply)
20. (waiting for reply)
21. (waiting for reply)
22. (waiting for reply)
23. (waiting for reply)
24. (waiting for reply)
25. AS136907 150.40.17.25 3.2% 155 367.7 362.6 358.6 368.4 3.9


My traceroute [v0.95]
hcss-ecs-f1b5 (172.31.9.146) -> 110.41.110.180 (110.41.110.180) 2025-12-11T16:17:03+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. (waiting for reply)
2. (waiting for reply)
3. (waiting for reply)
4. (waiting for reply)
5. AS749 11.92.129.146 90.7% 109 1.4 1.4 1.2 1.7 0.2
6. (waiting for reply)
7. (waiting for reply)
8. (waiting for reply)
9. (waiting for reply)
10. AS3491 BE43.br02.frf08.as3491.net 57.0% 108 200.0 200.3 200.0 204.8 0.8
11. AS4134 81.173.21.41 0.0% 108 205.3 208.7 203.7 257.5 6.6
12. AS4134 202.97.116.77 14.8% 108 345.9 346.9 343.8 353.9 3.9
13. AS4134 202.97.64.166 66.7% 108 359.9 359.2 356.7 366.8 3.7
14. AS4134 202.97.93.46 98.1% 108 347.9 347.1 346.3 347.9 1.1
15. AS4134 113.96.4.154 86.0% 108 365.8 359.6 355.9 365.8 4.1
16. AS4134 183.60.190.2 84.1% 108 361.5 356.5 352.4 368.8 5.0
17. AS4134 121.14.60.42 10.2% 108 368.1 362.2 357.6 375.2 4.8
18. (waiting for reply)
19. (waiting for reply)
20. (waiting for reply)
21. (waiting for reply)
22. (waiting for reply)
23. AS55990 ecs-110-41-110-180.compute.hwclouds-dns.com 12.2% 98 368.4 361.8 358.7 368.6 3.7

狗妈咪图灵优化线路



My traceroute [v0.95]
ecs-ca13 (192.168.0.53) -> 103.73.220.16 (103.73.220.16) 2025-12-11T16:20:05+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. (waiting for reply)
2. (waiting for reply)
3. AS749 26.4.105.65 0.0% 104 3.3 3.4 3.0 6.0 0.5
4. AS749 26.4.73.112 0.0% 104 2.9 3.6 2.9 15.5 1.7
5. AS749 26.4.66.158 0.0% 104 3.1 3.6 2.9 13.2 1.9
6. (waiting for reply)
7. AS??? 172.16.66.94 0.0% 104 3.3 3.4 2.6 12.1 1.3
8. AS4134 121.14.60.41 49.5% 104 5.4 5.2 3.8 11.6 1.2
9. AS4134 113.108.208.174 0.0% 104 49.8 8.9 3.4 49.8 7.6
10. AS4134 113.96.5.65 92.2% 104 5.0 5.1 5.0 5.5 0.2
11. AS4134 202.97.94.138 84.5% 104 5.7 8.2 5.5 20.4 4.1
12. AS4134 202.97.12.13 32.7% 104 6.7 6.9 6.4 17.2 1.3
13. AS4134 202.97.22.126 0.0% 104 9.9 9.9 9.9 10.1 0.0
14. (waiting for reply)
15. (waiting for reply)
16. (waiting for reply)
17. (waiting for reply)
18. (waiting for reply)
19. AS??? 10.24.1.104 0.0% 104 9.5 10.0 9.3 27.3 2.5
20. AS??? 9.34.128.126 0.0% 103 10.1 10.7 10.1 28.5 1.9
21. AS??? 9.34.128.127 0.0% 103 9.3 10.0 9.1 43.1 4.3
22. (waiting for reply)
23. AS36002 103.73.220.16 0.0% 103 11.6 11.6 11.5 11.8 0.1




Hop Host Loss% Snt Last Avg Best Wrst StDev
0 103.73.220.1 0.0% 10 2.0 3.0 1.5 13.1 3.6
1 10.38.95.0 0.0% 10 0.4 2.9 0.3 24.9 7.8
2 9.34.128.126 0.0% 10 0.5 0.4 0.3 0.6 0.1
3 203.34.194.114 0.0% 10 0.5 0.5 0.4 0.7 0.1
4 (waiting for reply) 0.0% 10 ??? ??? ??? ??? ???
5 69.194.165.81 88.9% 10 1.1 1.1 1.1 1.1 0.0
6 69.194.169.194 0.0% 10 1.6 1.6 1.3 2.9 0.5
7 (waiting for reply) 0.0% 10 ??? ??? ??? ??? ???
8 59.43.250.53 30.0% 10 7.6 7.6 7.5 7.8 0.1
9 59.43.16.181 50.0% 10 9.4 9.4 9.3 9.4 0.0
10 202.97.43.81 0.0% 10 8.3 8.3 8.3 8.3 0.0
11 113.96.5.134 70.0% 10 8.7 8.7 8.7 8.7 0.0
12 183.60.190.2 0.0% 10 11.2 11.2 11.2 11.2 0.0
13 121.14.60.42 0.0% 10 10.6 11.0 10.3 14.7 1.3
14 (waiting for reply) 0.0% 10 ??? ??? ??? ??? ???
15 (waiting for reply) 0.0% 10 ??? ??? ??? ??? ???
16 (waiting for reply) 0.0% 10 ??? ??? ??? ??? ???
17 (waiting for reply) 0.0% 10 ??? ??? ??? ??? ???
18 (waiting for reply) 0.0% 10 ??? ??? ??? ??? ???
19 110.41.110.180 0.0% 10 11.6 11.6 11.5 11.8 0.1

脚本检测

华为云非洲开罗节点,101.46.67.242。此IP某dog上识别为重庆鹏博士。

IP质量

网络质量

实测回程

  • 联通
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
                                                 My traceroute  [v0.95]
ecs-ede5 (192.168.0.48) -> 120.80.102.117 (120.80.102.117) 2025-12-10T10:16:48+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDevt 1. (waiting for reply) quit
2. AS??? 10.160.138.81 0.6% 180 0.3 0.2 0.2 1.2 0.1
3. AS??? 10.160.136.58 0.0% 180 0.4 0.3 0.3 0.5 0.1
4. AS??? 10.160.136.3 0.0% 180 0.7 0.9 0.5 11.7 1.1
5. (waiting for reply)
6. (waiting for reply)
7. AS??? 172.16.110.14 0.0% 180 47.9 48.1 47.8 59.6 1.1
8. (waiting for reply)
9. AS174 be2921.ccr41.par01.atlas.cogentco.com 0.0% 180 48.4 49.0 48.2 81.4 3.5
10. AS174 be4975.ccr41.fra05.atlas.cogentco.com 0.0% 180 57.6 57.7 57.5 58.6 0.2
11. AS174 be5485.rcr31.fra06.atlas.cogentco.com 0.0% 180 58.1 58.2 57.8 81.4 1.7
12. AS174 149.11.21.241 5.0% 180 66.7 62.5 58.6 74.4 3.9
13. AS4837 219.158.14.81 1.7% 180 219.1 214.7 211.0 219.6 3.7
14. AS4837 219.158.4.101 26.4% 179 216.1 219.7 216.0 230.9 4.0
15. AS4837 219.158.3.157 99.4% 179 205.5 205.5 205.5 205.5 0.0
16. AS17816 112.91.0.186 14.0% 179 224.1 224.0 216.0 269.8 11.7
17. AS17816 120.80.203.206 3.4% 179 226.7 222.6 218.6 232.4 3.9
18. AS17816 120.80.102.117 4.5% 179 223.0 220.7 217.5 225.7 3.7
  • 移动
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
My traceroute  [v0.95]
ecs-ede5 (192.168.0.48) -> 120.196.91.1 (120.196.91.1) 2025-12-10T10:26:34+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. (waiting for reply)
2. AS??? 10.160.138.1 0.0% 350 0.3 0.2 0.2 6.0 0.3
3. AS??? 10.160.136.36 0.3% 350 0.4 0.3 0.3 0.5 0.0
4. AS??? 10.160.136.13 0.0% 350 0.8 0.9 0.4 8.2 1.0
5. (waiting for reply)
6. (waiting for reply)
7. AS??? 172.16.110.18 0.0% 350 47.9 48.0 47.7 53.0 0.7
8. AS5511 193.251.254.195 0.0% 350 48.1 48.0 47.9 48.4 0.1
9. AS5511 193.251.133.29 1.7% 350 56.1 62.3 56.0 425.3 36.5
10. AS5511 81.52.170.20 0.0% 350 55.8 55.8 55.7 55.9 0.0
11. AS58453 223.120.10.57 0.6% 350 62.4 63.2 62.3 73.5 1.8
12. AS9808 221.183.55.82 62.2% 350 251.0 251.1 251.0 251.8 0.1
13. AS9808 221.183.92.21 5.2% 349 250.4 250.5 250.3 274.1 1.4
14. AS9808 221.183.89.246 96.0% 349 298.2 298.2 298.1 298.3 0.0
15. (waiting for reply)
16. AS9808 183.233.59.226 0.0% 349 293.6 293.5 293.1 297.5 0.5
17. AS9808 120.196.91.1 0.0% 349 283.8 284.2 283.2 296.9 1.0

  • 电信
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
My traceroute  [v0.95]
ecs-ede5 (192.168.0.48) -> 14.147.8.22 (14.147.8.22) 2025-12-10T10:30:25+0800
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. (waiting for reply)
2. AS??? 10.160.138.17 0.0% 172 0.3 0.3 0.2 0.4 0.0
3. AS??? 10.160.136.48 0.0% 172 0.4 0.3 0.3 0.4 0.0
4. AS??? 10.160.136.9 0.0% 172 0.7 1.3 0.5 9.8 1.6
5. (waiting for reply)
6. (waiting for reply)
7. AS??? 172.16.110.14 0.0% 172 47.9 47.9 47.7 51.5 0.4
8. (waiting for reply)
9. AS174 be2921.ccr41.par01.atlas.cogentco.com 0.0% 172 48.7 48.6 48.3 50.9 0.3
10. AS174 be4975.ccr41.fra05.atlas.cogentco.com 0.0% 172 58.0 57.8 57.6 58.7 0.1
11. AS174 be3763.agr31.fra05.atlas.cogentco.com 0.0% 172 57.8 58.0 57.6 59.9 0.2
12. AS174 149.11.228.55 3.5% 172 65.8 66.3 58.1 74.1 2.2
13. AS4134 202.97.116.77 23.3% 172 290.1 289.6 282.0 295.5 2.2
14. AS4134 202.97.66.34 53.2% 172 295.0 292.9 285.3 300.0 2.6
15. AS4134 202.97.93.90 99.4% 172 293.3 293.3 293.3 293.3 0.0
16. (waiting for reply)
17. (waiting for reply)
18. (no route to host)

最近遇到一个真实案例

一位来自武汉的用户,将原先部署在阿里云杭州地域的服务器迁回到武汉节点,希望本地访问延迟更低。按照云厂商的宣传,“地域越近,延迟越低”。

但实际测试却发现:

  • 武汉本地 → 武汉节点:30ms
  • 杭州 → 武汉节点:15ms

反而是距离更远的杭州访问更快?

最终与阿里云技术确认:
武汉节点的公网出口实际上仍然在杭州。

这到底是什么原理?


一、这属于典型的“云厂商中心化出口(Centralized Egress)”架构

虽然服务器物理上在武汉机房,但云厂商不一定在每个地域都部署 BGP 出口(与运营商交换路由的接口)

对云厂商来说:

  • 机房:放服务器、存储、交换机
  • 出口:与电信/联通/移动对接的 BGP 点

为了节省成本、减少维护复杂度,云厂商常采用:

多个机房 → 统一走一个或多个核心地域的 BGP 出口

阿里云内部称为:
中心集群 / 跨地域骨干互联(的统一调度出口)


二、为什么武汉访问武汉服务器,反而绕到杭州?

访问路径实际上是这样的:

1
2
武汉用户 → 武汉本地运营商 →(无本地 BGP)→ 运营商骨干 → 杭州阿里云出口 
→ 阿里云内网 → 返回武汉机房 ECS

而不是你以为的:

1
武汉用户 → 武汉阿里云机房

原因很简单:

武汉机房没有运营商的 BGP Peering(对接)

因此:

  • 运营商不知道如何把外网流量直接路由到武汉阿里云机房
  • 所有流量必须进入阿里云的 杭州出口节点
  • 然后再通过阿里云自家的骨干 回传到武汉机房

于是形成:武汉 → 杭州 → 武汉 的绕路路径。


三、阿里云杭州出口为什么快?

杭州是阿里云最成熟的区域之一,具有:

  • 三大运营商就近有多个 BGP 互联点
  • 机房规模与容量全国领先
  • 自有骨干网带宽非常大

因此:

  • 武汉访问杭州:大约 15ms
  • 武汉访问武汉(但出口在杭州):约 30ms(多绕一圈)

本质是 出口位置影响延迟,而不是机房位置


四、为什么云厂商不在武汉建出口?

1. 成本极高

建 BGP 出口需要:

  • 大量光纤、路由器、交换机
  • 机房空间与维护团队
  • 三大运营商的跨省结算与资源协调
  • 冗余部署等安全要求

只有 核心地域(北京、杭州、深圳)通常才值得投入。

武汉属于“二级 Region”,成本与流量规模无法匹配。


2. 资源复用(更常见的原因)

云厂商倾向于把出口集中到:

  • 杭州(华东核心)
  • 北京(华北核心)
  • 深圳(华南核心)

以便:

  • 集中管理 BGP
  • 集中安全设备(DDoS、审计等)
  • 集中运营成本

这就是为什么:

入口在武汉,但出口在杭州
而 CDN 恰恰相反,出口就在就近节点


五、云厂商内部网络是怎么工作的?

一个典型拓扑如下:

1
2
3
4
5
6
7
8
9
武汉机房(无公网出口)

阿里云骨干网(CEN)

杭州核心地域(具有 BGP 出口)

三大运营商公共网络

用户

主要机制:

1. 内部通信全部走云厂商自己的骨干网

  • 速度快、质量可控
  • 比公网更稳定

2. 只有核心地域才有对外 BGP 出口

从而降低运营成本,并便于调度。


六、总结:服务器在武汉,出口却在杭州,是正常现象

你的测试现象完全符合云厂商的“中心化出口”架构:

  • 服务器位置 = 武汉
  • IP 归属地 = 武汉
  • 公网出口 = 杭州(真实决定访问路径的地方)

所以远距离反而更快。


七、如何验证出口确实在杭州?

在武汉机房 ECS 上执行:

1
traceroute 8.8.8.8

通常你会看到第一跳为:

1
阿里云骨干网 → 杭州出口 → 三大运营商网

没有任何湖北本地运营商的节点。


八、如何解决延迟问题?

方案 1:换地域(更关键)

选择 郑州、长沙 等真正具备本地 BGP 出口的区域。

方案 2:换云厂商(不同厂商布局不同)

例如腾讯云在华中部分地区的出口布局更本地化。

方案 3:使用具备“最优入口与出口”的产品

如:

  • 全球加速 GA
  • Anycast EIP
  • 高防 IP(通常分布更多出口)

这些产品不依赖地域出口,能显著改善路径。

0%