Anycast CDN和DNS调度CDN有什么区别？普通网站怎么选

北京、上海和新加坡分别查询同一个CDN域名，如果得到三个不同IP，通常会被解释为“DNS智能调度”；如果三地查到的是同一个IP，却分别进入了不同城市的节点，则可能使用了Anycast。

两种方式都能把用户引向分布式CDN节点，但选择节点的阶段不同：

DNS调度是在域名解析时选择入口地址；Anycast是在用户连接IP时，由互联网路由选择实际接入节点。

这并不意味着两种架构互相排斥。很多CDN会先通过DNS把用户分配到一个区域、线路或地址池，再在该地址池内使用Anycast；也有CDN让全球用户解析到相同Anycast IP，同时使用DNS完成域名接入、IPv4与IPv6返回以及产品策略控制。

普通网站需要了解这个区别，但没有必要只因为某家厂商宣传“全球Anycast”就立即更换CDN。真正应该关心的是：目标用户被带到了哪里、实际连接是否稳定、故障能否切走，以及不同地区和运营商的访问结果是否符合业务要求。

Anycast CDN是怎么选择节点的

Anycast允许多个不同位置的节点对外公布相同的IP地址或IP前缀。

例如，CDN在东京、新加坡、洛杉矶和法兰克福都公布：

203.0.113.20

用户查询域名后得到的都是：

www.example.com → 203.0.113.20

但用户实际连接到哪里，由BGP路由决定：

东京用户
   └── 203.0.113.20 → 东京或附近节点

新加坡用户
   └── 203.0.113.20 → 新加坡或附近节点

德国用户
   └── 203.0.113.20 → 法兰克福或附近节点

RFC 4786关于Anycast服务运行的说明将Anycast描述为：同一个服务地址存在多个独立实例，互联网路由系统把数据包送向其中一个实例。对于全球BGP部署，通常会为同一目的地址选择一条相对稳定的出口路径。

需要注意，路由系统选择的并不一定是地图上距离最近的节点。BGP更关注网络可达性、运营商策略、路由属性和互联关系，所以可能出现：

• 用户位于A城市，却接入B城市节点；

• 两个地理位置相近的运营商进入不同节点；

• 地区没有变化，运营商改变后接入点发生变化；

• 相同IP在不同时段出现不同网络路径。

因此，“Anycast会自动选择物理距离最近节点”并不准确。更合适的说法是：网络路由会根据当时可见的路径与路由策略，把用户带到公布该地址的某个节点。

DNS调度CDN是怎么选择节点的

DNS调度发生在用户建立HTTP或HTTPS连接之前。

典型过程是：

用户查询：www.example.com
        ↓
CNAME：www.example.com.cdn-provider.example
        ↓
CDN权威DNS根据地区、运营商、健康状态或策略选择答案
        ↓
返回：203.0.113.31
        ↓
用户连接该IP

来自其他地区的用户可能得到另一个答案：

北京电信 → 203.0.113.31
广州移动 → 203.0.113.42
新加坡   → 203.0.113.53

DNS调度可以按照多种条件选择入口，例如：

• 递归DNS所在地区；

• 递归DNS所属运营商；

• EDNS Client Subnet提供的客户端网段线索；

• 节点健康状态；

• 当前容量与业务策略；

• IPv4或IPv6协议；

• 域名、套餐或客户自定义规则。

AWS Route 53的延迟路由官方说明就是一个清晰示例：权威DNS收到查询后，会从已配置的多个区域中选择预计能提供更低延迟的区域，并返回对应记录。

不过，DNS调度看到的通常不是浏览器本身，而是替用户完成查询的递归DNS。如果用户在广州，却使用了一个出口位置不同的公共DNS，CDN可能按照递归解析器的位置返回节点，结果不一定适合用户的实际网络。

Anycast和DNS调度最核心的区别

这张表描述的是典型设计，不代表所有CDN都严格采用同一种实现。厂商可能在不同产品、地区和套餐中使用不同调度架构。

Anycast CDN也需要DNS

一个常见误解是：“用了Anycast以后，就不需要DNS调度了。”

实际上，用户访问的是域名，仍然要通过DNS获得A或AAAA记录：

www.example.com
        ↓ DNS
203.0.113.20
        ↓ Anycast路由
某个CDN接入节点

DNS在这里仍然负责：

• 将业务域名映射到Anycast地址；

• 返回IPv4和IPv6入口；

• 处理CNAME接入；

• 控制不同域名或产品的地址池；

• 在部分情况下执行区域或线路级选择。

因此，判断一个CDN是不是Anycast，不能只看它是否要求配置CNAME。DNS调度型CDN和Anycast CDN都可能通过CNAME接入。

同样，全球查询得到相同IP也只能作为Anycast线索，不能单独证明该IP一定采用Anycast。它也可能只是一个固定的单点地址、区域入口或负载均衡地址。

DNS调度也可能返回Anycast IP

另一种常见架构是先DNS分组，再由Anycast完成组内接入：

用户DNS查询
     ↓
按区域分配地址池
     ↓
亚洲地址：203.0.113.20
欧洲地址：203.0.113.30
     ↓
每个地址又由区域内多个节点Anycast公布

此时，北京和新加坡可能查到同一个亚洲Anycast IP，伦敦查到欧洲的另一个Anycast IP。

所以，将CDN简单分成“Anycast CDN”和“DNS调度CDN”有助于理解原理，却不能完整描述大型CDN的真实架构。很多网络实际使用的是混合调度。

对网站运营者来说，真正有价值的问题不是“到底属于哪一类”，而是：

DNS先把用户分到了哪个地址池？
这个地址在用户网络中进入了哪个节点？
节点异常后如何切走？
切换需要多久？
切换期间已有连接会怎样？

同一IP不代表进入同一个节点

采用Anycast后，不同地区查到相同IP完全可能是正常现象。

例如：

北京：203.0.113.20
上海：203.0.113.20
新加坡：203.0.113.20

三地的IP字符串相同，但路由终点可能不同。

这也是为什么查询IP地理位置经常会产生误导。数据库显示的可能是：

• IP注册机构所在地；

• 网络运营方地址；

• 某个代表性机房；

• 历史采集位置；

• 地址段的统一标注。

它不一定代表某次请求真正进入的边缘机房。

反过来，DNS调度返回不同IP，也不保证它们一定是三台不同的物理服务器。不同IP可能进入同一机房、同一节点集群或同一个Anycast网络。

有关IP变化的更多判断，可以参考为什么不同地区查到的CDN节点IP不一样？。

Anycast出现故障时怎样切换

当一个Anycast节点或机房不可用时，CDN可以停止从该位置公布相应路由，互联网随后可能把新流量送到其他仍在公布该地址的节点。

这个过程对DNS答案来说可能没有变化：

故障前：203.0.113.20 → 节点A
故障后：203.0.113.20 → 节点B

优势是用户不必等待DNS答案更换，IP地址也可以保持不变。

但这不等于切换绝对无感：

• 路由变化需要传播和收敛时间；

• 已建立的TCP或QUIC连接可能中断；

• 新节点的缓存状态可能不同；

• 路由撤销范围不正确时，用户可能被引到更远节点；

• 节点服务异常但路由仍在广播时，流量可能继续进入故障节点。

Anycast只解决“相同地址如何从多个位置提供服务”的问题，不会自动完成应用健康检查、配置同步、缓存一致性和会话处理。

DNS调度出现故障时怎样切换

DNS调度可以通过健康检查或人工策略，把后续查询切换到其他节点：

故障前：
www.example.com → 203.0.113.31

切换后：
www.example.com → 203.0.113.42

但用户什么时候取得新答案，受到多层缓存影响：

浏览器DNS缓存
操作系统DNS缓存
本地路由器缓存
运营商或公共递归DNS缓存
权威DNS返回记录的TTL

即使权威DNS已经修改，部分用户仍可能在一段时间内使用旧IP。已经建立的长连接也不会因为DNS答案改变而自动迁移。

将TTL设置得很低可以缩短部分缓存周期，但不是“立即切换”按钮。过低的TTL还会增加解析查询频率，并使权威DNS和调度系统的稳定性变得更重要。

关于DNS缓存、TTL以及递归解析器的影响，可以继续阅读DNS解析慢会拖慢CDN吗？域名解析耗时怎么排查。

EDNS Client Subnet为什么会影响DNS调度

权威DNS通常看到的是递归解析器IP，而不是最终用户IP。EDNS Client Subnet，简称ECS，可以让递归解析器在查询中携带部分客户端网段信息，帮助权威DNS做更接近用户位置的回答。

RFC 7871定义了这一DNS扩展，用于携带发起查询的网络信息以及后续答案适用的网络范围。

但ECS并不是所有解析器都支持，也不是所有CDN都会以相同方式使用。它还会带来两个现实取舍：

• 传递的客户端网段越具体，位置判断可能越精细，但隐私暴露也越多；

• 按网段生成更多DNS答案，会降低递归缓存的复用效率。

因此，用户切换运营商DNS或公共DNS后，可能得到不同CDN IP。这不一定说明其中一个DNS发生劫持，也可能只是递归解析器位置、ECS支持和缓存策略不同。

怎样判断网站更像使用了哪种调度

只能进行外部观察时，可以从多个地区收集DNS和网络结果，但不要依赖单一现象下结论。

第一步：查看CNAME、A和AAAA

dig www.example.com CNAME +noall +answer
dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer

记录：

CNAME链
IPv4地址
IPv6地址
TTL
查询时间
使用的递归DNS

第二步：比较不同递归DNS的答案

dig @1.1.1.1 www.example.com A +noall +answer
dig @8.8.8.8 www.example.com A +noall +answer

如果答案不同，说明可能存在DNS调度，也可能只是不同解析器缓存了不同时间取得的结果。

公共DNS本身也可能采用Anycast，命令发出的查询会进入离测试者较近的解析节点。它不能模拟北京、伦敦或纽约的真实用户环境。

第三步：从不同地区实际连接

curl -sS -o /dev/null \
  -w 'ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/

真正有价值的是同时保存：

测试地区和运营商
DNS返回地址
实际连接地址
TCP连接时间
TLS完成时间
TTFB
状态码

如果不同地区得到相同IP，但连接时间和网络路径明显不同，可能存在Anycast；如果不同地区稳定取得不同IP，则可能存在DNS区域或线路调度。

两种现象都只能作为证据之一。可以使用CDNChart的CDN检测工具查看CNAME、A/AAAA、ASN和厂商线索，再结合多地区网站测速观察实际连接结果。

第四步：比较网络路径

traceroute www.example.com

或：

mtr -rwzc 30 www.example.com

从多个地区对相同IP执行测试，如果路径最终进入不同区域或网络入口，可以进一步支持Anycast判断。

但Traceroute也有边界：

• 部分节点不回复ICMP；

• 中间路由器可能隐藏；

• 返回路径与去程路径可能不同；

• MPLS等网络可能不显示真实内部路径；

• IP地理定位可能不准确。

因此，外部测试通常只能判断“疑似Anycast”或“疑似DNS调度”，无法完整还原厂商内部路由设计。

Anycast一定比DNS调度快吗

不一定。

Anycast的优势在于使用稳定地址并利用网络路由选择入口，可能减少对精细DNS定位的依赖。但如果某个运营商把流量送到较远节点，Anycast同样可能出现绕路。

DNS调度可以针对地区和运营商返回不同节点，在网络差异明显的市场中更容易实施精细策略。但如果递归DNS位置判断不准、TTL缓存旧答案或权威DNS调度错误，也会把用户分配到不合适的入口。

决定访问速度的是整条路径：

DNS解析
→ 节点选择
→ 网络路由
→ TCP或QUIC连接
→ TLS握手
→ CDN缓存
→ 回源
→ 内容传输

调度技术只是其中一部分。一个设计优秀的DNS调度CDN，可能比路由质量较差的Anycast CDN更快；反过来也一样。

Anycast一定更抗DDoS吗

Anycast可以让多个节点同时公布同一服务地址，攻击流量可能被分散到多个网络入口，因此常被用于大型公共服务和DDoS防护网络。

但“使用Anycast”不等于“自动拥有无限防护能力”。真正的防护结果还取决于：

• 总网络容量；

• 各地区清洗能力；

• 攻击检测与牵引策略；

• 上游运营商合作；

• 路由控制能力；

• 单节点容量和隔离设计；

• 应用层WAF、限速和Bot管理；

• 故障节点是否能够及时撤销路由。

DNS调度同样可以把流量分配到不同节点或切换到备用网络。选择高防CDN时，应核对防护边界、清洗位置和故障处置方式，不能只看是否宣传Anycast。

普通网站需要关心到什么程度

如果网站用户集中在单一地区，业务以普通企业展示、博客或中小型电商为主，通常不需要因为Anycast和DNS调度的技术名称做决定。更应该测试：

• 主要用户地区访问是否稳定；

• 本地运营商是否存在明显慢线路；

• IPv4和IPv6表现是否一致；

• TLS、TTFB和下载速度是否合理；

• 节点故障时能否恢复；

• 缓存、回源和安全功能是否满足需求；

• 套餐费用与技术支持是否匹配。

以下业务则更应该了解调度方式：

用户分布跨多个国家和地区

需要确认各区域如何选择节点，是否存在跨洲绕行，以及故障后会切换到哪里。

国内涉及多个运营商

电信、联通、移动及其他网络之间的互联质量可能不同。精细DNS线路调度、区域Anycast或两者组合都可能影响实际结果。

实时互动、游戏和直播业务

这类业务对抖动、丢包、路径变化和长连接稳定性更敏感。不能只看网页首字节，还要关注会话期间路由变化和连接连续性。

高可用或多CDN架构

多CDN通常会在DNS或更上层的流量调度系统中选择厂商，而每家CDN内部又可能采用Anycast。具体可以参考一个网站能用多个CDN吗？多家检测结果怎么看。

DDoS风险较高的业务

需要确认Anycast入口、清洗中心、路由撤销、备用网络和应用层防护如何配合，而不是只看节点数量。

选择CDN时应该问哪些问题

与其只问“你们是不是Anycast”，不如把问题拆得更具体：

主要用户地区通过什么方式选择节点？
是否按运营商或网络线路进行调度？
IPv4和IPv6是否采用相同覆盖范围？
同一Anycast地址在哪些地区公布？
节点故障时通过BGP还是DNS切换？
DNS调度记录的TTL是多少？
递归DNS定位错误时如何处理？
是否支持ECS，使用到什么网段范围？
故障节点退出后，已有连接如何处理？
能否提供目标地区的测试域名和实时数据？

厂商能够说清这些问题，比单独展示“全球Anycast网络”几个字更有参考价值。

常见问题

Anycast CDN查询出来一定只有一个IP吗？

不一定。CDN可能提供多个IPv4或IPv6 Anycast地址，也可能先通过DNS返回不同地址池。多个IP不代表没有使用Anycast。

不同地区查到相同IP，就一定是Anycast吗？

不一定。相同IP可能是Anycast入口，也可能只是固定的单点、区域网关或负载均衡地址。还需要结合多地区网络路径、ASN、延迟和厂商资料判断。

不同地区查到不同IP，就一定是DNS调度吗？

通常说明DNS答案存在差异，但也可能来自缓存时间不同、记录轮询或配置变更。需要在相同时间、多个真实地区重复查询。

更换公共DNS会影响CDN节点吗？

可能会。CDN权威DNS可能根据递归解析器位置或ECS信息返回地址。更换解析器后，用户可能获得不同节点，但不同不代表一定更快。

Anycast节点故障后会立即切走吗？

不能保证立即。路由撤销和BGP收敛需要时间，已建立连接也可能中断。具体恢复时间取决于CDN的路由、健康检查和网络设计。

DNS TTL越低，故障切换就一定越快吗？

不一定。低TTL有助于更快取得新答案，但递归DNS、操作系统和应用可能仍有缓存，已有连接也不会因为DNS更新自动迁移。TTL还需要在切换速度和解析负载之间平衡。

Anycast更适合全球网站，DNS调度更适合国内网站吗？

不能简单这样划分。全球CDN也经常结合DNS调度，国内网络也可以使用Anycast或区域Anycast。应根据节点覆盖、运营商线路、路由质量和实际测试结果判断。

普通网站应该优先选哪一种？

普通网站无需把Anycast或DNS调度作为唯一筛选条件。先比较目标地区的成功率、P50/P95延迟、TLS、TTFB、下载表现和故障恢复能力。如果两家表现接近，再考虑调度架构、日志能力、成本和技术支持。