开了加速，反而有人打不开

给站点接上 DNS 加速解析之后，我以为访问会更快，结果陆续有用户反馈打不开，而我本地一切正常。查来查去，问题不在服务器，在调度：某个运营商被指到了一个根本不通的节点。

加速解析的卖点是「按来源给不同答案」，这也意味着判断标准变了。以前看各地解析是否一致，现在要看每个地区拿到的答案，是不是真的适合它。

一致性不再是标准，合适才是

普通解析要求各地指向同一个地址，加速解析恰恰相反：电信拿电信附近的节点，移动拿移动的节点，跨省跨运营商各走各的路。

所以巡检时看到各地结果不同，先别慌。要看的是这些结果属于谁、是不是你配置的那批节点、有没有混进陌生地址。

我用宝塔拨测的 DNS 测速查的时候，会分别看 A 记录和 CNAME 记录，再按电信、联通、移动分组对照。分组之后，某个运营商整片指错的情况很容易暴露出来。

DNS 查询：多地区多运营商解析结果对比

DNS 查询：多地区多运营商解析结果对比

CNAME 链是常见故障点

很多加速服务是让你把域名 CNAME 到它的调度域名，再由它返回实际节点。这一层如果配错，前面查什么都对不上。

链太长同样有代价：每多一级，就多一次解析往返，用户在等首屏之前先等了解析。CNAME 指向的域名如果失效或者拼错，表现就是部分地区完全解析不出来。

查的时候顺着链路一层层看，别只看最终那个 IP。

解析耗时和响应最慢节点

加速做得再好，解析环节也需要时间。页面会给出响应最快、响应最慢和平均响应，我主要盯最慢的那几个节点。

如果某个地区持续偏慢，可能是当地的递归服务器还没缓存，也可能是调度把它指到了远端节点。这两种处理方式不一样：前者等 TTL 过去就好，后者得改调度配置。

解析快也不代表访问快。解析返回一个不通的节点，耗时再漂亮也没意义。所以我习惯把解析结果和实际连通性放在一起看。

TTL 与缓存的拉扯

加速解析常用较短的 TTL，为的是故障时能快速切走。但 TTL 太短，递归服务器会频繁回源，高峰时权威侧压力大，解析耗时反而抖。

故障切换期间，旧记录还会在各个递归里残留一阵，这时候各地结果不一致是正常的。判断依据不是「一致」，而是「新的正确结果在变多、错误的在变少」。

复测和该警惕的信号

改完调度或记录，连续复测两三次，看同一批运营商的结果是否稳定、异常地区是否收敛、耗时有没有回落。只看一次，很容易被缓存误导。

值得警惕的情况有几种：某家运营商固定返回不属于你的 IP、CNAME 目标域名解析失败、TTL 和后台配置对不上、解析耗时在故障切换后迟迟不恢复。碰上这些，先查调度和记录，别急着怪用户网络。