服务器 dns 解析超时如何处理

学完这篇，你能按「确认超时 → 查配置来源 → 换 DNS → 改持久化配置 → 抓包验证」的顺序，处理大多数 Linux 服务器的 DNS 解析超时问题。

第一步：确认到底是不是 DNS 超时

这一步要拿到「卡在 DNS」的证据，而不是误判成网络断开。先执行：

time dig www.baidu.com +time=2 +tries=1
getent hosts www.baidu.com

如果 dig 的 Query time 达到 5000 msec 以上，或 getent 明显卡住，而 ping -c 2 223.5.5.5 正常，基本就是 DNS 问题。再看一眼当前用的 DNS：

cat /etc/resolv.conf

注意：/etc/resolv.conf 可能只是软链接，直接改它会在重启或 NetworkManager 刷新后丢失，后面第四步要处理持久化。

第二步：查清 DNS 配置由谁管理

这一步要确定改哪个文件才不会被覆盖。执行：

ls -l /etc/resolv.conf

• 若指向 /run/systemd/resolve/stub-resolv.conf，配置在 /etc/systemd/resolved.conf，属于 systemd-resolved（Ubuntu 18.04+/CentOS 8+）。
• 若文件里写着 Generated by NetworkManager，配置在网卡或 NetworkManager。
• 若没有任何注释，可能是手工维护或 resolvconf 包生成。

查看托管状态：

resolvectl status
nmcli dev show | grep DNS

CentOS 7 常见入口是 /etc/sysconfig/network-scripts/ifcfg-eth0，里面有 DNS1=、DNS2=。

第三步：逐个 DNS 服务器测速

这一步找出是哪一个 DNS 慢。分别测：

dig @223.5.5.5 www.baidu.com +time=2 +tries=1
dig @114.114.114.114 www.baidu.com +time=2 +tries=1
dig @8.8.8.8 www.baidu.com +time=2 +tries=1

如果有 IPv6 的 nameserver（如 2400:3200::1），而服务器没有可用 IPv6 出口，会出现「先等 IPv6 超时、再走 IPv4」的典型 5 秒卡顿。执行 ip -6 route 确认无默认路由后，应删掉或禁用 IPv6 DNS。

第四步：临时修改验证效果

这一步用最小改动验证「换 DNS + 缩短超时」是否有效。编辑 /etc/resolv.conf：

nameserver 223.5.5.5
nameserver 119.29.29.29
options timeout:1 attempts:2 rotate

timeout:1 表示单次查询 1 秒超时，attempts:2 表示重试 2 次，rotate 表示轮询多个 DNS。保存后再跑：

time dig www.baidu.com

若 Query time 降到几十毫秒，方案成立，继续第五步做持久化。

第五步：写进持久化配置

这一步让改动在重启后仍然生效。按管理方式选一种：

systemd-resolved（Ubuntu 20.04/22.04、CentOS 8+）
编辑 /etc/systemd/resolved.conf：

[Resolve]
DNS=223.5.5.5 119.29.29.29
FallbackDNS=114.114.114.114
Domains=~.
Cache=yes
DNSStubListener=yes

然后：

systemctl restart systemd-resolved
resolvectl status

注意：Ubuntu 若启用了 Netplan，/etc/netplan/*.yaml 里的 nameservers 也会下发 DNS，改完执行 netplan apply 再确认。

NetworkManager（CentOS 7、RHEL 7/8 桌面版）
在 /etc/NetworkManager/conf.d/90-dns.conf 写入：

[main]
dns=default

随后 systemctl restart NetworkManager。或在 ifcfg-eth0 中设置 DNS1=223.5.5.5、PEERDNS=no，再 systemctl restart network。

Windows Server
以管理员打开 PowerShell：

Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 223.5.5.5,119.29.29.29
ipconfig /flushdns

第六步：抓包确认是网络还是 DNS 服务端问题

这一步排除「DNS 服务器没回包」。执行：

tcpdump -i eth0 -nn port 53

另开终端 dig www.baidu.com。如果只看到请求包、没有响应包，说明丢包在中间链路或 DNS 服务器侧；如果很快有响应但应用仍慢，检查 /etc/nsswitch.conf 的 hosts: 行，应为 files dns，避免先查不存在的 NIS/LDAP。

高并发服务器还可启用本地缓存：

systemctl enable --now systemd-resolved   # 已用 resolved 时自带缓存

yum install -y nscd && systemctl enable --now nscd

第七步：验证并观察

这一步确认修复稳定。连续执行：

for i in 1 2 3 4 5; do time dig www.baidu.com +short; done
curl -v https://www.baidu.com -o /dev/null
resolvectl statistics      # systemd-resolved 环境

5 次都应在 100 ms 内返回，且不再出现 5 秒级等待。

注意：如果业务使用长连接或连接池，DNS 改完后要重启应用进程，否则旧进程仍持有可能已失效的解析结果。

小结

• 用 time dig 和 getent hosts 先证明是 DNS 超时，而不是网络中断。
• 先看 ls -l /etc/resolv.conf 判断配置由 systemd-resolved、NetworkManager 还是手工维护。
• 临时用 options timeout:1 attempts:2 验证，再写进 /etc/systemd/resolved.conf 或 ifcfg-eth0 持久化。
• 无 IPv6 出口时务必删掉 IPv6 nameserver，否则会出现固定 5 秒延迟的假超时。
• 改完配置重启应用，必要时用 tcpdump 抓 53 端口确认丢包位置。