linux dns解析失败时,应按/etc/resolv.conf配置→dns服务状态→上游连通性→端口可达性→nsswitch.conf顺序逐层排查,重点验证nameserver有效性、systemd-resolved或networkmanager管理方式、udp 53端口通断及hosts文件干扰。

Linux DNS 解析失败,典型表现是 ping google.com 报 Unknown host,或 curl/wget 提示 Could not resolve host,但用 IP 地址(如 ping 8.8.8.8)能通——这说明网络层通畅,问题出在“域名→IP”这一步。核心思路是:从本地配置出发,逐层验证解析链路是否完整、可达、有效。
确认 /etc/resolv.conf 是否真实生效
该文件是系统 DNS 查询的“第一入口”,但容易被覆盖或忽略:
- 运行
cat /etc/resolv.conf,检查是否有至少一行nameserver,且 IP 可达(如8.8.8.8、114.114.114.114或内网 DNS) - 若内容为空、全被注释、或指向
127.0.0.53却未运行systemd-resolved,解析必失败 - Ubuntu 18.04+、Fedora 等默认由
systemd-resolved动态管理此文件,手动修改会被重写;应改用resolvectl dns eth0 8.8.8.8或编辑/etc/systemd/resolved.conf后执行sudo systemctl restart systemd-resolved - 若使用 NetworkManager,可在
/etc/NetworkManager/NetworkManager.conf中添加dns=none,再重启服务,避免其接管 DNS 配置
验证 DNS 服务本身是否正常工作
即使 resolv.conf 正确,后端服务宕机或转发异常也会导致解析中断:
- 查服务状态:
systemctl status systemd-resolved(确认 active),或systemctl status dnsmasq(如启用本地缓存) - 查当前实际使用的上游 DNS:
resolvectl status(systemd-resolved 系统)或nmcli dev show | grep DNS(NetworkManager 管理) - 绕过本地服务直连测试:
dig @8.8.8.8 github.com或nslookup baidu.com 114.114.114.114;若成功,说明问题在本地服务或其到上游的路径上 - 注意
ndots设置陷阱:若/etc/resolv.conf含options ndots:5,短域名(如redis)会先尝试拼接 search 域多次失败才查根,造成明显延迟甚至超时
检查网络连通性与端口可达性
DNS 查询依赖 UDP 53 端口(TCP 53 用于大响应或重试),任一环节阻断都会静默失败:
- 基础连通性:
ping -c 3 8.8.8.8—— 若不通,先排查路由、网卡、网关 - DNS 端口检测:
nc -zv 8.8.8.8 53或timeout 3 bash -c 'echo > /dev/tcp/8.8.8.8/53' 2>/dev/null && echo ok || echo fail - 本机防火墙:
sudo ufw status(Ubuntu)或sudo firewall-cmd --list-all(RHEL/CentOS),确保允许出站 UDP 53 - 云服务器需同步检查安全组规则;企业/校园网可能劫持 53 端口,可临时换用 DoH(如
curl -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=google.com&type=A")验证
核对解析顺序与本地干扰项
系统不只靠 DNS,还受 hosts 文件和 NSS 配置影响,顺序错乱会导致预期外行为:
- 看解析优先级:
cat /etc/nsswitch.conf | grep hosts,标准应为hosts: files dns—— 表示先查/etc/hosts,再走 DNS;若写成hosts: dns files或漏掉dns,域名将无法解析 - 检查
/etc/hosts是否存在错误映射(如把github.com指向了错误 IP 或 localhost),尤其注意开发环境常手动加的条目 - 验证 NSS 实际行为:
getent hosts google.com—— 它按nsswitch.conf规则执行,结果可反映真实解析路径 - 清除本地缓存(如有):
sudo systemd-resolve --flush-caches(systemd-resolved)、sudo systemctl restart nscd(nscd)










