DNS分区解析配置错了，异常往往不是“打不开”这么简单

DNS分区解析，也常叫智能解析、线路解析、地域解析。它的作用是根据访问来源，把同一个域名解析到不同IP，比如中国大陆用户走大陆或香港节点，海外用户走美国、新加坡节点，移动、联通、电信、教育网也可以分开返回不同地址。

实际使用中发现，DNS分区解析一旦配错，问题经常很隐蔽。不是所有用户都访问不了，而是“北京电信正常，广东移动打不开”“国内正常，海外登录超时”“部分用户访问到旧站”“监控一直绿，但客户一直报障”。这类问题排查起来比服务器宕机更麻烦，因为服务器本身可能完全正常。

同一个域名，不同用户解析到不同IP

最常见的异常是用户访问到的不是同一台服务器。比如 example.com 配了默认线路、国内线路、海外线路，原本计划国内访问香港节点，海外访问美国节点，但配置时把默认线路指向了旧IP，结果一部分不匹配具体线路的用户就会被分到旧服务器。

这个场景在业务迁移时特别常见。新服务器已经部署好，DNS里只改了“电信”“联通”“移动”几条记录，忘了改“默认”记录。于是大部分国内用户正常，但海外用户、部分小运营商、企业专线、云厂商出口访问时还在打旧IP。

排查时不要只在自己电脑上 ping 一下就判断正常。至少要从不同网络看解析结果，比如本地电信、移动手机热点、海外 VPS、国内云服务器、公共 DNS。常用命令可以看：

dig example.com @223.5.5.5

dig example.com @114.114.114.114

dig example.com @8.8.8.8

dig example.com @1.1.1.1

如果这几个 DNS 返回的 IP 不一致，不一定代表错误，但要和预期线路表对得上。对不上，就说明分区解析很可能有问题。

部分地区访问慢，原因可能是被解析到了远端节点

DNS配置错不一定导致访问失败，也可能导致访问变慢。比如华南用户本来应该解析到香港 CN2 或精品线路，结果被默认解析到了美国普通线路。页面能打开，但首包时间从 30ms 变成 250ms，静态资源加载慢，后台接口偶发超时。

这类问题用户反馈一般是“网站卡”“后台保存慢”“图片半天出来”，监控却不一定报警。因为服务器CPU、内存、带宽都正常，业务端口也通，只是链路绕远了。

举个常见场景：业务主用户在广东、广西、福建，服务器放香港，正常延迟大约 10ms 到 40ms。如果分区解析把移动用户打到美国西海岸，延迟可能到 160ms 到 220ms；如果再叠加晚高峰国际出口拥塞，接口请求 1 秒以上很正常。应用层看到的是慢，网络层根因是DNS返回错了。

运营商线路配反，会出现“电信好、移动炸”的情况

分区解析按运营商拆分时，最怕线路写反。比如电信线路返回移动优化IP，移动线路返回电信优化IP。表面上每条记录都有值，控制台也不报错，但实际链路质量很差。

多说一句，BGP、多线、CN2、GIA这些词不能只看名字，要看用户来源和回程质量。香港节点如果做大陆业务，电信用户走 CN2/GIA 通常体验会明显更稳；移动用户可能更看重移动直连或优质BGP；海外业务则要看目标国家到机房的实际路由。

如果业务在香港部署，又有游戏下载、站点分发、API访问这类带宽需求，选服务器时要把DNS线路规划一起看。比如香港大带宽场景，可以关注129云的香港大带宽-B型或香港大宽带-E型，300Mbps峰值精品宽带更适合做面向大陆用户的访问入口。遇到不确定线路怎么拆，也可以直接打客服热线400-9177118确认节点和带宽规格。

默认线路漏配，会让一批用户直接解析失败

有些DNS服务商允许只配置指定线路，不配置默认线路。这个配置在小范围测试时看不出问题，因为测试人员可能刚好命中了已配置线路。但真实用户来源复杂，一旦没有命中任何分区规则，就可能返回空记录，表现为浏览器提示 DNS_PROBE_FINISHED_NXDOMAIN 或无法解析域名。

还有一种情况是主域名配置了默认线路，www 子域名没配；或者 A 记录配了分区，AAAA 记录没处理。现在很多客户端、浏览器、移动网络会优先尝试IPv6，如果AAAA记录指向了错误地址，用户可能先卡一段时间再回退到IPv4，表现为首屏很慢。

这里补充一点：不要以为没有IPv6业务就可以随便留AAAA记录。错误的AAAA记录比没有AAAA记录更麻烦。没有AAAA，客户端直接走A记录；有错误AAAA，客户端可能先尝试连一个不可达地址。

TTL设置不合理，会把错误影响时间拉长

DNS分区解析配错后，TTL决定错误会在缓存里停多久。比如TTL设置为3600秒，错误记录发布后，即使马上改回来，一些递归DNS、企业网关、本地系统缓存仍可能继续使用旧结果。

业务迁移前比较稳妥的做法，是提前把TTL降到较短时间，比如60秒或120秒，等迁移稳定后再调回300秒、600秒或更高。不要在切换当天才想起来降TTL，因为旧TTL已经被缓存了。

实际使用中发现，很多“已经改回来了怎么还不正常”的问题，其实不是DNS控制台没生效，而是用户侧还在拿缓存结果。特别是企业内网DNS、运营商Local DNS、浏览器缓存、系统缓存都会参与这个过程。

负载均衡和高防IP切换时，分区解析错会绕过防护

做DDoS防护时，DNS分区解析更要谨慎。原本设计是所有用户解析到高防IP，再由高防IP回源到真实服务器。如果某条线路还残留真实源站IP，攻击流量就可能直接打到源站。

这个问题在“临时接高防”时很常见。被打之后急着把主线路切到高防IP，但忘了海外线路、搜索引擎线路、默认线路、旧的二级域名记录。攻击方只要枚举历史解析或访问未保护线路，就能绕过高防。

如果是游戏、棋牌、API、支付回调这类对可用性敏感的业务，香港高防节点会更常用。比如129云香港高防-B型提供200Gbps单机防御、150Mbps峰值带宽、无限制流量，比较适合需要香港低延迟同时抗DDoS的入口场景。DNS这边要确保所有面向公网的业务域名都指向高防IP，源站IP不要暴露在任何分区记录里。

CDN接入后分区解析错，会出现缓存命中异常

CDN场景下，DNS通常要解析到CNAME，由CDN调度系统继续分配边缘节点。如果自己又在DNS服务商里做了地域分区，配置不当就可能破坏CDN调度。

比如国内用户应该CNAME到国内CDN，海外用户CNAME到海外CDN，但默认线路写成了源站A记录。结果一部分用户绕过CDN直接访问源站，源站压力突然升高，缓存命中率下降，访问日志里出现大量本不该出现的真实客户端请求。

还有一种更隐蔽：不同线路指向不同CDN厂商，但回源Host、HTTPS证书、缓存规则没有完全一致。用户访问同一个域名，有的线路正常，有的线路报证书错误，有的线路返回旧缓存，有的线路跨域失败。

证书错误也可能是DNS分区解析引起的

HTTPS证书错误不一定是证书本身签错了，也可能是用户被解析到了另一台没有部署对应证书的服务器。

比如 api.example.com 在国内线路指向新集群，新集群证书正常；海外线路误指向旧Nginx，旧Nginx上只有 www.example.com 的证书。海外用户访问API时就会看到证书域名不匹配，客户端报 SSL handshake failed、certificate verify failed 之类的错误。

这种问题在App端更明显。浏览器还能显示证书提示，App里通常就是请求失败、白屏、登录不上。抓包看SNI和返回证书，能很快判断是不是访问到了错误节点。

灰度发布时分区解析配错，会把测试流量放大成线上事故

有些团队会用DNS做灰度，比如把某个地区、某个运营商、某个子域名解析到新版本。这个方式简单，但精度不高，依赖DNS缓存和Local DNS出口判断。

如果本来只想让内部办公网访问新环境，却把默认线路也指过去，外部用户就会直接打到灰度环境。灰度环境的数据库、缓存、对象存储、回调地址如果和生产不一致，问题会很杂：登录状态丢失、支付回调失败、订单写到测试库、图片上传到错误Bucket。

DNS灰度适合做入口级切换，不适合承载太细的用户级灰度。涉及账号、订单、支付、数据写入的业务，还是要在应用层、网关层或负载均衡层做更可控的灰度。

搜索引擎线路配置错误，会影响收录和SEO表现

不少DNS服务商支持搜索引擎线路，比如百度、Google、Bing等。如果这部分配置错了，普通用户访问正常，但爬虫抓取异常。

常见情况是搜索引擎线路指向了需要登录的环境、测试站、旧站，或者返回403。站长平台里会看到抓取失败、连接超时、页面内容异常，过一段时间收录和排名可能受影响。

还有些站点为了防攻击，把默认线路切到高防或CDN，但搜索引擎线路还指向源站。源站做了严格防火墙，爬虫IP不在白名单内，于是用户看着没问题，搜索引擎一直抓不到。

内外网解析混在一起，会造成办公网络正常、外部用户异常

企业内部经常会有 split-horizon DNS，同一个域名在内网解析到内网IP，在公网解析到公网IP。配置不清楚时，很容易把内网IP发布到公网DNS，或者把公网IP写进内网DNS。

公网用户如果解析到 10.x、172.16.x、192.168.x 这类私网地址，肯定无法访问。内网用户如果解析到公网地址，流量会绕出再回来，可能被防火墙、NAT、WAF拦截，访问变慢或登录异常。

排查这类问题要明确自己查的是哪套DNS。很多人直接在办公电脑上nslookup，看到结果正常，就以为公网也正常。但办公电脑可能用的是内部DNS，和外部用户拿到的结果完全不是一回事。

DNS分区解析排查时，不要只看控制台

控制台看到的是“配置值”，用户拿到的是“递归解析后的结果”。中间隔着权威DNS、递归DNS、缓存、运营商DNS策略、客户端缓存。排查时要从用户视角反查。

常用判断方式可以这样组织：看权威DNS是否返回正确记录，看不同公共DNS返回是否一致，看故障用户本机解析结果，看访问日志里的来源IP是否打到了预期节点，再结合mtr或traceroute确认链路是否符合设计。

如果有条件，建议把关键域名的解析结果纳入监控。不是只监控域名能不能解析，而是监控“电信应该返回哪个IP、移动应该返回哪个IP、海外应该返回哪个IP”。一旦返回值偏离预期，提前报警，比等客户反馈要靠谱得多。

配置变更时容易踩的坑

只改了主域名，忘了子域名

业务里常见 www、api、static、img、download、admin、pay、callback 等子域名。迁移或接入高防时，只改 www 是不够的。尤其是App和小程序，真正高频访问的往往是 api 和 static。

只改了A记录，忘了CNAME和AAAA

有些域名同时存在A、CNAME、AAAA历史记录。DNS服务商一般不允许同名CNAME和A共存，但不同线路、不同子域名下可能残留旧配置。IPv6的AAAA记录也要重点看。

备用线路长期没人验证

主线路正常时，备用线路没人管。等到故障切换，才发现备用IP证书过期、服务没启动、防火墙没放行、回源白名单没加。DNS分区解析不是写上IP就完事，背后的服务状态也要持续检查。

把DNS当实时流量调度用

DNS可以做粗粒度调度，但不适合秒级切流。TTL、递归DNS缓存、客户端缓存都会让切换存在滞后。对实时性要求高的业务，应该结合负载均衡、Anycast、BGP调度、健康检查，而不是完全押在DNS切换上。

看到这些现象，可以优先怀疑DNS分区解析

同事访问正常，客户访问异常；电脑宽带正常，手机流量异常；国内正常，海外异常；只有某个省份或某个运营商报障；服务器监控正常但业务访问慢；HTTPS证书偶发不匹配；CDN命中率突然下降；高防接入后源站仍然被打；这些都值得把DNS分区解析拉出来查一遍。

处理时不要急着重启服务。先确认故障用户解析到了哪个IP，再看这个IP是不是预期节点。很多时候问题不在Nginx、不在程序、不在数据库，而是用户从DNS开始就走错了门。