域名被DNS污染打不开怎么恢复：确认与恢复步骤

域名突然在国内或部分地区打不开，而你自己（或海外同事）访问一切正常。这种时候第一件事不是换域名，也不是换服务器，而是把故障压到具体某一层：是解析被抢答，还是访问被阻断，或者干脆是源站自己出了问题。这三种表现很像，处理路径却完全不同，误判成 DNS 污染再去买清洗，钱花了问题还在。

下面按实际动手的顺序走：先用四个动作确认是不是污染，再分两条线恢复——你和团队能立刻用上的临时手段，以及让普通用户不做任何设置就能打开网站的业务侧方案。

四步确认：故障到底卡在解析、链路还是源站

第一步，绕开域名直连源站。 用真实 IP 发一次请求，带上 Host 头：

curl -sv -H "Host: 你的域名" https://源站IP/ --resolve 你的域名:443:源站IP
ping 源站IP
telnet 源站IP 443

如果直连能拿到正常响应，说明服务本身是好的，问题在域名到 IP 这一段。如果直连也不通，先去查防火墙、安全组和服务进程，别往 DNS 上想。

第二步，对比境内外解析结果。 用 dig +trace 你的域名 看权威服务器返回什么，再用多地拨测工具看各省各运营商解析出的 IP。典型的污染特征是：权威解析和境外解析都返回真实入口 IP，而境内某些运营商的 LocalDNS 返回一个黑洞 IP、一个和你毫无关系的境外 IP，或者干脆是错误记录。

第三步，向一个不提供 DNS 服务的境外 IP 发查询。 这一步最能一锤定音：

nslookup 你的域名 <一个你确定没有运行 DNS 服务的境外 IP>

正常情况下这条查询应该超时、拿不到任何应答。如果它几乎秒回了一条 A 记录，那条记录不可能来自那个 IP——它来自链路上识别明文 UDP 53 查询并抢先伪造应答的设备。到这一步，链路级污染基本可以确认。

第四步，换网络复测。 不同运营商、不同城市、手机流量各测一遍。污染通常有明显的地域和运营商差异，只在一台机器上看到的异常，更可能是本地缓存问题。

DNS 污染四步分层排查流程与对应结论

定性之前，先排掉几种更常见的原因

访问阻断，不是解析污染。 解析结果正确、TCP 也能建连，但 80/443 被 RST 或返回一个阻断提示页——这属于内容/备案层面的阻断，做 DNS 清洗没用。
解析记录本身写错，或 TTL 还没过。 先登录 DNS 服务商核对权威记录；刚改过记录的话，按旧 TTL 的时长等一等再下结论。
源站故障、端口没起、安全组误封。 IP 直连就不通，和 DNS 无关。
只有个别用户打不开。 更可能是那几台机器或那个 LocalDNS 缓存了一条坏结果，刷一下缓存就好。

可用的判断口径：源站直连正常 + 权威解析正常 + 境内解析返回错误 IP + 存在伪造抢答，四项同时成立才按 DNS 污染处理。缺一项，回到上一步重新看。

临时手段：只够你和内部团队自救

确认是污染之后，最先能做的是让自己人恢复访问，方便继续排查和发版：

清本地缓存。 Windows ipconfig /flushdns；Linux 视发行版重启 systemd-resolved 或 nscd；macOS sudo dscacheutil -flushcache。
换公共 DNS（作用有限）。 换成 1.1.1.1、8.8.8.8 有时能解决 LocalDNS 缓存了脏记录的情况，但如果是针对你这个域名的链路级抢答，明文 UDP 53 走到哪都会被旁路劫持，换了往往照样错。
用 DoH 或 DoT。 加密解析把查询包在 HTTPS/TLS 里，中间设备看不到你在查什么，也就无从抢答。这是客户端侧真正有效的一招。
hosts 绑定真实 IP。 应急可用，但要注意证书和 SNI 是否匹配，而且入口 IP 一变就得手动跟，不适合长期挂着。

把话说明白：这些都是自救，不是修复。 你不可能让成千上万的终端用户去改 hosts、配 DoH，App 里的请求也不会因为你自己能打开就恢复。所以这一段做完，就该转到业务侧。