国内三大运营商访问 Cloudflare CDN的真实路径分析
本文基于 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 调整而变化。
