问题出在dns解析环节，需按生效顺序逐层排查：先用nslookup/dig验证解析能力，再检查resolv.conf真实来源及内容，接着确认systemd-resolved服务状态与上游dns配置，最后核验nsswitch.conf解析顺序和hosts文件干扰。
Linux 中域名无法解析，但能 ping 通 IP，说明网络层通畅，问题一定出在“域名到 IP”的转换环节。排查要按实际生效顺序一层层验证，不能只改 /etc/resolv.conf 就停手。
先确认 DNS 解析是否真的失败
用 nslookup 或 dig 直接测试，避开 ping 的别名和缓存干扰：
-
nslookup www.baidu.com—— 若返回connection timed out或NXDOMAIN，说明解析失败 -
nslookup www.baidu.com 114.114.114.114—— 指定公共 DNS 测试，成功则说明本地配置或服务异常 -
dig @8.8.8.8 mirrors.tencentyun.com—— 针对特定域名（如腾讯云源）验证上游可达性
检查 /etc/resolv.conf 是否真实生效
这个文件常被自动管理，内容未必代表实际使用的 DNS：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
ls -l /etc/resolv.conf—— 若指向/run/systemd/resolve/stub-resolv.conf，说明由systemd-resolved控制，手动改它无效 -
cat /etc/resolv.conf—— 若只含nameserver 127.0.0.53，而systemd-resolved未运行，就等于没 DNS - 临时验证：用
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf覆盖后重试解析
验证 systemd-resolved 服务状态与上游配置
现代发行版（如 Ubuntu 22.04+、CentOS Stream 9）默认启用该服务，它是解析链的关键中转：
-
systemctl is-active systemd-resolved—— 必须是active，否则 stub resolver 失效 -
resolvectl status—— 查看Current DNS Server和DNS Servers列表；若只有127.0.0.53且无上游，说明 NetworkManager 没推送 DNS - 强制刷新：运行
sudo resolvectl revert eth0（把eth0换成你实际网卡名），从 DHCP 重新获取并提交 DNS
核对 nsswitch.conf 解析顺序与 hosts 干扰
即使 DNS 配置全对，系统也可能根本不去查 DNS：
-
grep "^hosts:" /etc/nsswitch.conf—— 正确应为hosts: files dns；若写成hosts: files或hosts: dns [NOTFOUND=return] files，会导致跳过 DNS -
getent hosts www.baidu.com—— 这个命令走完整解析链（nsswitch → resolver → DNS），比 ping 更准 -
cat /etc/hosts | grep baidu—— 确认没有错误条目将域名映射到127.0.0.1或空地址
