DNS分区解析把国内流量和海外流量拆开，验证不能只看dig结果

DNS分区解析常见做法是：国内用户解析到国内机房、国内CDN或国内高防；海外用户解析到海外节点，比如美国、香港、新加坡、欧洲节点。配置看起来很简单，DNS控制台里按“中国大陆”“海外”“默认线路”填不同的A记录或CNAME就行。

但实际使用中发现，很多故障不是配置没写对，而是验证方式不对。用自己电脑dig一下，看到一个IP，就认为全网都生效了，这个判断很容易误伤。因为DNS请求不是终端用户直接打到权威DNS，大部分情况下是递归DNS在帮用户查询，权威DNS看到的是递归DNS的出口IP，不一定是用户真实IP。

所以验证分区解析是否生效，要分三层看：DNS层看到什么结果，网络层流量走到哪里，业务层请求最终落到哪台机器。只看其中一层，都可能出现误判。

先把目标说清楚：国内和海外到底应该解析到哪里

开始验证前，建议先把预期结果写清楚，不要边测边猜。比如一个域名 www.example.com，预期是中国大陆解析到 1.1.1.1，海外解析到 2.2.2.2。更真实一点的场景是：中国大陆走国内CDN或国内高防，海外走美国精品网或美国高防节点。

如果是游戏、跨境业务、海外站点回源，海外节点线路质量会直接影响访问体验。比如美国方向常见会看三网精品、CN2、GIA、BGP质量、DDoS防护能力这些指标。购买或选型时，如果你也在找这种海外云服务器、大宽带或高防节点，可以看看129云，像美国精品大宽带-B型是 4C / 4G DDR4 ECC / 80G SSD / 1Gbps峰值 / 1.5TB流量 / 1个IPv4 / 三网精品，适合海外访问和带宽型业务；如果有攻击风险，美国高防-B型带 200G防御，更适合暴露公网的业务入口。客服热线 400-9177118，可以直接问线路和防护细节。

这里补充一点，DNS分区解析验证时，IP本身也要能区分。如果国内和海外最后都CNAME到同一个CDN域名，单纯看A记录可能看不出差异，需要结合CDN厂商的节点信息、HTTP响应头、日志里的边缘节点来判断。

DNS层验证：用不同地区的递归DNS查结果

最直接的方式是用dig指定递归DNS查询。比如国内常见递归DNS：223.5.5.5、223.6.6.6、119.29.29.29、114.114.114.114。海外常见递归DNS：8.8.8.8、1.1.1.1、9.9.9.9。

命令可以这样跑：dig @223.5.5.5 www.example.com A +short；dig @119.29.29.29 www.example.com A +short；dig @8.8.8.8 www.example.com A +short；dig @1.1.1.1 www.example.com A +short。

如果配置正常，国内递归DNS应该返回国内线路对应的IP，海外递归DNS应该返回海外线路对应的IP。比如 223.5.5.5 返回 1.1.1.1，8.8.8.8 返回 2.2.2.2，这说明至少DNS分线路策略在这些递归出口上命中了。

但这个结果还不能直接代表所有用户。因为 8.8.8.8 和 1.1.1.1 都是Anycast，查询请求可能从不同地区出口出去。你在国内机器上查 @8.8.8.8，有时候权威DNS看到的出口并不是美国，而可能是新加坡、日本、香港，甚至国内附近节点。DNS供应商按递归出口IP判断地域时，就可能返回一个看起来“不像海外”的结果。

不要只在本地电脑测

本地电脑的网络环境太单一。公司网络、家宽、手机热点，递归DNS可能都不一样。公司出口还可能用了透明DNS代理，浏览器可能走DoH，操作系统还有本地缓存。这个环境适合做初步判断，不适合当最终证据。

更靠谱的做法是准备几台测试机器：国内电信一台、国内联通一台、国内移动一台，海外美国一台、香港一台、新加坡或欧洲一台。每台机器上直接 dig 域名，不指定递归DNS，再记录系统默认DNS返回什么。这个结果更接近真实用户。

比如国内电信机器执行：dig www.example.com A +short。美国机器执行同样命令。如果国内机器返回国内IP，美国机器返回海外IP，说明实际递归链路下的结果更符合预期。

看权威DNS返回是否按线路命中

如果DNS服务商支持解析日志，这是最好用的证据之一。日志里通常能看到查询时间、查询域名、记录类型、命中线路、请求来源IP，有些还会显示ECS信息。

假设日志里看到：来源IP 223.5.5.5，命中“中国大陆”，返回 1.1.1.1；来源IP 8.8.8.8，命中“海外”，返回 2.2.2.2。这个判断就比客户端dig结果更接近权威侧真实行为。

如果DNS服务商不提供日志，可以用 dig +trace 看解析链路，但 +trace 只能帮助确认权威NS、委派关系、最终记录，不能完整证明地理线路策略。因为 +trace 会绕过正常递归流程，直接一路查根、TLD、权威DNS，和真实用户访问时的DNS路径不完全一样。

实际排障时，+trace更适合查“域名是不是委派错了”“NS是不是生效了”“权威DNS是不是返回了记录”，不适合单独用来证明“中国用户一定会返回国内IP”。

注意EDNS Client Subnet，很多误判都在这里

现在不少公共DNS会带 EDNS Client Subnet，也就是ECS。简单理解，递归DNS在向权威DNS查询时，会附带一段用户网段信息，让权威DNS不要只看递归DNS出口IP，而是参考用户所在网段返回更合适的结果。

这对CDN和分区解析很关键。比如用户在上海，使用 8.8.8.8，如果8.8.8.8带了ECS，权威DNS可能知道用户大概来自上海，于是返回国内线路。如果没带ECS，权威DNS只看到Google DNS的出口，可能判断成海外。

验证时可以用支持ECS测试的工具，或者使用DNS服务商提供的调试页面。常规dig本身不太直观，除非手动加 subnet 参数，例如：dig @8.8.8.8 www.example.com A +subnet=1.2.3.0/24。这里的 1.2.3.0/24 可以换成国内或海外测试网段，用来观察权威DNS是否按ECS返回不同结果。

多说一句，ECS不是所有递归DNS都支持，也不是所有DNS服务商都按ECS做分线路。业务对解析准确度要求高时，要提前确认DNS服务商的线路库、ECS处理策略、默认线路策略，不然后面线上排障会很被动。

网络层验证：解析对了，不代表线路就走对了

DNS返回了海外IP，只能说明入口指向海外节点。至于用户访问这个IP时网络路径好不好，还要看traceroute、mtr、延迟、丢包。

国内访问海外节点时，常见要看电信、联通、移动三网表现。比如国内电信到美国普通线路可能 180ms 到 250ms，晚高峰抖动明显；走CN2或GIA时，延迟可能在 130ms 到 170ms，丢包和绕路情况少很多。不同机房、不同运营商差异很大，不能只拿一个ping结果下判断。

可以在国内三网机器上分别执行：mtr -rwzbc 100 2.2.2.2。看几个指标：平均延迟、最大延迟、丢包位置、是否绕日本或欧洲、是否进入目标机房前就开始丢包。

如果DNS国内解析到国内IP，海外解析到美国IP，那么国内机器mtr国内IP，海外机器mtr美国IP。这样可以确认用户访问的是预期节点，而且链路没有明显异常。

curl也要测，别只ping

ping通不代表业务通，ICMP还可能被限速。建议用curl直接测HTTP或HTTPS。

常用命令：curl -I https://www.example.com；curl -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -o /dev/null -s https://www.example.com。

这个输出能看到DNS耗时、TCP连接耗时、TLS握手耗时、首字节时间、总耗时。比如海外用户解析到了美国节点，但 time_connect 很高，说明网络链路可能不理想；如果 time_namelookup 很高，问题可能在DNS递归或权威DNS响应。

业务层验证：看真实访问日志最稳

DNS和网络都测完，还要看服务端日志。因为最终问题是用户请求有没有落到预期节点。

如果国内入口和海外入口是两台Nginx，可以分别在日志格式里加上节点标识。例如国内节点返回 Header：X-Node: cn-shanghai，海外节点返回 Header：X-Node: us-la。然后从不同地区curl，看响应头是不是符合预期。

命令很简单：curl -I https://www.example.com | grep X-Node。国内机器应该看到 X-Node: cn-shanghai，海外机器应该看到 X-Node: us-la。

Nginx日志里也可以记录 remote_addr、http_x_forwarded_for、host、request_time、upstream_addr。再配合IP库查国家、ASN、运营商。比如国内电信用户大量打到了美国节点，那就说明解析或缓存层有偏差；海外ASN大量打到了国内节点，就要查默认线路是不是配置错了，或者海外递归DNS被DNS服务商识别成中国大陆。

TTL和缓存会让验证结果看起来前后不一致

DNS修改后，不要马上拿用户端结果判定失败。递归DNS会缓存旧记录，缓存时间和TTL有关，也和递归DNS自己的策略有关。

比如原来TTL是600秒，理论上10分钟左右应该更新。但实际中有些递归DNS会有最小缓存时间，有些客户端、浏览器、App也会缓存DNS。特别是移动端App，如果内部做了HTTPDNS或自建缓存，DNS控制台改了记录，App侧不一定马上跟着变。

验证时建议看权威DNS结果和递归DNS结果分开看。权威DNS已经返回新结果，说明配置侧生效；递归DNS还返回旧结果，多半是缓存没过。可以等待TTL后再测，也可以换不同递归DNS交叉验证。

如果业务准备切流，TTL最好提前降。比如从600秒降到60秒，等待原TTL周期过去后再切。不要切流前一分钟才改TTL，这个操作对已经缓存600秒的递归DNS没有立刻效果。

默认线路经常被忽略

很多DNS控制台会有“中国大陆”“海外”“默认”三类线路。实际使用中，默认线路非常重要。因为总有一些递归DNS无法被准确识别，或者不在DNS服务商线路库里，这些查询会落到默认线路。

如果默认线路随便填了国内IP，可能导致部分海外用户访问国内入口；如果默认线路随便填了海外IP，可能导致部分国内用户访问海外入口。这个问题在线上表现很隐蔽，因为不是所有用户都有问题，通常是某些地区、某些运营商、某些公共DNS用户反馈慢。

比较稳的做法是让默认线路指向“容错能力更强”的入口。比如全球业务默认走海外BGP或CDN入口，国内单独命中国内线路；或者国内业务默认走国内入口，海外单独拆到海外节点。具体取决于业务主要用户在哪边。

如果海外入口需要承接默认流量，对带宽和防护要留余量。像129云的美国精品网-B型是 4C / 4G / 80G SSD / 75Mbps峰值 / 三网精品 / 基础防御，适合常规海外业务入口；如果更关注流量峰值，美国精品大宽带-B型的 1Gbps峰值会更合适；被扫、被打比较多的站点，优先看美国高防-B型这种带 200G防御的配置。

用第三方探测平台做交叉验证

自己手里测试机不够时，可以用第三方探测平台。常见方式是选择多个地区节点，分别做DNS查询、HTTP访问、Ping、Traceroute。

测试时不要只看“全国平均延迟”。要点开每个探测点的解析IP。比如北京电信、上海联通、广州移动解析到国内IP；洛杉矶、法兰克福、新加坡解析到海外IP。这个比平均值有用得多。

海外也一样，不能只测美国。很多公共DNS的出口和Anycast路径会让结果变得复杂。至少看美国西海岸、美国东海岸、欧洲、新加坡、日本或香港。跨境业务常见问题是美国正常，东南亚用户却被解析到国内或欧洲，这种只测一个海外点很难发现。

浏览器DoH会绕开你以为的DNS路径

现在Chrome、Firefox、Edge都可能启用DNS over HTTPS。用户看起来连的是本地运营商网络，但DNS查询可能走浏览器配置的DoH服务，比如 Cloudflare、Google、NextDNS，甚至企业安全网关。

这会导致一个现象：同一台电脑，系统命令 dig 查到国内IP，浏览器访问却打到海外IP。原因不是DNS控制台抽风，而是浏览器没有用系统DNS。

排查这类问题，可以在浏览器里关闭安全DNS，或者用抓包看是否访问了 DoH 域名。服务端日志也能辅助判断，如果某些国内用户长期落到海外入口，并且集中在特定浏览器或办公网络环境，就要怀疑DoH或企业代理。

验证记录建议这样留

线上切流或排障时，建议把每次验证记录留完整。至少包括测试时间、测试地点、运营商、测试机器公网IP、使用的递归DNS、dig结果、curl响应头、mtr结果、服务端访问日志片段。

比如记录成这样：2026-06-01 10:20，北京电信，测试IP x.x.x.x，默认DNS查询 www.example.com 返回 1.1.1.1，curl响应 X-Node: cn-bj，mtr平均延迟 12ms，无明显丢包。2026-06-01 10:22，美国洛杉矶，测试IP y.y.y.y，默认DNS返回 2.2.2.2，curl响应 X-Node: us-la，mtr平均延迟 3ms。

这种记录在和DNS服务商、云厂商、CDN厂商沟通时很有用。只说“有用户访问慢”“海外解析不对”，对方很难查。给出递归DNS、来源IP、时间点、返回记录，才容易定位是线路库问题、ECS问题、缓存问题，还是业务入口问题。

常见异常现象怎么判断

国内用户解析到了海外IP

先看用户使用的递归DNS。如果是 8.8.8.8、1.1.1.1、DoH，权威DNS可能按海外递归出口返回海外线路。再看DNS服务商是否支持ECS，支持的话查ECS是否生效。不支持的话，这类公共DNS用户可能只能落到默认线路或递归出口所在地区。

海外用户解析到了国内IP

重点查默认线路和海外线路配置。还有一种情况是海外用户使用了国内公共DNS，或者企业网络出口在中国大陆。权威DNS看到的是国内递归出口，自然会返回国内记录。服务端日志里的用户真实IP和递归DNS来源IP要分开看。

dig结果对，浏览器访问不对

优先查浏览器DoH、系统DNS缓存、代理软件、VPN、App内置HTTPDNS。可以用 curl --resolve 强制指定IP测试业务是否正常，例如：curl --resolve www.example.com:443:2.2.2.2 https://www.example.com -I。这个命令可以绕开DNS，直接验证某个入口的HTTPS服务是否正常。

解析已经切了，但还有请求打到旧节点

看TTL、递归DNS缓存、客户端长连接。HTTP Keep-Alive、WebSocket、游戏长连接都不会因为DNS改了就自动断开。旧连接可能继续在旧节点上跑一段时间。切流期间不要急着下掉旧节点，至少保留一个观察窗口。

实际验证时可以按这个顺序跑

先在权威DNS控制台确认记录：国内线路、海外线路、默认线路分别是什么，TTL是多少，是否有CNAME嵌套。

然后用国内和海外递归DNS查：dig @223.5.5.5 域名 A +short，dig @119.29.29.29 域名 A +short，dig @8.8.8.8 域名 A +short，dig @1.1.1.1 域名 A +short。

再从真实地区机器查默认解析，不指定递归DNS。国内电信、联通、移动各测一次，海外美国、新加坡、欧洲各测一次。记录返回IP。

接着 curl 看响应头，确认请求落到哪个节点。能加 X-Node 就加，不能加就看Server、CDN节点头、日志里的upstream或机器名。

再跑 mtr 看链路。国内到国内入口、海外到海外入口，分别看延迟、丢包、绕路。DNS分区解析只是把门牌号发对，网络质量还要靠链路验证。

最后看服务端日志。按国家、ASN、运营商统计访问入口。如果中国大陆ASN大量出现在海外节点，或者海外ASN大量出现在国内节点，再反查这些请求使用的DNS环境和客户端特征。

容易忽略的CNAME链路

很多域名不是直接A记录，而是 CNAME 到 CDN、WAF、高防、负载均衡域名。这里要看每一层CNAME是否也做了分区解析。

比如 www.example.com 在你的DNS里国内和海外都CNAME到 cdn.example.net，而 cdn.example.net 自己再按地区返回不同边缘节点。这个时候你在第一层DNS看到的结果可能完全一样，但最终A记录不同。

验证时用 dig www.example.com CNAME 和 dig www.example.com A 一起看。如果CNAME相同，不代表没有分区；要继续看最终A记录和HTTP响应节点。如果CNAME不同，也要确认后面的A记录没有又汇到同一个入口。

IPv6也要单独测

现在不少网络环境会优先IPv6。你只测A记录，AAAA记录没测，可能会漏掉一半问题。

如果域名同时有A和AAAA，浏览器可能根据Happy Eyeballs策略选择IPv6或IPv4。国内IPv6解析到国内，IPv4解析到海外，或者反过来，都会造成用户体验不一致。

命令要分开跑：dig www.example.com A +short；dig www.example.com AAAA +short。curl也可以指定协议栈：curl -4 -I https://www.example.com；curl -6 -I https://www.example.com。

如果暂时没有把IPv6线路规划清楚，宁愿先不要随便发布AAAA记录。特别是海外节点IPv6路由质量参差不齐，部分地区看起来能通，实际延迟和丢包很难看。

切流前后要盯哪些数据

DNS分区解析验证生效后，真正切业务时还要看监控。比较关键的是各入口QPS、带宽、连接数、HTTP 4xx/5xx、TLS握手失败、源站CPU、内存、网卡、DDoS清洗状态。

比如预期海外流量从国内入口迁到美国入口，切完后美国节点带宽应该上升，国内入口对应海外访问日志应该下降。如果DNS看起来已经切了，但流量曲线没有变化，要查缓存、长连接、客户端DNS策略。

如果切完后海外入口 5xx 上升，可能不是DNS问题，而是海外节点回源失败、证书SNI不匹配、WAF规则不同、源站白名单没放行。DNS只是入口选择，后面的七层配置也要一致。

一个排障案例的判断过程

某个站点配置了中国大陆解析到国内高防，海外解析到美国节点。上线后，部分国内用户反馈访问慢，服务端日志显示这些用户请求落到了美国节点。

开始看用户IP，确实是中国大陆电信和移动。继续看DNS查询环境，发现这些用户集中使用浏览器DoH，解析结果来自 1.1.1.1。用本地系统DNS查询返回国内IP，用浏览器访问却命中美国节点。

后面在DNS服务商侧查，海外线路和默认线路都指向美国，DoH递归出口被识别成海外，导致返回美国节点。处理方式是调整默认线路，把默认入口改成更适合主要用户的国内高防，同时保留海外线路给明确识别的海外递归DNS。再通过服务端 X-Node 响应头和日志观察，国内误入美国节点的比例明显下降。

这个案例里，DNS配置表面没错，问题在“默认线路”和“递归DNS出口识别”。如果只在办公室电脑 dig 一次，根本看不到这个问题。

不要把DNS分区解析当成强制调度

DNS分区解析是尽量让用户拿到合适入口，但它不是强制路由。递归DNS、ECS、缓存、DoH、客户端策略都会影响结果。对强一致调度要求很高的业务，还要结合HTTPDNS、客户端调度、Anycast、GSLB、CDN边缘规则一起设计。

但大多数Web站点、游戏网关、下载分发、海外业务入口，用DNS分区解析已经能解决大量问题。关键是验证方法要覆盖DNS层、网络层、业务层。只要能从不同地区看到不同解析结果，链路质量符合预期，服务端日志也证明请求落到了对应节点，就可以认为这次分区解析已经在真实访问路径里生效。

继续观察24小时访问日志，特别是递归DNS分布、异常国家和ASN、默认线路命中比例、旧节点残留流量。如果某个地区持续命中错误入口，就拿该地区测试IP、递归DNS、dig结果、curl头和访问日志去查线路库或ECS，不要只改A记录碰运气。