DNS污染怎么排查？从现象到结论的4步诊断流程
简答：如果域名打不开、部分网络异常或解析到陌生IP，不要先把不同DNS返回不同IP直接认定为污染。最快做法是：先清理并检查本机配置，再用多个DNS查询A和AAAA记录，随后用dig +trace或权威DNS核对，最后用curl和实际网络连接验证；只有在同一时间、同一记录类型下出现稳定且明显偏离权威结果的响应，才更接近DNS层异常。
定义：DNS污染通常指解析请求在到达或返回权威结果前被错误响应影响，使用户拿到与正常DNS记录不一致的结果；它与本机缓存、hosts修改、DNS劫持、CDN调度和服务器故障并不等同。
先看结论：DNS污染排查的4步速查卡
遇到“网站打不开”“部分网络能打开、部分网络打不开”“解析到陌生IP”时，按下面顺序做，不要一开始就改路由器或反复更换DNS。每一步都要记录查询时间、网络环境、DNS服务器、记录类型和返回结果。
| 步骤 | 检查内容 | 可执行操作 | 判断重点 |
|---|---|---|---|
| 1 | 本机与局域网 | 检查hosts、系统DNS、代理、路由器DNS并清理本地缓存 | 只有一台设备异常，优先怀疑本机或局域网 |
| 2 | 多DNS对比 | 分别查询A、AAAA、CNAME、TTL和响应状态 | 不同IP不一定是污染，可能是CDN或GeoDNS |
| 3 | 权威链路核对 | 使用dig +trace或查询权威DNS | 确认结果是否与权威记录一致 |
| 4 | 实际连接验证 | 用curl、浏览器和IPv4/IPv6分别测试 | 区分DNS层问题与TCP、TLS、HTTP或服务器故障 |
Windows用户可以先执行ipconfig /all查看当前DNS、网关和网卡配置，再执行ipconfig /flushdns清理DNS客户端缓存。微软文档说明，/flushdns用于清空并重置DNS客户端解析缓存，也可丢弃缓存中的失败记录；Microsoft的ipconfig文档可核对参数含义。
第一步：先排除hosts、本地缓存和错误DNS配置
DNS污染排查的第一原则是先确认“查询请求到底发给了谁”。如果hosts文件直接指定了域名，浏览器可能不会按正常DNS流程查询；如果系统、浏览器、代理客户端、路由器或安全软件分别接管DNS，也可能出现命令行和浏览器结果不一致。
- Windows：执行
ipconfig /all，记录DNS服务器和默认网关；检查hosts文件中是否存在目标域名的固定IP；执行ipconfig /flushdns后重新查询。Windows的nslookup可以指定查询服务器，例如nslookup example.com 1.1.1.1，也可以查询AAAA记录：nslookup -type=AAAA example.com 1.1.1.1。相关语法和错误提示可参考Microsoft的nslookup文档。 - macOS：在“系统设置—网络—当前网络—详细信息—DNS”中查看或临时调整DNS服务器。Apple说明该位置用于添加、删除DNS服务器和搜索域；操作前先记下原配置，测试结束后恢复。具体路径见Apple的Mac DNS设置文档。
- Linux：先查看
/etc/resolv.conf以及当前网络管理器配置；若系统使用systemd-resolved，可执行resolvectl status查看各接口的DNS设置，再用resolvectl query example.com查询。systemd文档说明，resolvectl可以查询IPv4、IPv6和其他DNS记录，并显示查询所使用的协议、接口以及DNSSEC认证状态，详见freedesktop.org的resolvectl文档。
如果清理缓存后只有当前设备恢复，通常更像本地缓存、hosts或软件配置问题；如果同一Wi-Fi下多台设备同时异常，再继续检查路由器下发的DNS和网络出口。
第二步：用多个DNS对比，但不要把不同IP直接当成污染
建议至少比较当前网络默认DNS和两个公开递归DNS。查询时不要只看一个A记录，还要分别查看AAAA、CNAME、TTL、响应状态以及是否返回NXDOMAIN、SERVFAIL或超时。Windows可使用nslookup example.com 1.1.1.1和nslookup example.com 8.8.8.8；macOS、Linux若安装了dig，可使用dig example.com A、dig example.com AAAA、dig example.com CNAME，并指定服务器：dig @1.1.1.1 example.com A。
| 现象 | 可能原因 | 下一步 |
|---|---|---|
| 多个DNS返回不同IPv4，但都指向同一CDN或同一服务商网段 | CDN、GeoDNS、负载均衡或缓存时间不同 | 继续核对CNAME、TTL、地区和时间，不直接判定污染 |
| 只有本地DNS返回陌生IP，其他DNS和权威DNS一致 | 本地DNS、路由器或网络出口异常 | 更换网络复测，并检查路由器DNS与代理设置 |
| A记录正常但AAAA记录异常 | IPv6路径、AAAA配置或IPv6解析异常 | 分别进行IPv4和IPv6连接测试 |
| 所有递归DNS都返回NXDOMAIN | 域名可能不存在、记录已删除或查询名称有误 | 核对完整域名、CNAME和权威DNS状态 |
| 查询超时或SERVFAIL | 递归服务器、网络链路、DNSSEC或权威服务器异常 | 换网络并查询权威链路，不能仅凭超时认定污染 |
Google Public DNS文档明确区分了递归解析服务与权威DNS托管服务，也提醒不同解析器可能因为缓存、配置和DNSSEC处理方式不同而返回不同结果。更换DNS只能作为对比手段，不应被当作已经证明污染的结论；可参考Google Public DNS使用说明和Google Public DNS FAQ。
第三步：用权威DNS和dig +trace核对“真实记录”
如果多个递归DNS结果差异明显，下一步要绕开单一递归缓存，沿DNS委派链查询。macOS、Linux或已安装dig的环境可执行dig +trace example.com A，再分别执行dig +trace example.com AAAA和dig +trace example.com CNAME。重点观察根服务器、顶级域名服务器、权威DNS服务器之间的委派是否连贯，以及最终A、AAAA、CNAME和TTL是否与递归DNS结果一致。
如果你已经知道域名的权威DNS服务器，还可以直接指定查询，例如dig @ns1.example-dns.com example.com A。这里的ns1.example-dns.com只是占位符，应替换为实际NS记录中的服务器，不要照抄。权威结果也可能因CDN、GeoDNS、EDNS客户端子网或查询来源而变化，所以应在相同时间、相同记录类型下做比较。
DNS污染更值得怀疑的组合通常是：同一网络、同一时间、同一域名和记录类型下，本地或某个网络的递归结果持续返回异常记录，而权威DNS和其他网络的结果稳定一致；同时实际访问也连接到该异常地址。单独出现“IP不同”“TTL不同”或“一次查询超时”，证据都不足。
第四步：用curl和IPv4/IPv6测试确认是不是DNS层问题
DNS查询正常，不代表网站一定能打开；反过来，网页打不开也不一定是DNS污染。需要把解析、TCP、TLS和HTTP分开验证。先查看域名解析出的地址，再测试对应协议：
- 使用
curl -I https://example.com观察是否能建立HTTPS连接以及返回HTTP状态。 - 使用
curl -4 -I https://example.com只走IPv4，使用curl -6 -I https://example.com只走IPv6。 - 若已获得一个候选IP，可在受控测试中使用
curl --resolve example.com:443:203.0.113.10 https://example.com/ -I，其中IP必须替换为你记录到的地址；该方式用于比较指定IP对应的TLS和HTTP响应，不能证明该IP就是正确服务器。
如果IPv4正常、IPv6失败，优先检查AAAA记录、IPv6路由和服务器IPv6监听；如果DNS结果一致但TCP连接超时，问题更可能在网络链路、防火墙或服务端；如果TCP和TLS成功但HTTP返回错误，则应转向应用、CDN或源站排查。Google的DNS排障文档也提醒，ping和traceroute主要用于确认可达性或定位延迟位置，不能直接代表DNS解析速度或证明DNS污染，可参考Google Public DNS排障文档。
DNS污染、DNS劫持、缓存和CDN差异怎么区分
| 类型 | 典型表现 | 验证方式 | 处理方向 |
|---|---|---|---|
| 本地缓存未刷新 | 同一设备持续拿旧结果，清缓存或等待后恢复 | 清理缓存后与其他设备对比 | 恢复系统、浏览器或客户端的正常DNS配置 |
| hosts或软件改写 | 命令行、浏览器或特定客户端结果不一致 | 检查hosts、代理、VPN或安全软件 | 撤销未知固定记录，逐个停用接管DNS的软件 |
| DNS劫持 | 请求被改送到其他解析服务，可能出现广告页、拦截页或非预期NXDOMAIN | 比较当前DNS与指定DNS，并查看网络变化 | 检查路由器、网络出口和DNS配置 |
| DNS污染 | 部分网络或区域持续收到偏离权威结果的响应 | 多网络、多DNS、权威DNS和实际连接组合验证 | 保留证据后联系网络、DNS或域名服务方 |
| CDN或GeoDNS正常差异 | 不同地区、运营商或时间返回不同但可用的IP | 检查CNAME、TTL、IP归属和实际HTTPS结果 | 不要误改DNS，先确认服务是否正常 |
| 服务器或应用故障 | 解析一致，但连接超时、TLS失败或HTTP报错 | 绕过DNS层分别测试IPv4、IPv6、TCP、TLS和HTTP | 联系CDN、主机或应用维护方 |
记录证据时，至少保存这6项信息
如果问题需要交给DNS服务商、CDN、网络管理员或运营商，建议保存：目标域名及完整记录类型、发生时间和时区、所在网络与运营商、当前使用的DNS服务器、多个DNS和权威DNS的完整输出、浏览器或curl的错误信息。不要只提交“打不开”或一张没有时间的截图。
记录时可以使用下面的模板：时间：2026-10-27；网络：家庭Wi-Fi/移动网络；域名：example.com；记录：A、AAAA、CNAME；DNS：默认DNS、1.1.1.1、8.8.8.8；权威DNS：实际NS；结果：IP、TTL、状态；连接：IPv4/IPv6、TLS、HTTP；是否换网络复现：是/否。其中日期仅作为记录格式示例，实际提交时应填写问题真实发生时间。
安全提醒与恢复建议
临时更换DNS、启用加密DNS或修改路由器设置前，先记录原配置。Google文档建议在更改公共DNS前保存原DNS地址，并提醒不同系统和设备的配置方法并不完全相同。测试结束后，如果问题没有得到证实，不要长期保留多个不明来源的DNS、代理或网络配置。
DNS over HTTPS和DNS over TLS可以加密设备到递归解析器之间的DNS通信，但它们不等于服务器一定可达，也不能单独证明某次异常就是污染。Google资料说明，DoH和DoT主要用于增强传输过程中的隐私与安全，并可与DNSSEC验证配合使用；相关说明见Google Public DNS安全传输文档。排障时应一次只改变一个变量，避免同时修改DNS、代理、MTU和路由，导致无法判断究竟是哪项设置产生影响。
常见问题
不同DNS返回不同IP，就是DNS污染吗？
不是。CDN、GeoDNS、负载均衡、IPv4与IPv6记录差异、缓存时间不同，都可能造成不同IP。应先比较相同记录类型、CNAME、TTL、响应状态，再用权威DNS和实际连接结果核对。
DNS污染和DNS劫持有什么区别？
DNS污染通常强调查询过程中收到偏离正常结果的错误响应；DNS劫持更强调请求被改送、改写或替换。实际排查时两者可能同时出现，不能只凭“打不开”区分，应比较当前网络、指定DNS、权威DNS和换网络后的结果。
只清空DNS缓存能解决污染吗？
只能排除本机缓存中的旧记录或失败记录，不能修复网络出口、路由器、递归DNS或权威DNS问题。Windows可用<code>ipconfig /flushdns</code>清理DNS客户端缓存，之后必须重新查询并比较结果。
为什么A记录正常，但浏览器仍然打不开？
浏览器可能优先使用AAAA记录，或者问题发生在TCP、TLS、代理、HTTP、CDN或服务器层。建议分别执行IPv4和IPv6测试，并用<code>curl -I</code>、<code>curl -4 -I</code>和<code>curl -6 -I</code>分开验证。
macOS和Linux应该用什么命令排查？
macOS或Linux上可使用<code>dig</code>查询A、AAAA、CNAME、TTL并指定DNS服务器；需要沿委派链核对时使用<code>dig +trace</code>。使用systemd-resolved的Linux可用<code>resolvectl status</code>查看DNS配置、用<code>resolvectl query example.com</code>查询。
什么时候应该联系DNS服务商或网络运营商？
当同一网络下多台设备可以稳定复现，且多个时间点都出现与权威DNS不一致的结果，同时你已经排除了hosts、本地缓存、代理、CDN和IPv6差异，就应提交完整的查询输出、时间、网络、DNS服务器和连接错误，而不是只描述网页打不开。