网站打不开这件事，原因可以排出一长串：源站宕机、本地网络故障、防火墙拦截、CDN回源异常。但在排除了这些“硬故障”之后，有一类问题格外隐蔽，网络明明是通的，IP也能ping通，偏偏域名解析出来的地址是错的。你输入的网址指向了一台根本不存在的服务器，或者一台与你毫无关系的机器。这就是DNS污染。

　　DNS污染的本质，是在域名解析的信任链条上做了手脚。传统DNS查询走UDP 53端口，明文传输，不验证应答来源的合法性。任何能在查询路径上截获请求的中间设备——无论是运营商层面的策略性干预、恶意路由器的中间人攻击，还是公共Wi-Fi的广告劫持——都可以抢在权威服务器之前，向你的递归解析器塞入一个伪造的应答。由于UDP无连接、无认证，递归服务器往往照单全收，把这个错误的IP缓存下来，并在接下来几分钟到几小时内，持续把错误答案分发给所有来问同一个域名的用户。

　　判断问题是否出在DNS上，有几个直观的信号。同一域名在手机热点下能打开、切回WiFi就失败；直接用IP地址访问正常、换成域名就超时；用nslookup分别向运营商DNS和可信公共DNS查询，返回的IP天差地别。一旦确认解析结果异常，接下来的修复路径可以归纳为三个递进的步骤，每一步的生效层面不同，复杂度也逐级上升。

　　第一步：更换DNS服务器，切断污染源头

　　多数轻度污染场景下，更换递归解析服务器就足以解决问题。运营商默认下发的DNS服务器是污染发生的高发节点，尤其是当查询指向境外域名时，某些网络环境会在国际出口处对特定查询进行干预，抢先返回伪造应答。将解析请求从运营商DNS切换到受污染影响较小的公共DNS，等于绕开了被动手脚的那一段路径。

　　国内环境下的公共DNS选择需要考虑实际可达性与解析质量。阿里公共DNS和腾讯DNSPod是国内节点覆盖较广、对国内站点解析优化较好的选项。Google虽然知名度高，但在国内网络环境下解析延迟往往不理想，部分运营商甚至存在丢包，作为首选并不合适。如果目标网站是境外站点且污染来自国际链路层面，切换国内公共DNS的效果可能有限，因为污染发生在更上游的位置，解析请求无论从哪个国内递归服务器发出，都可能在同一出口节点被截获。

　　Windows下的修改路径：控制面板 → 网络和共享中心 → 更改适配器设置 → 右键当前连接 → 属性 → 双击“Internet协议版本4(TCP/IPv4)”→ 选择“使用下面的DNS服务器地址”并填入首选与备用地址。macOS在系统设置 → 网络 → 当前连接 → 详情 → DNS中修改。手机端在Wi-Fi设置中长按或点击当前网络，将DNS配置从自动改为手动填入。

　　需要明确一个预期：更换DNS解决的是“递归服务器收到的是污染结果”这一类问题，但如果污染发生在你的设备到递归服务器之间的传输链路上——即查询请求本身在到达DNS服务器之前就被中间设备拦截并伪造了应答——那么换再干净的DNS服务器也无济于事。这时候需要进入第二步和第三步。

　　第二步：清除本地缓存，消除残留污染

　　更换DNS之后如果问题依旧，一个常被忽略的原因是本地缓存里还留着污染期间写入的错误记录。操作系统和浏览器都会缓存DNS解析结果，TTL未过期之前，即使你已经切换到了干净的DNS服务器，系统仍然会从缓存中读取旧的、被污染的IP地址。

　　Windows下最直接的方式是以管理员身份打开命令提示符，执行：

ipconfig /flushdns

　　执行成功后会显示“已成功刷新 DNS 解析缓存”。如果权限不足，这一步会静默失败，务必确认命令行窗口标题带有“管理员”字样。

　　macOS根据版本不同命令有所差异。Ventura及更新版本在终端中执行：

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

　　旧版本macOS(Monterey及以下)使用：

sudo killall -HUP mDNSResponder

　　输入管理员密码时终端不会回显字符，正常输入后回车即可。

　　浏览器层面也有独立的DNS缓存。Chrome和Edge用户可以在地址栏输入chrome://net-internals/#dns(Edge同样适用该地址)，点击“Clear host cache”按钮清除浏览器维护的主机缓存。这一步不常被提及，但在系统缓存已清、浏览器仍然固执地访问旧IP的情况下，它是必要操作。

　　完成系统级和浏览器级缓存清理后，重新尝试访问目标网站。如果解析恢复正常，说明污染的影响范围仅限于本地缓存，问题已解决。

　　第三步：启用加密解析，从传输层规避篡改

　　前两步失效，意味着污染不是发生在“你向递归服务器要答案”这个环节，而是发生在“答案在回来的路上被掉包”或者“你的查询请求在发出之前就被截获”。传统DNS的明文UDP传输是这一切得以发生的根基。加密DNS协议——DNS over HTTPS(DoH)和DNS over TLS(DoT)——把查询封装进TLS加密通道，中间设备无法读取查询内容，也无法在不破坏TLS握手的情况下注入伪造应答。

　　DoH将DNS查询包装成标准的HTTPS请求，走443端口，外观上与普通网页流量无异，在大多数网络环境中具有较好的穿透性。DoT走独立的853端口，使用TLS加密，协议开销略低于DoH，但853端口在某些网络策略下可能被针对性限制。Google公共DNS同时支持两种协议，DoH端点为https://dns.google/dns-query，DoT端点为dns.google:853。Cloudflare的DoH端点则是https://cloudflare-dns.com/dns-query

　　对于普通用户，最便捷的启用方式是在浏览器层面开启。Firefox在设置 → 隐私与安全 → 启用基于HTTPS的DNS中配置。Chrome在设置 → 隐私和安全 → 安全 → 使用安全DNS中开启，可以选择自定义提供商并填入上述DoH地址。浏览器级DoH只影响该浏览器内的域名解析，系统层面的其他应用仍然走传统DNS。如果需要全局生效，需要在操作系统层面配置DoH(Windows 11已原生支持，在设置 → 网络和Internet → 以太网/Wi-Fi → DNS服务器分配中启用加密)或使用支持DoH转发的本地工具。

　　需要清醒认识的是，加密DNS解决的是“解析结果在传输中被篡改”的问题，但它不解决“递归服务器本身返回了错误结果”的问题。如果某个域名在权威DNS层面就被错误配置，或者你使用的加密DNS提供商本身受到了策略性影响，DoH也无法变出正确的IP。加密解析的价值在于把可被中间设备随意干预的明文查询，变成了一条端到端加密的通道，大幅抬高了污染的实施门槛。

　　三步之后：如果仍然打不开

　　三步走完，绝大多数由解析篡改导致的访问失败可以被修复。但如果问题依然存在，需要把视线从DNS层面移开。ping域名看解析出的IP是否仍然异常；curl -v或浏览器开发者工具查看连接建立在哪一步失败；尝试用目标网站的真实IP直接访问(如果已知)，确认源站本身是否可达。某些情况下，你面对的可能根本不是DNS污染，而是目标IP被封锁、路由黑洞、或者源站针对你所在区域的访问限制。这些问题的修复路径与DNS无关，继续在解析层面折腾只会浪费时间。

　　另一个务实的临时手段是修改hosts文件，将域名与已知正确的IP手动绑定，完全绕过DNS查询。Windows路径为C:\Windows\System32\drivers\etc\hosts，macOS和Linux为/etc/hosts。

　　保存后刷新DNS缓存生效。这个方法的局限在于硬编码的IP可能随CDN调度或源站迁移而失效，需要手动维护，仅适合作为临时应急。

　　常见问答

　　Q：换了公共DNS，为什么还是打不开?

　　污染可能发生在你到DNS服务器之间的链路上，而非DNS服务器本身。换DNS只改变了“问谁”，没有改变“怎么问”。明文UDP查询在到达新DNS服务器之前仍可能被路径上的设备截获并伪造应答。这种情况需要进入第三步，用DoH/DoT加密查询通道。

　　Q：DoH和DoT哪个更好?

　　DoH走443端口，与普通HTTPS流量混在一起，在受限网络中的穿透性通常更好；DoT走853端口，协议开销略低，连接建立更快，但端口特征明显，可能被针对性阻断。浏览器场景优先用DoH，移动设备全局配置DoT(如Android私人DNS)是更简洁的方案。两者在安全性上没有实质差距。

　　Q：清除DNS缓存会有什么副作用?

　　没有持久性副作用。清除后首次访问常用网站时会多一次解析查询，延迟增加几毫秒到几十毫秒，随后缓存重新建立，恢复正常。不建议高频执行，因为缓存本身的设计目的就是减少重复查询，频繁清空反而增加解析负担。

　　Q：手机流量能打开、WiFi打不开，一定是DNS污染吗?

　　大概率是，但不绝对。也可能是WiFi路由器的DNS配置被篡改、路由器本身被恶意固件劫持，或者WiFi所属网络存在策略性拦截。先用手机热点对比确认现象，然后在WiFi环境下执行nslookup 域名，观察返回的IP是否与热点环境下一致。不一致则指向DNS层面的问题。

　　Q：加密DNS会影响网速吗?

　　对网页加载速度的影响在常规使用中难以感知。DoH/DoT的TLS握手会增加首次查询的延迟，但连接复用后后续查询的额外开销很小。考虑到DNS解析在整体页面加载时间中的占比很低，加密带来的安全性收益远大于微小的延迟代价。