DNS分地区解析配错，海外用户会不会全部回源到国内节点

会，而且线上真见过。更准确地说，不是“海外用户”这个标签本身被DNS识别错了，而是权威DNS根据递归DNS、EDNS Client Subnet、默认线路、CNAME链路等信息做判断时，把一批海外请求导到了国内A记录或国内CDN源站。结果表现出来就是：海外访问延迟突然从几十毫秒变成两三百毫秒，部分地区还会出现TLS握手慢、图片加载断断续续、API超时。

这个问题容易被误判成“海外线路差”“服务器带宽不够”“CDN节点抽风”。实际排查时，DNS解析方向要放在很前面看，因为用户还没建立TCP连接之前，路就已经被DNS指错了。

真正出问题的不是用户在哪，而是DNS认为用户在哪

很多人配置分地区解析时，会写成：中国大陆解析到国内节点，海外解析到美国、日本、新加坡节点。看起来很直接，但DNS不是直接问用户手机GPS在哪里，它通常看到的是递归DNS的出口IP。

比如一个美国用户使用了国内公共DNS，或者某些企业VPN、代理网络的递归DNS出口在中国大陆，权威DNS可能就会把这个请求判断成“中国大陆线路”。反过来也一样，国内用户用了海外递归DNS，也可能被分到海外节点。

这里补充一点，EDNS Client Subnet，也就是常说的ECS，可以把用户网段的一部分带给权威DNS，提升地理判断准确度。但不是所有递归DNS都支持ECS，也不是所有权威DNS都正确处理ECS。Cloudflare、Google DNS、部分运营商Local DNS的行为都不完全一样，所以不能假设“用户在哪，DNS一定知道”。

一个常见现场：海外默认线路没配，全部掉到国内默认

实际使用中发现，最容易出事的是“默认线路”。很多DNS平台会有中国大陆、境外、运营商、搜索引擎、默认这些线路。配置时只加了电信、联通、移动到国内IP，又加了几个指定海外区域，但忘了把默认线路指到海外Anycast或海外CDN。

结果是什么？没命中任何规则的请求全部走默认，而默认刚好是国内源站。

场景示例：域名 api.example.com，国内源站 1.1.1.1，香港节点 2.2.2.2，美国节点 3.3.3.3。

配置看起来是：中国电信 -> 1.1.1.1，中国联通 -> 1.1.1.1，中国移动 -> 1.1.1.1，北美 -> 3.3.3.3，日本 -> 2.2.2.2，默认 -> 1.1.1.1。

如果欧洲、南美、中东、非洲、部分东南亚没有单独匹配到，就会全部落到默认的 1.1.1.1。表面上不是“海外全部回国内”，但从业务视角看，大量海外区域确实都被打回国内了。

哪些配置会让海外流量回到国内

默认线路指向国内

这是最直观的。很多DNS平台的“默认”不是兜底到最优节点，而是兜底到你填的那条记录。只要海外区域规则不完整、识别失败、递归DNS不支持ECS，都会命中默认线路。

如果业务本来就是全球访问，默认线路一般不建议放国内单点。更稳的做法是默认给海外BGP节点、香港优化线路、美国GIA/CN2优化节点，或者直接给全球CDN的CNAME。

境外线路被写成了国内IP

这个错误很朴素，但发生概率不低。比如复制A记录时，把“境外”线路也复制成了国内源站IP。配置界面看着有多条线路，实际解析结果全是同一个国内IP。

排查时不要只看控制台配置，要从不同地区dig。至少用美国、日本、新加坡、德国、香港这些探测点分别查一遍。

例如：

美国探测：api.example.com -> 203.0.113.10 国内IP，RTT 220ms

日本探测：api.example.com -> 203.0.113.10 国内IP，RTT 95ms

德国探测：api.example.com -> 203.0.113.10 国内IP，RTT 260ms

香港探测：api.example.com -> 198.51.100.20 香港IP，RTT 12ms

这种结果就很明显，美国、日本、德国都没被分到本地或近源节点。

CNAME链路中间跳回国内

有些业务不是直接A记录，而是：业务域名 CNAME 到调度域名，调度域名再CNAME到CDN或源站。第一层DNS看着没问题，第二层调度却把海外请求指到了国内。

例如：www.example.com -> www.example.com.cdn.example.net -> origin-cn.example.net -> 国内IP。

用户侧只看到访问慢，DNS控制台看第一层也正常，但完整dig +trace或者逐层dig才发现中间CNAME已经变成国内线路。

多说一句，CDN回源配置也要分开看。DNS把海外用户解析到海外CDN节点，不代表CDN一定回海外源。如果CDN源站只填了国内源站，海外边缘节点缓存未命中时仍然要跨境回源，首包时间一样会难看。

智能解析区域粒度不够

有些DNS服务商的海外线路只有“境外”一个大类，有些能细到亚洲、北美、欧洲，有些还能按国家和运营商拆。粒度不够时，调度结果会比较粗。

比如新加坡用户和美国用户都命中“境外”，但境外只配置了美国西海岸IP。新加坡访问美国西海岸，RTT可能在170ms到220ms之间；如果有日本或香港节点，通常能压到30ms到70ms。

这类不是严格意义上的“回源国内”，但用户体验同样会差，尤其是游戏、实时语音、行情推送、WebSocket长连接。

用数据看一下错误解析的影响

下面是一次比较典型的压测观察，业务是API接口，源站在华东，海外有美国洛杉矶和日本东京节点。接口本身处理时间约20ms，差异主要来自网络。

场景：日本用户 -> 日本节点，DNS正确，平均RTT 35ms，TLS握手约60ms，接口P95约110ms。

场景：日本用户 -> 国内华东节点，DNS错误，平均RTT 90ms到130ms，TLS握手约180ms，接口P95约320ms。

场景：美国西海岸用户 -> 洛杉矶节点，DNS正确，平均RTT 10ms到25ms，TLS握手约45ms，接口P95约90ms。

场景：美国西海岸用户 -> 国内华东节点，DNS错误，平均RTT 180ms到230ms，TLS握手约350ms，接口P95可能到600ms以上。

如果接口还依赖多次请求，比如登录页要拉配置、鉴权、用户信息、活动资源，单次慢300ms，页面整体就可能慢1秒到3秒。用户体感不是“有点慢”，而是“打不开”。

怎么判断是不是DNS分地区解析配错

不要只在本地dig

本地dig只能说明你当前递归DNS拿到什么结果，不能代表海外用户。排查这类问题要多点探测，最好覆盖用户真实分布区域。

常用方式有三类：全球探测平台、云服务器上直接dig、让海外用户提供nslookup结果。云服务器方式最可靠，因为可以顺手测ping、mtr、curl耗时。

命令可以这样看：

dig api.example.com @8.8.8.8

dig api.example.com @1.1.1.1

dig api.example.com @当地运营商DNS

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://api.example.com/health

如果DNS解析出来的IP已经是国内节点，后面curl再慢就不用先怀疑应用。

看权威DNS日志比猜更快

支持查询日志的DNS平台，可以直接看请求来源、命中线路、返回记录。重点看三项：递归DNS IP属于哪里，是否携带ECS，命中了哪条线路。

比如美国用户反馈慢，日志里看到递归DNS是某国内运营商IP，命中“中国移动”线路，返回国内A记录。这个时候就不是美国用户网络差，而是DNS判断入口已经偏了。

还有一种情况，日志显示命中“默认”，返回国内A记录。那就回到默认线路兜底的问题。

TTL会放大错误时间

DNS配置改错后，TTL越长，影响越久。比如TTL是600秒，理论上十分钟左右递归DNS会刷新；如果TTL是3600秒，错误解析可能持续一小时甚至更久。部分递归DNS还会有自己的缓存策略，实际表现不一定严格按你填的TTL走。

线上调整DNS前，建议先把TTL降到60秒或120秒，等缓存逐步过期后再改线路。改完观察稳定，再把TTL调回300秒或600秒。高频切换业务不要把TTL设得太长。

海外业务的DNS线路应该怎么放

默认线路不要随便给国内单点

如果业务有海外用户，默认线路建议给一个跨区域可接受的节点。比如香港BGP、美国优化线路、日本软银直连，或者全球CDN。默认线路的意义不是“国内默认”，而是“无法识别时的兜底”。

常见配置可以这样拆：

中国大陆 -> 国内CDN或国内源站

中国香港/澳门/台湾 -> 香港节点或华南优化节点

日本/韩国 -> 日本节点

东南亚 -> 新加坡、日本或香港节点，按实测RTT选

北美 -> 美国西海岸或美国中部节点

欧洲 -> 欧洲节点；没有欧洲节点时，美国东海岸通常比美国西海岸更合适

默认 -> 海外BGP/CDN，不建议直接指向国内源站

源站和CDN要一起看

只改DNS不看源站，会留下另一个坑。海外用户解析到了海外CDN，CDN回源却走国内，缓存命中率低的时候还是慢。静态资源还好，缓存上来以后能缓解；动态API、WebSocket、游戏服入口就不适合完全依赖跨境回源。

如果是游戏、跨境电商、TikTok相关业务、海外API服务，源站最好靠近用户区域。比如北美用户占比高，就放美国节点；日本用户多，就放日本节点。需要三网回国优化时再考虑CN2、GIA、精品网线路。

如果你也在找这种海外云服务器、G口大带宽、高防或游戏业务节点，可以看看129云。比如美国精品网-C型适合需要美国三网精品线路的业务，4C 8G、100G SSD、100Mbps峰值，带基础防御；日本活动机型走软银直连，适合日本和东亚访问场景；美国双ISP-D型更偏TikTok、亚马逊、电商和游戏场景，16C 16G、100Mbps峰值。需要按地区和线路确认，也可以直接打客服热线400-9177118问节点和线路情况。

分地区解析和负载均衡不要混着想

DNS分地区解析解决的是“用户应该去哪个区域”，不是精确的实时负载均衡。它对节点故障、链路抖动、DDoS清洗切换的反应速度，取决于健康检查、TTL、递归DNS缓存和权威DNS调度能力。

比如美国节点挂了，DNS健康检查把美国线路切到日本节点，但一部分递归DNS还缓存着美国IP，用户短时间内仍然访问失败。反过来，如果健康检查误判，把海外线路切到国内备用节点，也会出现“海外回国内”的现象。

高可用场景下，DNS可以做大方向调度，节点内部再用SLB、Nginx、Anycast、BGP路由或业务层发现机制。单靠DNS做秒级容灾，期望不要太高。

线上改DNS时容易忽略的细节

AAAA记录也要同步检查

现在不少海外网络IPv6质量不错，浏览器也可能优先尝试IPv6。如果A记录分地区正常，AAAA记录却只配置了国内IPv6，海外用户仍然可能走到国内。排查时A和AAAA都要dig。

有些业务为了省事只测IPv4，结果海外移动网络访问异常，最后发现是AAAA返回了错误节点。移动端这种问题更明显。

备用记录别写成长期主用

DNS控制台里经常会有“备用”“暂停”“权重”之类配置。做故障演练时临时把海外权重切到国内，演练结束忘了恢复，就会形成隐性故障。

权重配置也要注意。比如海外线路里美国节点权重80，国内节点权重20，本意是留一点备用流量做探测，但真实用户里就会有20%被分到国内。对于延迟敏感业务，这20%就是投诉来源。

监控要按解析结果分组

只监控域名总可用性不够。应该把“不同地区解析到哪个IP”和“访问耗时”一起采集。比如每分钟从东京、洛杉矶、新加坡、法兰克福分别dig一次，再curl一次健康检查接口。

报警规则可以直接写：日本探测点解析结果不是日本IP或香港IP就报警；美国探测点解析结果不是美国IP就报警；海外探测点解析到国内IP连续3次就报警。这样比等用户反馈快很多。

遇到海外全部变慢时的排查顺序

先查DNS解析结果。不同地区dig域名，看A、AAAA、CNAME链路是否指向国内。再查curl分段耗时，确认慢在DNS、TCP、TLS、TTFB还是下载阶段。接着跑mtr，看链路是不是跨境绕路。最后再看应用日志、服务器负载、CDN命中率。

如果海外探测点解析到国内IP，优先修DNS。把海外线路和默认线路改到正确节点，降低TTL，等待缓存刷新。必要时换一个临时域名验证新配置，不要在生产域名上反复试。

如果DNS正确但TTFB很高，再看CDN是否跨境回源、源站是否只在国内、数据库是否跨区域调用。很多海外业务慢不是单一问题，DNS只是最前面的入口。

配置检查可以按这个格式过一遍

域名：www.example.com

中国大陆线路：返回国内CDN或国内源站，确认A和AAAA都正确。

香港线路：返回香港节点，RTT目标通常10ms到40ms，视用户运营商而定。

日本线路：返回日本节点，东京本地RTT通常5ms到20ms，国内访问日本软银线路一般也比较稳定。

北美线路：返回美国节点，西海岸用户访问洛杉矶通常10ms到40ms，美国中部到西海岸大约40ms到70ms。

欧洲线路：有欧洲节点就返回欧洲；没有欧洲节点时，测试美国东海岸、美国西海岸、香港三者的实际RTT，不要拍脑袋选。

默认线路：返回海外可接受节点或CDN，不要直接返回国内单点。

CNAME全链路：每一跳都查，不能只看第一跳。

TTL：变更期60秒到120秒，稳定后300秒到600秒，按业务容忍度调整。

监控：按地区记录解析IP、RTT、TLS耗时、TTFB，海外解析到国内IP直接告警。

有些“回源国内”其实是业务架构造成的

DNS解析正确，海外用户也到了海外节点，但海外节点只是反向代理，所有动态请求还要回国内应用集群。这个在跨境电商、出海SaaS、游戏登录服里很常见。

如果只是官网、图片、下载包，CDN缓存能解决大部分问题。动态请求不一样，用户每次操作都要走跨境链路。美国到国内一次RTT 180ms到230ms，数据库再查几次，接口P95很容易上去。

这时候要把业务拆开看：静态资源放CDN，登录和API按区域部署，账号体系和订单数据做异步同步或就近读写，强一致请求再回中心区域。DNS只负责把用户送到近的入口，后面的链路不能继续绕回国内。

DNS分地区解析配错后的处理方式

已经发生海外用户被导回国内，处理动作不要太复杂。先把海外线路和默认线路改到海外节点，确认A、AAAA、CNAME都一致。然后用多个海外探测点验证解析结果。再观察CDN命中率、源站带宽、接口P95。

如果TTL较长，短时间内还有用户访问旧IP，可以临时保留国内节点服务，不要立刻下线。对于API类业务，可以在国内节点加一层302或反向代理临时转发到海外节点，但这只是止血，不能长期依赖。

DDoS场景下还要小心高防切换。有些高防IP在国内，有些在海外。如果海外线路被切到国内高防，攻击可能扛住了，用户延迟也上去了。业务需要海外访问时，尽量选海外高防或就近清洗节点，DNS线路里标清楚用途，别把“防护备用”和“全球默认”混在一起。

最容易踩坑的配置长这样

国内三网都配得很细：电信、联通、移动、教育网、搜索引擎，每条都指向国内CDN。

海外只配了“境外”一条，指向美国节点。

默认线路还保留着最早的国内源站IP。

AAAA记录没有分地区，全部返回国内IPv6。

CDN源站只填国内源站，没有海外源。

健康检查失败时，海外线路自动切到默认线路，而默认线路是国内。

这套配置平时看着没问题，一旦某个海外区域没命中、递归DNS不带ECS、美国节点健康检查抖动，海外用户就会被批量打回国内。排查时按解析结果、CNAME链路、默认线路、AAAA、健康检查切换顺序看，基本都能定位到具体是哪一层把流量带偏了。