DNS解析被污染，先别急着重启服务器

线上遇到“域名打不开”，很多人第一反应是服务器挂了、Nginx异常、证书过期。实际使用中发现，DNS解析被污染时，服务器往往是正常的，甚至你直接访问 IP 都没问题，只有访问域名才异常。

DNS污染的典型表现是：同一个域名，在不同网络下解析出不同 IP；解析结果里出现完全不属于自己的地址；国内某些地区打不开，海外正常；手机 4G/5G 能打开，办公室宽带打不开；或者用户反馈“有时候能开，有时候跳到奇怪页面”。

判断到底是运营商 DNS 问题，还是服务器侧问题，不能只看一个本地 nslookup 结果。DNS链路中间经过本地缓存、路由器、运营商递归 DNS、公共 DNS、权威 DNS，任何一层都可能给出错误结果。

先确认服务器本身有没有问题

排查顺序不要一上来就查 DNS。先绕开域名，直接打服务器 IP，看业务是否可用。

比如网站业务，可以在本地 hosts 临时绑定域名到真实服务器 IP，再访问域名。如果 hosts 绑定后页面正常，证书正常，接口正常，基本可以把 Web 服务、反向代理、源站端口这些问题先放一边。

常用方式：

Windows：修改 C:\Windows\System32\drivers\etc\hosts，加入：真实IP 域名

Linux/macOS：修改 /etc/hosts，加入：真实IP 域名

然后访问域名。如果绑定 hosts 后恢复正常，而不绑定就异常，问题大概率在 DNS 解析链路，不在服务器业务层。

这里补充一点，如果你的站点开启了 HTTPS，直接访问 IP 可能会证书不匹配，所以不能用“访问 IP 报证书错误”来判断服务器异常。更可靠的是 hosts 绑定后用域名访问。

看权威 DNS 返回什么

判断是不是服务器问题，关键要看权威 DNS 的解析结果。权威 DNS 返回的是域名配置源头的结果，运营商 DNS、公共 DNS 都是去它那里递归查询或者缓存结果。

可以用 dig 指定权威 DNS 查询。比如域名使用的是 Cloudflare、DNSPod、阿里云 DNS、Route 53，就找到对应 NS 记录，然后直接查：

dig NS example.com

dig @ns1.example-dns.com example.com A

如果权威 DNS 返回的 A 记录是你配置的真实 IP，TTL 也正常，说明域名配置本身没有错。

如果权威 DNS 返回的就是错误 IP，那就不是运营商污染，而是 DNS 配置层面出错。常见原因有：误改了 A 记录、CNAME 指向错了、解析线路配置覆盖、DNS 服务商控制台被误操作、自动化发布脚本写错。

同一域名，多地多 DNS 对比

DNS污染最明显的特征是“不同递归 DNS 返回不一致”。下面这种对比很有用，不要只测本机。

本地运营商 DNS 查询：

nslookup example.com

指定公共 DNS 查询：

nslookup example.com 8.8.8.8

nslookup example.com 1.1.1.1

nslookup example.com 223.5.5.5

nslookup example.com 119.29.29.29

dig example.com @8.8.8.8

dig example.com @1.1.1.1

dig example.com @223.5.5.5

实际排查中可以按这个思路看：

场景A：权威 DNS 正确，8.8.8.8 正确，1.1.1.1 正确，本地运营商 DNS 错误。这种基本就是本地运营商递归 DNS 缓存异常、劫持或污染。

场景B：权威 DNS 正确，但多个国内公共 DNS 都返回异常，海外 DNS 正常。这个更像是跨境 DNS 查询链路被干扰，或者国内递归节点拿到的结果异常。

场景C：权威 DNS 都错误，所有公共 DNS 逐渐跟着错误。这个不是污染，是源头配置问题。

场景D：DNS 解析正确，但访问仍然失败，ping IP 不通，traceroute 中断，telnet 端口不通。这个方向要转到网络路由、防火墙、安全组、源站服务、DDoS清洗策略。

用多地探测比本地命令更可信

本机测试只能代表当前网络。线上业务面向全国用户时，最好用多地 DNS 检测平台或自己准备几台不同线路机器做查询，比如北京联通、上海电信、广州移动、香港、美国、新加坡节点。

多地查询时重点看三类数据：

解析 IP：是否返回预期 IP。

TTL：是否异常偏大或不符合权威 DNS 设置。

响应来源：是否是本地运营商 DNS、公共 DNS，还是某个中间递归节点。

举个常见场景：权威 DNS 配置 A 记录为 203.0.113.10，TTL 300。多地检测结果里，海外和部分国内节点都返回 203.0.113.10，但某省电信返回 198.51.100.23，TTL 86400。这种 86400 很刺眼，通常不是正常解析配置，像是被递归 DNS 缓存了错误结果，或者中间层做了劫持。

还有一种情况，返回的是 127.0.0.1、0.0.0.0、内网地址、广告页 IP，这种基本不用怀疑服务器，优先看 DNS 劫持、域名拦截、运营商策略。

DNS污染和服务器故障的表现差异

下面按实战现象对比一下，排查时很省时间。

现象 | 更偏向 DNS污染 | 更偏向服务器问题

同一个域名不同网络解析到不同 IP | 是 | 否

hosts 绑定真实 IP 后访问正常 | 是 | 否

直接访问源站 IP 端口不通 | 不一定 | 是

权威 DNS 返回错误 IP | 否，偏配置问题 | 否，偏 DNS配置问题

本地运营商 DNS 错，8.8.8.8 正常 | 是 | 否

解析正确但 HTTP 502/504 | 否 | 是，查网关、源站、反代

解析正确但丢包高、跨境延迟飘 | 否 | 偏线路质量或网络拥塞

解析结果偶尔正常偶尔异常 | 是，常见于递归缓存混乱 | 也可能是多源站负载异常

别把 CDN、WAF、负载均衡误判成污染

很多业务前面挂了 CDN 或 WAF，本来就会根据地区、运营商、负载情况返回不同 IP。看到不同地区解析结果不一样，不代表一定被污染。

判断方式很简单：看这些 IP 是否属于你的 CDN/WAF 服务商网段。如果是 Cloudflare、Akamai、CloudFront、阿里云 CDN、腾讯云 EdgeOne、火山引擎 CDN 等，返回多个边缘节点是正常行为。

但如果你没有开 CDN，权威 DNS 只配置了一个 A 记录，某些运营商却解析出陌生 IP，那就不正常。

多说一句，使用 CDN 时不要只盯 A 记录，有些域名走 CNAME。需要一路追踪：

dig example.com CNAME

dig cdn-target.example.net A

如果 CNAME 链路中某一层被污染，最终 A 记录也会跟着错。

TTL能帮忙判断污染发生在哪一层

TTL 不一定能直接定责，但能提供线索。

如果权威 DNS 设置 TTL 300，本地查询一直显示 299、280、260 这种递减，说明递归 DNS 正常缓存。

如果某个运营商 DNS 返回错误 IP，TTL 还特别大，比如 86400、172800，甚至每次查询都重新回到 86400，这种很可疑。正常递归缓存的 TTL 应该递减，不应该一直刷新成固定大值。

如果权威 DNS 修改记录后，公共 DNS 过了 TTL 仍不更新，可能是递归 DNS 缓存滞留。遇到这种情况，业务临时恢复可以通过切换域名、启用备用解析、让用户改公共 DNS，但根因还是要定位递归节点。

运营商问题怎么进一步确认

如果怀疑是运营商 DNS，尽量收集证据，不要只说“打不开”。运营商侧排障一般需要明确时间、地区、宽带类型、DNS服务器、解析结果。

建议记录这些信息：

用户所在地区：例如陕西西安电信、广东深圳移动、江苏南京联通。

用户 DNS：通过 ipconfig /all、nmcli dev show、路由器 WAN 信息查看。

异常解析结果：nslookup 域名 返回的 IP。

对比结果：同一网络下查询 8.8.8.8、1.1.1.1、223.5.5.5 的结果。

权威 DNS 结果：dig @权威NS 域名 A。

访问结果：hosts 绑定后是否正常。

这些信息凑齐后，基本能把锅从服务器侧摘出来。实际沟通时，不要只报“DNS污染”，运营商一线客服未必能处理，最好描述为“指定地区递归 DNS 返回非权威解析结果”。

服务器侧问题通常长什么样

如果 DNS 解析完全正确，但业务还是异常，那就回到服务器侧。

常见服务器侧问题包括：安全组没放行 80/443，Nginx upstream 全部 down，源站负载过高，磁盘满，证书链错误，IPv6 解析到了未监听地址，防火墙封了特定地区 IP，WAF 规则误拦截，DDoS清洗后回源异常。

这里特别容易漏的是 IPv6。很多域名同时有 A 和 AAAA 记录，部分用户网络优先走 IPv6。如果服务器 IPv6 没配好，用户就会觉得“域名打不开”，但你在只测 IPv4 的环境里完全正常。

排查时分别查：

dig example.com A

dig example.com AAAA

curl -4 -I https://example.com

curl -6 -I https://example.com

如果 IPv4 正常、IPv6 异常，要么修 IPv6 服务，要么暂时移除 AAAA 记录。

跨境业务更容易把线路问题看成 DNS污染

香港、美国、新加坡、日本这些海外节点，如果面向国内用户，很多异常不是 DNS，而是线路质量问题。DNS 返回没错，但访问慢、丢包、TCP握手失败、晚高峰抖动，这类问题更像线路拥塞或路由绕路。

判断方式是解析和连通性分开看：

DNS阶段：dig 查询结果是否正确。

网络阶段：ping、mtr、traceroute 看丢包和跳点。

应用阶段：curl -I 看 HTTP 状态码和响应时间。

如果 DNS 正确，mtr 显示跨境段丢包明显，或者电信走了普通国际出口绕远，那就不是污染。这个时候选线路比改 DNS 更关键，比如 CN2、BGP精品、GIA 这类线路会明显影响体验。

如果业务面向国内用户，又需要香港节点、大带宽、低延迟，可以看看129云的香港大宽带-D型。8C 8G DDR4 ECC、300Mbps峰值、70G SSD、1TB流量适合中小业务入口；如果并发更高，可以看 16C 16G、500Mbps峰值、220G SSD、2TB流量的版本。选这种机器时重点看线路质量和带宽峰值，不要只看 CPU 核数。

高防场景下还要看清洗和解析联动

有些业务开了高防，DNS解析不是直接指向源站，而是指向高防 IP 或 CNAME。用户访问异常时，要分清楚是 DNS 被污染，还是高防调度异常。

高防业务常见链路是：用户解析域名 → 返回高防入口 IP → 高防清洗 → 回源服务器。

如果解析出来的高防 IP 是正确的，但访问失败，重点查高防入口、清洗策略、回源端口、源站白名单。

如果解析出来的不是高防 IP，也不是你的 CNAME 目标，那才考虑 DNS污染或解析配置问题。

比如西北地区企业业务，比较在意本地电信访问和抗攻击能力，可以关注129云的西安电信-D型，8C 8G DDR4 ECC、60G SSD、20Mbps上行、50Gbps单机防御、电信单线。适合电信用户集中的业务、政企系统、区域性平台。遇到解析或线路选型不确定，也可以直接打客服热线 400-9177118 让技术确认节点和线路情况。

本地DNS缓存也会制造假象

有时候不是运营商，也不是服务器，是你自己的电脑或路由器缓存了旧解析。

Windows 清缓存：

ipconfig /flushdns

macOS：

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux 如果用了 systemd-resolved：

sudo resolvectl flush-caches

浏览器也有 DNS 缓存，Chrome 可以看 chrome://net-internals/#dns，部分新版页面位置会变化，但浏览器缓存确实存在。企业办公网络里，出口网关、透明代理、内网 DNS 服务器也可能缓存旧记录。

所以看到本机异常时，换手机热点测一下很有必要。手机 5G 正常、公司宽带异常，基本能把范围缩到公司网络、路由器、运营商 DNS。

遇到污染时的临时处理办法

临时恢复访问，常见办法有几类。

让用户改公共 DNS，比如 223.5.5.5、119.29.29.29、8.8.8.8、1.1.1.1。这个对个人用户有效，对大规模业务不现实。

切换备用域名。业务提前准备多个域名，主域名异常时通过公告、App配置、客户端热更新切换。游戏、支付、API类业务经常这么做。

接入 CDN 或高防 CNAME，让解析调度交给更成熟的平台。前提是业务适合走代理，且源站回源配置正确。

更换 DNS 服务商。有些 DNS 服务商在国内递归命中和线路调度上更稳，支持按运营商、地域、线路解析，也支持健康检查和故障切换。

降低 TTL。平时 TTL 不要设太大，300 到 600 秒比较常见。TTL 过大时，一旦错误记录扩散，恢复时间会被拉长。

一个排查案例：用户说域名被劫持

某业务反馈广东电信用户访问官网跳到陌生页面，其他地区正常。服务器监控正常，Nginx日志里看不到这些广东用户请求。

当时排查过程是：

在广东电信宽带下 nslookup 域名，返回 198.51.100.88，不是业务 IP。

指定 223.5.5.5 查询，返回正确高防 CNAME。

指定 8.8.8.8 查询，返回正确 CNAME。

查权威 DNS，CNAME 配置正常，TTL 300。

hosts 绑定正确高防 IP 后访问正常，HTTPS证书正常。

这就很清楚，服务器没收到请求，因为请求根本没去服务器或高防入口。问题在广东电信递归 DNS 返回了异常结果。

后续处理是：收集异常 DNS IP、解析结果截图、dig输出、权威 DNS 输出，提交运营商处理；同时业务侧临时启用备用域名，并在客户端配置里下发备用 API 域名。主域名大概几个小时后恢复正常。

另一个案例：看起来像污染，其实是AAAA记录坑了

还有一次用户反馈海外正常、国内部分网络打不开。多地 DNS 检测 A 记录都正确，结果一开始方向被带偏了。

后来抓包发现部分移动网络优先访问 AAAA 记录，域名解析到了 IPv6 地址，但服务器没有监听 IPv6 的 443 端口。浏览器等待 IPv6 连接超时后才回退 IPv4，用户体验就是页面一直转圈。

处理很简单：临时删除 AAAA 记录，等待 TTL 过期；后面再把 IPv6监听、防火墙、安全组、证书全部补齐。

这种不叫 DNS污染。DNS 返回的是你自己配置的 IPv6，只是服务器侧没准备好。

排查时最怕只拿一个结果下结论

DNS问题一定要交叉验证。至少要有权威 DNS、本地运营商 DNS、公共 DNS、多地节点、hosts绑定访问这几类结果。

如果权威 DNS 正确，本地运营商 DNS 错，hosts绑定正常，服务器日志没有异常请求，那就是典型运营商递归解析问题。

如果权威 DNS 错，所有地方逐渐错，那就是解析配置问题。

如果 DNS 全部正确，但 IP连通性差、端口不通、HTTP状态异常，那就回到线路、服务器、防火墙、应用层继续查。

线上处理时，把“解析是否正确”和“访问是否正常”拆开看，能少走很多弯路。