Linux DNS解析失败需逐层排查：先检查/etc/resolv.conf是否有效，再用dig直连测试DNS通路，接着确认systemd-resolved状态与缓存，最后验证防火墙是否放行UDP/TCP 53端口。
Linux DNS解析失败，通常表现为 ping google.com 提示“Unknown host”或 curl 报错“Could not resolve host”。这不是网络不通，而是域名到IP的转换环节断了。定位要从本地配置出发，一层层验证是否真正走到外部DNS服务器。
看 /etc/resolv.conf 是否有效
这是系统DNS查询的起点。运行：
cat /etc/resolv.conf检查是否有类似这样的行：
nameserver 8.8.8.8nameserver 114.114.114.114
若文件为空、被注释掉，或 nameserver 后跟的是内网地址（如 192.168.1.1）但该设备不提供DNS服务，就直接导致失败。注意：NetworkManager 或 systemd-resolved 可能动态覆盖此文件，手动修改后重启网络可能失效。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
用 dig 直连测试 DNS 通路
dig 不走系统解析器链，能绕过 nsswitch.conf、systemd-resolved 等中间层，直击问题本质：
- 查本机配置的 DNS 是否响应：
dig @$(grep nameserver /etc/resolv.conf | head -1 | awk '{print $2}') google.com - 对比公共 DNS：
dig @8.8.8.8 google.com—— 若这个成功，说明是本地DNS或路径问题 - 关注输出中的 ANSWER SECTION（有无IP）、status（NOERROR=成功，SERVFAIL=服务器异常，TIMEOUT=连不上）
确认本地解析服务状态
现代发行版常启用 systemd-resolved，它监听 127.0.0.53，并接管 /etc/resolv.conf。若它没启动或异常，会影响所有依赖 libc 的程序（如 curl、ssh）：
- 查状态：
systemctl status systemd-resolved，留意是否 active (running) - 看当前生效的 DNS：
resolvectl status，检查 “DNS Servers” 和 “Current Scopes” - 刷新缓存：
sudo resolvectl flush-caches - 临时禁用以排除干扰：
sudo systemctl stop systemd-resolved，再手动写入 /etc/resolv.conf 测试
排查防火墙与端口连通性
DNS 主要用 UDP 53 端口，部分场景也走 TCP 53。很多故障实际卡在这里：
- 测 DNS 服务器可达性：
nc -uvz 8.8.8.8 53（返回 “succeeded” 才算通） - 查 OUTPUT 链是否 DROP 了 DNS：
sudo iptables -L OUTPUT -n | grep :53 - 检查是否启用了 firewalld：
sudo firewall-cmd --list-all | grep 53 - 若发现阻断规则，可临时放行：
sudo iptables -I OUTPUT -p udp --dport 53 -j ACCEPT
