4、DNS解析故障：DNS缓存污染、DNS服务器不可达、域名解析超时
说到连接断开，DNS 这块儿绝对是重灾区。很多朋友遇到网页打不开，第一反应就是“网断了”，其实呢，八成是 DNS 在搞鬼。我这些年处理过的网络故障里，DNS 相关的问题少说占了三分之一。
DNS 是什么？说白了就是“电话本”。你输入 www.baidu.com，它帮你翻译成服务器能认的 IP 地址。这个翻译过程一旦出问题，连接自然就断了。今天咱们就把 DNS 解析故障的三种典型场景掰开揉碎讲清楚。
核心要点：DNS 解析故障通常表现为“能上但打不开网页”、“部分网站能访问部分不行”、“间歇性断连”。这三种症状分别对应缓存污染、服务器不可达、解析超时。
4.1 DNS 缓存污染：你访问的“假网站”
缓存污染，也叫 DNS 劫持。简单说就是你的电脑或路由器里存了错误的 DNS 记录。你明明想上百度，结果被带到了一个钓鱼网站或者广告页面。
为什么会这样？可能是你中了恶意软件，也可能是运营商搞的鬼。我记得前几年有个项目，客户投诉说访问公司官网总是跳转到竞品页面。我过去一查，好家伙，本地 DNS 缓存里 www.company.com 指向的 IP 根本不是我们的服务器。
快速判断方法：用 nslookup 或 dig 查一下域名解析结果。如果返回的 IP 跟你预期的不一样，基本就是缓存污染了。
怎么解决？我个人的习惯是三步走：
- 清本地 DNS 缓存——Windows 上跑
ipconfig /flushdns，macOS 跑sudo dscacheutil -flushcache，Linux 重启systemd-resolved服务。 - 检查 hosts 文件——有些恶意软件会直接写 hosts 文件。Windows 在
C:\Windows\System32\drivers\etc\hosts，Linux/macOS 在/etc/hosts。打开看看有没有奇怪的映射。 - 换公共 DNS——如果运营商给的 DNS 总出幺蛾子，我建议直接换成 114.114.114.114 或者 8.8.8.8。
注意：清缓存后如果问题依旧，别急着怀疑是污染。先确认一下是不是路由器里也被改了。很多家用路由器的 DNS 设置是默认从运营商获取的，容易被篡改。
4.2 DNS 服务器不可达：电话本丢了
这种情况更直接——你的设备根本联系不上 DNS 服务器。表现就是所有域名都解析不了，但直接输 IP 地址却能正常访问。
我遇到过最典型的场景：公司内部网络改造，防火墙策略调整后忘了放行 DNS 流量。结果全公司的人都在喊“上不了网”，但还能用（因为用的是 IP 直连）。
排查步骤其实很简单：
- 第一步：ping DNS 服务器——比如
ping 114.114.114.114。如果 ping 不通，说明网络层就有问题。 - 第二步：检查端口——DNS 用的是 UDP 53 端口。用
telnet 114.114.114.114 53或者nc -vuz 114.114.114.114 53测试一下。 - 第三步：看路由——
tracert 114.114.114.114（Windows）或traceroute 114.114.114.114（Linux/macOS），看看数据包在哪一跳丢了。
| 现象 | 可能原因 | 快速验证 |
|---|---|---|
| ping DNS 超时 | 防火墙拦截、路由不可达 | 检查防火墙规则、路由表 |
| ping 通但解析失败 | DNS 服务未运行、端口被封 | telnet 53 端口、检查服务状态 |
| 部分 DNS 可用 | 主 DNS 挂了，备 DNS 正常 | 切换 DNS 顺序测试 |
一个小技巧：我习惯在电脑上配两个不同运营商的 DNS。比如主用 114.114.114.114（电信），备用 8.8.8.8（谷歌）。这样就算一个挂了，另一个还能顶上。
4.3 域名解析超时：等得太久了
解析超时跟服务器不可达有点像，但有个关键区别——超时通常意味着 DNS 服务器本身是活着的，但响应太慢，或者查询链路太长，导致在规定时间内没拿到结果。
你想想看，一个域名解析请求发出去，如果递归查询要经过七八层，每一层都慢半拍，累积起来就超时了。我曾在一次跨国项目中遇到过这个问题：国内访问国外网站，DNS 查询要绕到国外的根服务器，延迟动不动就两三秒，经常超时。
超时的常见原因：
- 递归查询链路过长——每次查询都要经过多级 DNS 服务器，每一级都有延迟。
- DNS 服务器负载过高——比如公共 DNS 在高峰期处理不过来。
- 本地网络质量差——丢包率高，重传导致超时。
- TTL 设置不合理——TTL 太短会导致频繁查询，增加超时概率。
怎么排查？我一般用 dig +trace 命令，它能一步步展示域名解析的完整路径：
dig +trace www.example.com
; <<>> DiG 9.10.6 <<>> +trace www.example.com
;; global options: +cmd
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 30 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
;; Received 489 bytes from 198.41.0.4#53(a.root-servers.net) in 45 ms
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; Received 96 bytes from 192.5.6.30#53(a.gtld-servers.net) in 60 ms
www.example.com. 86400 IN A 93.184.216.34
;; Received 56 bytes from 199.43.0.53#53(a.iana-servers.net) in 120 ms看每一跳的耗时。如果某一跳特别慢，比如超过 500ms，那问题基本就锁定了。
解决方案优先级：
- 换一个响应更快的 DNS 服务器（比如从 8.8.8.8 换成 114.114.114.114）
- 在本地搭建 DNS 缓存服务器（比如用 dnsmasq 或 unbound）
- 调整操作系统的 DNS 超时参数（Windows 注册表或 Linux 的
/etc/resolv.conf）
4.4 实战：一次完整的 DNS 故障排查
讲个真实案例吧。去年有个电商客户，双十一前夜突然反馈说后台管理系统打不开。运维团队折腾了两个小时没搞定，凌晨两点把我叫起来。
我远程上去一看，症状很典型：
- 能 ping 通外网 IP（比如 114.114.114.114）
- 但
nslookup admin.xxx.com返回超时 - 直接输 IP 地址能访问后台
嗯，基本锁定是 DNS 问题。我按顺序排查：
- 先清缓存——
ipconfig /flushdns，无效。 - 检查 hosts——没发现异常。
- 测 DNS 连通性——
ping 8.8.8.8通，但telnet 8.8.8.8 53不通。
问题找到了——防火墙把 UDP 53 端口给封了。原来是运维同事白天做安全加固时，误把 DNS 端口加进了黑名单。放行之后，一切恢复正常。
避坑指南：我曾经见过有人折腾了半天 DNS，最后发现是网线没插好。所以排查之前，先确认物理层没问题。别笑，这种事真不少见。
4.5 预防性配置建议
与其出了问题再救火，不如提前做好防护。我个人的习惯配置是这样的：
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| 主 DNS | 114.114.114.114 | 国内速度快，防劫持 |
| 备 DNS | 8.8.8.8 | 全球通用，稳定性高 |
| 本地缓存 | 启用（dnsmasq） | 减少重复查询，提升速度 |
| TTL 最小值 | 300 秒 | 避免频繁刷新导致超时 |
| 防火墙规则 | 放行 UDP 53 | 确保 DNS 查询不被拦截 |
最后说一句：DNS 问题看着复杂，其实套路就那么几个。记住“先清缓存、再测连通、最后抓包”这个顺序，大部分问题都能搞定。别慌，一步步来。