全国监控大部分正常，只有某个省份的移动用户打不开；或者同一城市电信正常、联通超时。这类区域性故障通常不代表源站整体宕机，也不能只凭“域名在我这里能解析”就排除DNS。智能DNS和CDN可能根据递归DNS、运营商、地理位置和网络质量把用户调度到不同节点，真正需要对照的是：故障用户解析到了哪个地址、实际连接了哪个协议和节点、请求有没有到达边缘与源站。
为什么同一个域名在不同地区结果不同
| 调度或网络因素 | 可能造成的差异 |
|---|---|
| 智能DNS线路解析 | 按运营商或地区返回不同A、AAAA或CNAME |
| CDN DNS调度 | 不同递归DNS被分配到不同边缘节点 |
| Anycast | 同一个IP经BGP到达不同节点或入口 |
| IPv4/IPv6优先级 | 部分网络优先走AAAA，另一些只使用A |
| 运营商互联 | 跨网路径、拥塞或路由策略导致可达性不同 |
| 区域WAF规则 | 某节点或规则组误拦截特定来源 |
因此，“北京和广州都解析到同一IP”也不能完全证明访问同一台物理服务器，Anycast可能让两个地区进入不同节点；“两地解析IP不同”也不代表其中一个错误，可能正是正常的CDN调度。
先把故障描述变成可用数据
一句“广东打不开”信息不足。至少收集：
- 省市、运营商和接入方式，例如家庭宽带或移动网络；
- 故障发生时间、持续时长和是否间歇恢复；
- 访问的完整域名，不公开收集不必要的账号或个人数据；
- A、AAAA和CNAME查询结果，以及所用递归DNS；
- 浏览器实际连接的远程IP、IPv4或IPv6；
- 错误类型：无法解析、连接超时、证书错误、403、502还是504；
- CDN请求ID或响应头中的节点标识。
如果用户不会执行命令，可以让其提供浏览器错误码、IP查询结果和问题时间，再由运维使用同地区授权探针补测。截图中应遮盖账号、Cookie、令牌等敏感信息。
第一步：比较故障地区与正常地区的DNS
- 固定域名和时间段。CDN调度会变化，隔几个小时的结果不能直接代表故障当时。
- 分别记录A、AAAA和CNAME。不要只看一个最终IPv4。CNAME链可能指向不同CDN区域，AAAA也可能独立故障。
- 记录递归DNS。运营商默认DNS、公共DNS和浏览器DoH可能得到不同调度。没有查询服务器信息的截图证据不完整。
- 核对权威线路规则。检查是否为某运营商配置了专用记录，是否存在默认线路遗漏、错误IP或已下线节点。
- 检查TTL和变更时间。若刚切换节点，某递归DNS可能仍缓存旧地址，需要与修改前TTL一起判断。
多地解析工具可从极跃圈网址导航选择，但应关注探针运营商、递归来源、IPv6支持和采样时间，不要只看地图上的绿色或红色。
第二步：确认解析地址对应哪个节点
在CDN控制台或资产清单中查明该IP属于哪个边缘区域、哪家运营商线路和哪个站点配置。若同一个IP使用Anycast，可结合traceroute末端路径、响应头节点代码和CDN日志识别实际入口，IP归属地城市只能作辅助。
如果故障地区被调度到一个已下线、证书未部署或回源异常的节点，而正常地区命中另一节点，修复重点在节点健康和调度摘除，不在源站DNS总记录。
第三步：区分IPv4故障还是IPv6故障
很多“只有某运营商打不开”实际是该网络提供了IPv6，客户端优先使用AAAA；其他网络没有IPv6，于是自动走正常的A记录。对故障网络分别执行IPv4和IPv6的HTTPS请求：
curl -4 -I https://example.com/
curl -6 -I https://example.com/若IPv4正常、IPv6超时，检查AAAA是否指向当前节点、CDN是否启用IPv6、服务器监听、上游路由和IPv6防火墙。不要仅以删除AAAA作为长期方案；临时撤销错误记录可以止损，最终仍需修复和外部复测。
第四步：看路径异常是否持续到目标
从故障运营商和正常运营商分别运行traceroute或MTR，记录同一时间段的路径、最终延迟和丢包。中间某一跳不回ICMP或显示高丢包，后续各跳却正常，通常不能证明该路由器转发故障；只有异常从某一段持续影响最后目标和HTTPS业务，才更值得定位。
如果同节点只有某运营商超时，而其他运营商正常，可能涉及互联、回程或区域路由。向CDN或运营商提交工单时，提供源地区与运营商、目标IP、故障时间、完整路径和请求结果，比一句“线路不稳定”更容易推进。
第五步：用状态码定位CDN、WAF与回源
| 用户现象 | 优先检查 |
|---|---|
| DNS超时或NXDOMAIN | 递归DNS、权威线路规则和DNSSEC |
| 连接超时 | 节点可达性、路由、安全策略和监听 |
| 证书错误 | 故障节点的证书部署、SNI和系统时间 |
| 403 | WAF、地区规则、来源限制和误封 |
| 502 | 节点到源站的连接、协议、Host和证书 |
| 504 | 回源响应超时、源站负载或链路质量 |
同一个状态码在不同服务商中的具体定义可能略有差异，应结合当前平台文档。最重要的是拿到请求ID，在CDN日志中确认请求进入了哪个节点、命中了哪条规则、是否发起回源，以及源站返回了什么。
源站日志正常为什么仍有用户打不开
如果故障请求根本没有到达源站，源站日志当然看起来正常。请求可能在DNS阶段失败、被路由丢弃、停在CDN边缘或被WAF拦截。应把监控分成递归解析、边缘可达、TLS、CDN状态和回源五层，而不是只监控源站首页。
相反，如果CDN显示回源成功且源站返回200，用户仍看到异常，还要检查边缘缓存是否存了错误页面、浏览器是否复用旧连接，以及响应内容是否依赖地区或账号。
修复后怎么验收，避免“自己能打开就结案”
- 从原故障省份和运营商复测，不用办公室网络代替；
- 同时测试IPv4、IPv6和浏览器真实访问；
- 确认解析节点、证书、HTTP状态和请求ID均符合预期；
- 观察至少覆盖原故障持续周期，并检查错误率是否恢复；
- 保留正常地区作为对照，防止调整线路后把问题转移到别处；
- 记录DNS、CDN或WAF的变更和回滚方案。
区域故障工单最好整理为一条时间线：何时、哪个省份与运营商、解析到哪个IPv4/IPv6、经过什么路径、获得什么状态码、请求落到哪个节点、源站是否收到。把这组证据串起来，才能判断是智能DNS误调度、区域节点故障、IPv6配置还是运营商互联问题。
