linux系统能ping通ip但无法解析域名，说明dns配置、systemd-resolved服务状态或nsswitch.conf解析顺序出错，需依次验证resolv.conf来源、resolved服务活性、resolvectl状态及hosts解析优先级。
Linux系统能ping通114.114.114.114却无法ping www.baidu.com，说明网络层连通正常，但域名解析环节已中断——问题必然出在DNS配置、服务状态或解析路径上，必须按真实生效顺序逐层验证。
确认DNS解析是否真的失效
先用nslookup验证解析能力：执行nslookup www.baidu.com。若返回server can't find www.baidu.com: NXDOMAIN或connection timed out，说明解析失败；若返回正确IP，则问题不在DNS本身，可能是ping命令被别名或防火墙拦截。
再对比测试本地回环DNS：运行nslookup www.baidu.com 127.0.0.53。如果这步成功但不指定服务器时失败，说明系统默认没走127.0.0.53，或stub resolver未启用。
检查/etc/resolv.conf的真实来源和内容
执行ls -l /etc/resolv.conf，观察输出。若显示resolv.conf -> /run/systemd/resolve/stub-resolv.conf，说明由systemd-resolved管理，直接编辑该文件会被覆盖。
若显示-rw-r--r-- 1 root root且无箭头，才是可直接修改的普通文件。此时用cat /etc/resolv.conf查看内容，重点确认是否存在nameserver行，且IP非127.0.0.1或空行。
【关键陷阱】某些发行版（如Ubuntu 22.04+）中，/etc/resolv.conf是符号链接，指向stub-resolv.conf，而后者只含127.0.0.53——若systemd-resolved服务未运行，这个地址根本无响应。
验证systemd-resolved服务状态与配置
运行systemctl is-active systemd-resolved。若返回inactive或failed，解析必然中断，因为stub resolver失去上游转发能力。
若服务活跃，执行resolvectl status，检查OUTPUTS区域是否列出有效DNS服务器。若仅显示Current DNS Server: 127.0.0.53且无“DNS Servers”列表，说明上游DNS未被正确注入——常见于NetworkManager未向resolved推送配置。
临时启用fallback：执行sudo resolvectl revert eth0（将eth0替换为你的主网卡名），强制从DHCP重新拉取DNS并提交给resolved。
审查nsswitch.conf中的解析优先级链
打开/etc/nsswitch.conf，定位到hosts:这一行。
方法一：若当前为hosts: files，立即改为hosts: files dns。否则系统只查/etc/hosts，完全跳过DNS查询，哪怕resolv.conf写满8.8.8.8也无效。
方法二：若当前为hosts: dns [NOTFOUND=return] files，删掉[NOTFOUND=return]部分。这个标志会让DNS一失败就终止查找，不回退到files，导致即使/etc/hosts里有对应条目也不生效。
绕过系统配置直连上游DNS测试
第一步：用dig绕过本地resolver，直连公共DNS——执行dig @8.8.8.8 www.baidu.com +short。若返回IP，证明外网DNS可用，问题锁定在本机配置；若超时，说明防火墙或路由屏蔽了UDP 53端口。
第二步：检查是否被iptables拦截——运行sudo iptables -L OUTPUT -n | grep :53。若出现REJECT或DROP规则，执行sudo iptables -D OUTPUT -p udp --dport 53 -j DROP临时放行。
第三步：确认DNS端口可达——执行nc -zv 8.8.8.8 53。若显示Connection refused，说明目标DNS服务器拒绝UDP查询（正常），但Connection timed out则表明中间链路阻断UDP 53。
