Linux DNS解析失败多因配置错误，需依次检查/etc/resolv.conf内容及符号链接目标、systemd-resolved或NetworkManager实际生效的DNS设置、上游服务器连通性，以及本地代理服务状态。
Linux系统DNS解析失败，多数情况是配置层面出了问题，而不是网络连通性本身。排查时应优先检查本地DNS配置是否正确、生效，再逐步验证上游DNS服务器是否可达、响应是否正常。
确认当前使用的DNS服务器
系统实际使用的DNS可能和配置文件不一致，尤其在使用NetworkManager或systemd-resolved的环境中：
- 运行 systemd-resolved 时，用
resolvectl status查看当前活跃的DNS服务器和搜索域 - 直接查看
/etc/resolv.conf，但注意它可能是符号链接（如指向/run/systemd/resolve/stub-resolv.conf或/run/NetworkManager/resolv.conf），需结合实际指向判断 - 若使用 NetworkManager，可通过
nmcli dev show | grep DNS获取接口级DNS设置
检查 /etc/resolv.conf 内容是否合法
该文件格式简单但敏感，常见错误包括：
- 多于3个 nameserver 行（glibc只读前3个）
- IP地址写错（如写成
192.168.1.256或漏掉点分十进制格式） - 混入注释以外的非法字符（如中文空格、不可见控制符）
- search 或 domain 行拼写错误，导致域名补全异常
验证DNS服务可达性和响应能力
配置正确不代表能用，需实测解析行为：
- 用
dig @DNS_IP example.com +short绕过系统配置，直连指定DNS服务器测试 - 用
nslookup example.com观察是否返回结果及所用服务器（注意其默认行为可能受/etc/resolv.conf影响） - 若直连上游DNS成功，但系统解析失败，大概率是
systemd-resolved或dnsmasq等本地转发服务未正常工作
留意本地DNS代理服务的干扰
现代Linux发行版常启用本地DNS代理，容易掩盖真实配置问题：
-
systemd-resolved 默认监听
127.0.0.53:53，/etc/resolv.conf若指向该地址，需确保服务正在运行（systemctl status systemd-resolved） - 某些桌面环境会启动 dnsmasq 或 unbound，它们可能拦截DNS请求并缓存错误结果
- 临时停用本地代理（如
sudo systemctl stop systemd-resolved），再将/etc/resolv.conf改为直连公网DNS（如8.8.8.8），可快速定位是否为代理层故障
不复杂但容易忽略，DNS解析失败往往卡在配置路径的某个环节——从文件内容、符号链接目标，到代理服务状态，逐层验证比盲目重启更有效。
