DNS分地区解析配错了，会不会把海外流量全导进国内机房

会，而且线上见过。不是那种理论上存在、实际很难发生的情况，而是配置规则顺序、默认线路、Geo库识别、递归DNS缓存叠在一起后，海外用户真的可能被解析到国内IP。

但这里要拆开看：DNS分地区解析不是按“用户本人在哪”来判断，多数时候是按递归DNS的出口IP来判断。用户在新加坡，用了某个国内公共DNS，权威DNS看到的可能就是国内递归节点；用户在美国公司网络里，递归DNS走企业专线出口，也可能被识别成另一个区域。再加上TTL缓存，改错以后并不是立刻全网恢复。

分地区解析实际判断的不是浏览器，而是递归DNS

很多人第一次配GeoDNS时容易把它理解成：用户在美国，就返回美国机房IP；用户在国内，就返回国内机房IP。这个理解在产品界面上看起来没问题，但在DNS协议链路里，中间隔着递归DNS。

一次常见访问链路大概是这样：

用户浏览器 → 本地网络配置的DNS Resolver → 权威DNS → 返回A记录/AAAA记录 → 浏览器连接目标IP

权威DNS通常看到的是Resolver的IP，不一定是终端用户IP。支持EDNS Client Subnet，也就是ECS时，权威DNS可能拿到一段用户网段，用来做更准确的区域判断。但ECS不是所有Resolver都传，也不是所有权威DNS都完整使用。

实际使用中发现，海外用户“被解析到国内”的案例里，DNS本身不一定坏，更多是策略匹配结果和预期不一致。

哪些配置会把海外流量导进国内机房

默认线路写成了国内IP

这个最常见。很多DNS控制台里会有“默认”“境外”“其他地区”“未匹配线路”这类规则。如果只配置了“中国大陆 → 国内IP”，然后默认线路也填了国内IP，海外Resolver没命中任何专门线路时，就会拿到国内IP。

例如：

中国大陆：1.1.1.1（国内机房）

北美：2.2.2.2（美国机房）

欧洲：3.3.3.3（德国机房）

默认：1.1.1.1（国内机房）

这时候东南亚、中东、南美、部分非洲Resolver，只要没有单独线路，就可能全部回到国内机房。业务一看日志，会发现突然有大量海外IP访问国内源站，延迟从几十毫秒变成200ms、300ms甚至更高。

境外线路漏配或被更细规则覆盖

有些DNS平台的规则不是简单“地区大类优先”，而是有线路优先级。比如同时存在“默认”“境外”“亚洲”“韩国”“搜索引擎”“移动/联通/电信”等线路。某些平台匹配逻辑比较细，某些平台则按记录类型或线路颗粒度处理。

一个线上比较容易踩坑的写法是：

境外：海外IP

默认：国内IP

搜索引擎：国内IP

结果Googlebot、Bingbot之类的海外爬虫命中了搜索引擎线路，直接回国内。SEO团队看到海外抓取慢，运维这边看DNS记录又觉得“境外已经配了”，排查半天才发现是特殊线路覆盖了通用境外线路。

新加坡、日本、韩国被当成“亚洲”但亚洲线路指向国内

不少业务一开始只有国内站，后来加海外节点时会偷懒：大陆、亚洲、默认都指向国内，北美和欧洲才指向海外。这样看似覆盖了主要市场，实际对东南亚用户很伤。

例如游戏、跨境电商、API加速这类业务，新加坡访问国内华东机房，RTT可能在70ms到120ms；访问新加坡本地或香港节点，通常能压到10ms到40ms。DNS把新加坡打到国内，不一定直接打不开，但延迟、丢包、TLS握手耗时都会上去。

IPv6记录忘了分地区

现在很多站点同时有A和AAAA记录。A记录做了分地区，AAAA记录仍然全局指向国内IPv6，海外支持IPv6的用户可能优先走AAAA，结果还是连国内。

这个问题在移动网络、家庭宽带、海外运营商里都遇到过。浏览器有Happy Eyeballs机制，会在IPv4和IPv6之间做竞争，但如果IPv6可达且握手成功，业务日志里就会出现一批本应走海外节点的请求进入国内机房。

不是所有“海外进国内”都是DNS配错

这里补充一点，排查时不要只盯DNS控制台。海外流量进国内机房，可能是DNS返回错了，也可能是用户拿到了正确IP，但业务层又被重定向回国内。

常见情况包括：

HTTP 301/302根据Host或路径跳回国内域名。

APP内置了国内备用IP，DNS失败后直接连国内。

CDN回源配置写死国内源站，边缘节点虽然在海外，但源站压力仍然打到国内。

Anycast IP在某些地区BGP路由绕回国内。

负载均衡健康检查误判海外节点不可用，自动把权重切到国内。

所以判断是不是DNS问题，最直接的方法是从多个地区做dig，确认权威DNS到底返回了什么。不要只在办公室电脑上nslookup一下就下结论。

排查时看这几类数据，比看控制台截图可靠

从不同地区直接查权威DNS

普通dig默认会经过本地Resolver，结果受缓存影响。排查分地区解析时，最好指定权威DNS服务器，或者用多个海外探测点查询。

例如观察：

dig example.com A @权威DNS

dig example.com AAAA @权威DNS

dig example.com A @8.8.8.8

dig example.com A @1.1.1.1

dig example.com A @本地运营商DNS

多说一句，8.8.8.8和1.1.1.1不是“美国用户结果”的等价物。它们是公共递归DNS，节点全球Anycast，权威DNS看到的出口可能和你想象的不一样。如果权威DNS支持ECS，结果又会变一层。

看访问日志里的国家、ASN、目标机房

只看源IP国家不够，还要看请求最终进了哪个机房、哪个SLB、哪个源站。比较实用的日志字段包括：client_ip、X-Forwarded-For、server_id、region、upstream_addr、request_time、status、ASN。

例如某次故障里，业务反馈“海外用户慢”。日志一拉，国内机房在10分钟内多了约18%的非中国大陆IP访问，其中美国、德国、新加坡占比明显抬升。再对照DNS变更记录，发现同一时间把“默认线路”从海外Anycast改成了华东IP。

这类问题不一定会触发5xx告警，因为服务还活着，只是海外RTT变高。业务侧感知是页面白屏、接口超时、支付回调慢，监控侧可能只看到平均响应时间略升。

TTL会让错误持续一段时间

DNS配错后改回来，不代表全网立刻恢复。TTL如果是600秒，理论上缓存10分钟；TTL是3600秒，可能要等1小时。但实际还有Resolver最小缓存、客户端缓存、运营商缓存，恢复时间会比控制台显示更不可控。

线上变更前，通常会把TTL提前降到60秒或120秒，等旧缓存过期后再切。直接在TTL 3600的记录上改地区解析，错了以后回滚也会比较难受。

还有一种情况是负载均衡或CDN侧已经把连接建起来了，长连接业务不会因为DNS回滚马上断开。WebSocket、游戏长连接、MQTT、直播推流，都要单独看连接保持时间。

几个典型场景里的误配结果

场景A：国内官网加海外访问优化。中国大陆解析到宁波机房，北美解析到美国机房，欧洲解析到德国机房，默认忘了改，仍然指向宁波。结果东南亚和中东用户大量进国内，RTT从40ms到80ms变成180ms到260ms。

场景B：游戏业务做高防切换。被DDoS打的时候，把默认线路切到国内高防IP，但只考虑了国内玩家。海外玩家也拿到国内高防，清洗没问题，延迟直接爆。游戏类业务尤其敏感，80ms和180ms不是一个体验。

场景C：跨境电商上新海外节点。A记录按地区拆了，API子域名没拆，静态资源走海外CDN，接口仍回国内。页面打开看起来正常，提交订单和支付接口慢，用户以为是网站卡。

场景D：只配了A记录。海外IPv4走当地节点，IPv6走国内。部分海外网络IPv6优先，表现成同一地区有的用户快、有的用户慢。

国内机房接住海外流量以后，会发生什么

最直观的是延迟上升。以HTTP API为例，一次TLS握手加请求响应，RTT差距会被放大。海外到国内如果跨境链路拥塞，丢包还会引起TCP重传，用户看到的不是“慢一点”，而是偶发卡死。

大致感受可以按这个量级看：

中国大陆用户访问华东/华南机房：20ms到60ms常见。

韩国、日本访问中国大陆优化线路：40ms到90ms常见，线路差时更高。

新加坡访问中国大陆：70ms到150ms常见。

德国访问中国大陆：180ms到280ms常见。

美国西海岸访问中国大陆：150ms到230ms常见，美国东海岸更高。

如果链路走普通国际出口，高峰期抖动会比较明显。CN2、GIA、精品回国线路能改善，但不能把物理距离抹掉。

购买和选型时，DNS策略要跟机房布局一起看

只买国内服务器，然后用DNS分地区解析，并不能解决海外体验。DNS只能决定用户拿到哪个IP，它不会让一台国内机器变成海外节点。该放海外的业务还是要有海外资源，该接DDoS的入口也要有防护能力。

如果你也在找这种国内高防、海外节点、回国优化线路一起配的资源，可以看看129云。它的产品线里有国内高防、德国双ISP、韩国精品线路这类配置，适合按地区拆DNS后分别承接流量。需要确认线路和防护细节时，可以直接问客服，电话400-9177118。

国内主站或被攻击业务

国内业务如果主要面对大陆用户，又经常遇到DDoS，DNS可以把中国大陆线路解析到高防节点。比如129云的宁波高防-E型，16C、16G DDR4 ECC、100G U.2、上行40Mbps峰值、下行300Mbps、1个IPv4、100Gbps防御，适合做国内入口防护或中小型业务高防承载。

注意上行带宽。高防服务器的防御值和业务带宽是两件事，100Gbps防御不代表业务上行就是100Gbps。下载站、视频、补丁分发这类流量型业务，要单独算带宽。

欧洲、电商、TikTok相关业务

欧洲用户不要默认打国内。德国节点对欧洲访问体验更稳定，也方便承接亚马逊、电商、TikTok相关业务。德国双ISP-D型是16C、16G DDR4 ECC、150G SSD、100Mbps峰值、1个IPv4，双ISP线路更适合做欧洲侧业务入口。

DNS上可以把欧洲线路、德国线路、部分默认境外线路解析到德国节点。是否把默认也放德国，要看主要海外用户分布。如果海外用户以东南亚为主，默认放德国也不合适。

韩国、日本和回国访问

韩国节点适合东北亚访问，也常用于需要回国优化的业务。韩国-B型配置是2C、4G DDR4 ECC、50GB SSD、6Mbps、1个IPv4，带傲盾防火墙和精品线路，适合轻量服务、登录服、API中转、小型业务入口。

这里要看业务类型。6Mbps不适合大流量分发，但做低带宽接口、控制面、管理后台，线路质量比峰值带宽更关键。

DNS规则可以这样拆，别把默认线路当垃圾桶

比较稳的思路是：明确中国大陆、明确重点海外区域，再处理默认线路。默认线路不能随手填国内IP，它会接住所有没命中的地区和Resolver。

例如一个面向国内、欧洲、韩国的业务，可以这样设计：

中国大陆：宁波高防或国内BGP入口

韩国：韩国节点

日本：韩国节点或日本节点，看RTT实测

欧洲：德国节点

北美：北美节点；如果暂时没有，评估放德国还是国内，不要凭感觉

默认：选择海外访问最能接受的节点，或者使用全球CDN/Anycast入口

如果当前确实只有国内机房，海外又不是主要用户，默认指向国内可以接受，但要在变更记录里写清楚。后续一旦业务扩到海外，这条默认线路最容易被忘。

变更前后要测DNS，也要测连接

只测dig不够。DNS返回正确IP，只说明第一步没错。还要从海外机器上curl、mtr、tcping，看真实链路和应用响应。

常用检查动作：

dig确认A和AAAA返回值。

curl -v看是否发生301/302跳转。

mtr看跨境路由是否绕路、丢包。

tcping或hping3看端口连通和延迟。

检查服务端日志，确认请求进入预期机房。

检查CDN回源日志，确认边缘节点没有统一回国内源。

实际使用中发现，DNS变更最怕“看起来解析对了”。比如海外dig返回德国IP，但curl以后被302到www-cn.example.com；或者首页资源在德国，API域名还在国内。用户不会区分DNS、CDN、源站，只会说网站慢。

监控要按地区拆，不然这类问题很隐蔽

如果只有国内探测点，海外全进国内也可能不报警。国内探测正常，国内机房CPU正常，5xx正常，但海外用户已经开始超时。

至少要有几个外部探测点：新加坡、东京或首尔、法兰克福、洛杉矶。每个点同时探测DNS结果、TCP连接、HTTPS状态码、首包时间。业务关键的话，再加API级别探测，比如登录、下单、支付前置接口。

告警阈值不要只看可用性。海外访问国内经常不是完全不可用，而是P95、P99变差。比如P95从300ms涨到1800ms，状态码仍然是200，这种对用户已经很明显。

回滚时别只改DNS记录

如果已经把海外流量导进国内机房，回滚要同时看四个地方：DNS记录、TTL缓存、负载均衡权重、应用层跳转。

有一次处理类似问题，DNS已经把欧洲改回德国节点，但流量还有一部分进国内。继续查才发现APP网关有一条灰度规则：海外节点健康检查失败超过3次后，客户端会拿国内备用域名。DNS回滚了，客户端备用逻辑没恢复，所以还有残留流量。

长连接业务还要考虑踢连接或等待自然重连。如果玩家已经连到国内游戏服，DNS改回海外后，不会自动迁移连接。要不要断开重连，取决于业务能不能接受。

判断这次是不是“全导进国内”，看权威DNS和日志交叉结果

如果海外多个Resolver查询都返回国内IP，同时国内机房日志里海外ASN流量明显增加，基本可以确认DNS策略有问题。

如果DNS返回海外IP，但国内源站流量增加，重点查CDN回源、反向代理、HTTP跳转、APP备用地址。

如果只有某些国家异常，查Geo库、ECS、当地公共DNS出口、线路优先级。

如果只有IPv6用户异常，查AAAA记录和双栈优先级。

DNS分地区解析本身不复杂，复杂的是它和缓存、线路、应用跳转、CDN回源混在一起。上线前把默认线路、AAAA记录、海外探测、日志字段确认清楚，能少掉很多半夜排障时间。