"为什么 Cloudflare 在全球部署了 300+ 节点，我在国内访问还是经常 200ms+？"——这是很多用过 Cloudflare 的国内站长都会问的问题。同样的疑问也出现在 Google DNS（8.8.8.8）、Cloudflare DNS（1.1.1.1）、Akamai CDN 上：明明全球都有节点，到了国内访问就是慢。
答案藏在 BGP Anycast 这个底层技术里。Anycast 是 Cloudflare、Google、Akamai 等头部厂商的"魔法武器"，能用同一个 IP 地址同时部署在几百个机房，理论上让用户自动连接到最近的节点。但国内的特殊网络结构让 Anycast 有时候会"算错距离"，把广州用户连到东京、把北京用户连到香港。这篇文章把 Anycast 的原理、国内的特殊性、怎么验证节点位置都讲清楚。
一、Anycast 是什么：同一个 IP 在很多地方
常规的 IP 地址（叫 Unicast）和物理服务器是一一对应的——8.8.8.8 如果在洛杉矶机房，那全球访问 8.8.8.8 都得跑到洛杉矶。
Anycast 打破了这个对应关系。同一个 IP 地址，在全球多个机房同时通过 BGP 协议广播出去。当你访问这个 IP 时，互联网路由器会自动把你引导到"BGP 看起来最近"的那个机房。
用一个比喻：
- Unicast 像家庭住址：1 个地址 = 1 个家。你寄信只能寄到那个家
- Anycast 像连锁便利店：所有 711 都叫"711"。你要去 711，GPS 自动导航到离你最近的那家
对用户来说体验是：访问 1.1.1.1，自己不用知道连的是新加坡的 1.1.1.1 还是法兰克福的 1.1.1.1，反正"最近的"那个会响应。
二、Anycast 为什么快
三个层面的优势：
1. 路径短 = 延迟低
用户到服务器的 RTT 几乎完全由物理距离决定（光在光纤中传输是物理上限）。Anycast 把"距离"从"用户到某个固定机房"变成"用户到最近机房"。北京用户访问北京节点 5ms，访问新加坡节点 80ms——差 16 倍。
2. 自动故障转移
某个机房挂了，BGP 撤销该机房的路由广播，全网在几十秒内自动把流量切到下一个最近的机房。不需要客户端做任何重试，不需要 DNS 切换。
3. DDoS 防御能力放大
攻击者打 1.1.1.1，攻击流量会被自动分散到全球几百个机房。Cloudflare 能扛住 T 级 DDoS 攻击，Anycast 是最重要的底层武器之一。
三、Anycast 在用什么协议工作
底层是 BGP（Border Gateway Protocol），互联网骨干网的路由协议。这里讲清楚一个常见误解：
Anycast 不是一个独立的协议，它是"在多个机房同时用 BGP 广播同一个 IP 前缀"的一种使用方式。
具体流程：
- Cloudflare 有一个 IP 段（比如 1.1.1.0/24），它在全球 300+ 机房的路由器上都配置了这个 IP
- 每个机房的路由器通过 BGP 向相邻的 ISP 通告："我这里有去往 1.1.1.0/24 的路由"
- 各 ISP 路由器在 BGP 路由表里会有多条去往 1.1.1.0/24 的路径，每条路径有不同的"AS-Path 长度"（经过几个自治系统）
- 路由器根据 BGP 选路规则，选择 AS-Path 最短的那条作为下一跳
当一个用户的请求经过 ISP 的路由器，路由器根据 BGP 表把请求送到"AS-Path 最短"的那个 Cloudflare 节点。这个节点就响应用户。
四、关键问题：AS-Path 短≠物理距离短
BGP 的选路逻辑核心是 AS-Path 长度（经过几个自治系统），不是物理距离，也不是延迟。这就埋下了 Anycast 在国内"失灵"的根源。
看一个典型情况：
- 广东电信用户访问 1.1.1.1
- 广州本来有 Cloudflare 节点，物理距离最近
- 但中国电信和 Cloudflare 之间在大陆境内没有 BGP 直连
- 电信骨干网告诉路由器：去 Cloudflare 要经过
电信 → 香港电讯盈科 → Cloudflare 香港，AS-Path 长度 3 - 而广州节点的路径是
电信 → 中国电信国际出口 → 美国某 IX → Cloudflare 美国 → 回到广州，AS-Path 长度 5 - 结果路由器选择"走香港"的路径，明明广州节点物理上更近，却用不上
这就是为什么 Cloudflare 国内体验普遍不如海外——它的节点在中国大陆境内的 BGP 互联非常有限。
五、国内 BGP 网络的三个特殊性
1. 出口少且拥堵
中国大陆的国际网络出口主要集中在三大运营商（电信、联通、移动）的几个城市（北京、上海、广州）。所有跨境流量都要从这几个出口走，高峰期拥堵严重。
| 运营商 | 主要国际出口 |
|---|---|
| 中国电信 CN2 | 上海、广州、北京 |
| 中国联通 169 | 上海、北京 |
| 中国移动 CMI | 上海、广州、北京 |
2. 运营商之间互联差
三大运营商之间的 BGP 互联点（中国境内 IX）数量少、容量小。电信用户访问联通机房可能比访问香港还慢。
3. 跨境厂商在大陆境内 BGP 互联有限
Cloudflare、Google、Akamai 等厂商在大陆境内的节点（如果有）通常通过几个特定的 IX 接入，而非和三大运营商的骨干网做大规模 BGP 互联。这意味着即便厂商在国内"有节点"，也很可能不会被国内运营商的 BGP 路由器选中。
六、如何验证 Anycast 到底命中了哪个节点
厂商一般不会主动告诉你访问的是哪个节点，但有几个验证手段。
方法 1：看响应头
Cloudflare、Akamai 等会在 HTTP 响应头里加机场代码（airport code）：
curl -I https://www.cloudflare.com 2>&1 | grep -i cf-ray
# CF-Ray: 7a8f1234567abcde-NRT
# 末尾 NRT 是机场代码，表示东京成田
curl -I https://www.cloudflare.com 2>&1 | grep -i cf-cache
# CF-Cache-Status: HIT
# 表示命中缓存常见 Cloudflare 机场代码：
| 代码 | 城市 |
|---|---|
| HKG | 香港 |
| NRT | 东京成田 |
| KIX | 大阪关西 |
| SIN | 新加坡 |
| ICN | 首尔仁川 |
| LAX | 洛杉矶 |
| SJC | 圣何塞 |
| PEK / PVG / CAN | 北京 / 上海 / 广州（少见，仅企业版部分客户） |
方法 2：traceroute 看最后几跳
对 Anycast IP 做路由追踪，最后几跳能看出落在哪个机房：
mtr -rwc 5 1.1.1.1
# 看最后跳的反向 DNS 名，类似:
# *.hkg01.cloudflare.com → 香港
# *.lax01.cloudflare.com → 洛杉矶
# *.sin01.cloudflare.com → 新加坡方法 3：用多节点测速工具
用本站的 多节点 Ping 工具 或 HTTP 测试工具 测 Anycast IP，从不同地区的节点测得的延迟能反推命中的节点位置：
- 北京节点 ping 1.1.1.1 = 8ms：很可能命中北京
- 北京节点 ping 1.1.1.1 = 45ms：命中香港或东京
- 北京节点 ping 1.1.1.1 = 80ms+：命中新加坡或更远
- 北京节点 ping 1.1.1.1 = 150ms+：命中美国/欧洲
同一时刻不同地区节点测同一个 Anycast IP，结果差异很大，正是"Anycast 在不同位置命中不同节点"的直接证据。
七、实测：1.1.1.1 在不同位置命中哪里
用本站多节点工具实测 1.1.1.1 的典型结果（数值会因时段波动）：
| 测试点 | 延迟 | 反推命中节点 |
|---|---|---|
| 北京 · 电信 | 45-65ms | 香港或东京 |
| 北京 · 联通 | 50-80ms | 东京 |
| 上海 · 电信 | 40-60ms | 香港 |
| 上海 · 移动 | 60-90ms | 东京或首尔 |
| 广州 · 电信 | 20-40ms | 香港 |
| 广州 · 联通 | 50-70ms | 东京或香港 |
| 成都 · 电信 | 80-130ms | 新加坡或东京 |
| 新疆 · 电信 | 150-250ms | 新加坡或欧洲 |
规律很明显：
- 越接近东南沿海，命中香港节点的概率越高
- 北方城市倾向命中东京
- 移动用户的 Anycast 体验通常比电信差
- 内陆城市（成都、新疆等）出口绕路严重，延迟翻倍
八、为什么 Cloudflare 在国内"看起来都用 Anycast 但延迟还是高"
串联上面的所有内容，答案清晰了：
- Cloudflare 在大陆境内的 BGP 互联非常有限。它有几个机房（如 PVG 上海企业版节点），但只对企业客户提供，普通免费 / Pro 用户访问不到
- 大陆 ISP 的 BGP 路由表里，到 Cloudflare 的最短 AS-Path 路径基本都指向境外，最常见是香港、东京、新加坡
- BGP 不会考虑"实际延迟"或"实际带宽"，只看 AS-Path 长度和管理员配置的优先级。大陆 ISP 可能因为商业原因偏好走香港 / 走美国，不会考虑用户体验
- 国际出口拥堵。即便命中了"最近的境外节点"（如香港），高峰时段电信 / 联通 / 移动的国际出口本身就是瓶颈
这就是为什么 Cloudflare 在国内被诟病慢——不是 Cloudflare 不行，是 BGP 选路机制和国内网络结构的结构性矛盾。
九、对站长的实际建议
如果你用 Cloudflare 给国内用户加速
- 免费版 / Pro 版用户体验很难超过香港 / 东京节点的延迟（30-80ms）
- 真要让 Cloudflare 在国内快，需要 Cloudflare China Network（百度合作版）或 Enterprise 版
- 替代方案是国内 CDN（阿里云、腾讯云、网宿、火山引擎）+ 海外 Cloudflare 双 CDN 架构
如果你用 Cloudflare DNS（1.1.1.1）
- 北方用户建议同时配置 223.5.5.5（阿里）或 119.29.29.29（腾讯）做 fallback
- 客户端如果支持 DNS over HTTPS（DoH），优先选 DoH，避开 UDP 53 的 QoS
如何选择 Anycast 服务商
判断一个 Anycast 服务商在国内体验好不好，看三个指标：
- 大陆境内是否有 PoP 节点，且对小客户开放（不是只给企业）
- 是否和三大运营商有 BGP 直连（不是绕境外）
- 实测延迟：用多节点测速工具实测，从北上广各运营商对该 Anycast IP 做测试，延迟稳定在 30ms 以内才算合格
十、总结
Anycast 是一个绝妙的设计：用 BGP 协议把"同一个 IP 在很多地方"这件事变成了现实，全球用户自动连最近节点，故障自动转移，DDoS 自动分散。这让 Cloudflare 和 Google 能用很简单的架构提供全球服务。
但 Anycast 不是魔法。它依赖 BGP 选路，而 BGP 选路依赖 AS-Path 长度而非物理距离。在 BGP 互联充分的地区（如北美、欧洲内部），Anycast 表现接近完美。在 BGP 互联结构特殊的地区（如中国大陆），Anycast 经常会"绕远路"，表现远不如本地 CDN。
下次再听到"我们用了 Anycast 全球加速"的宣传，记得问一句：在中国大陆有多少个 BGP 直连点？这才是判断它在国内是否真的快的关键。
想验证某个 Anycast 服务在你这里的真实延迟，用本站的 多节点 Ping 工具 和 路由追踪工具，从全国多个测试点同时打那个 Anycast IP，对比延迟和 traceroute 最后几跳的反向 DNS 名，5 分钟就能搞清楚厂商有没有在你所在的地区有真正的本地节点。