DNS转发超时与失败本质是请求未响应，需按“请求发出→抵达→应答”三环节排查：先用ping 8.8.8.8和ping baidu.com确认是否真为DNS问题；再查/etc/resolv.conf实际生效配置；接着dig @8.8.8.8直连测试可达性；最后排查systemd-resolved、防火墙及代理干扰。
Linux 中 DNS 转发超时与失败，本质是查询请求发出去后没收到响应——不是解析结果错，而是“根本没通到 DNS 服务器”。排查要聚焦在“请求是否发出、能否抵达、对方是否应答”这三个环节，而不是一上来就改配置或换 DNS。
确认是不是 DNS 问题本身
先排除干扰，锁定故障域：
- 执行 ping -c 3 8.8.8.8：通 → 网络层通畅；不通 → 查网卡、路由、网关，DNS 排查暂停
- 执行 ping -c 3 baidu.com：返回 unknown host → 高概率 DNS 解析失败；返回超时或 Network is unreachable → 不是 DNS 问题
- 用 IP 直连验证服务层：curl -I http://180.101.49.12（百度某公网 IP）能返回 HTTP 头，说明应用层通，进一步坐实是 DNS 卡点
检查 /etc/resolv.conf 是否真实起作用
这个文件是系统 DNS 查询的起点，但常被 systemd-resolved、NetworkManager 或云平台自动覆盖：
- 运行 cat /etc/resolv.conf，看是否有有效 nameserver 行；若只有
nameserver 127.0.0.53，需确认 systemd-resolved 是否真在运行（systemctl is-active systemd-resolved） - 若使用 NetworkManager，
nmcli dev show | grep DNS才反映实际生效的上游 DNS，/etc/resolv.conf 可能只是软链接或 stub - 临时绕过所有管理器测试：用 echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf，再试
nslookup google.com。成功即说明原配置或代理机制有问题
直连测试 DNS 服务可达性与响应能力
跳过本地 resolver 和缓存，直接向目标 DNS 发包，验证端到端通路：
- 用 dig @8.8.8.8 google.com 或 nslookup baidu.com 114.114.114.114：若超时 → 网络路径或防火墙阻断；若返回 SERVFAIL/REFUSED → DNS 服务异常或拒绝递归
- 检测 UDP 53 端口是否可达：nc -zuv 8.8.8.8 53 或 timeout 3 bash -c 'echo >/dev/udp/8.8.8.8/53' 2>/dev/null && echo ok || echo fail
- 注意：某些环境（如企业内网、K8s Pod）可能屏蔽 UDP 53，但允许 TCP 53；可加
+tcp参数重试：dig +tcp @8.8.8.8 google.com
排查本地转发服务与干扰项
systemd-resolved、dnsmasq、代理变量等可能静默劫持或延迟 DNS 请求：
- 查 systemd-resolved 实际上行：resolvectl status，关注 “DNS Servers” 和 “Current Scopes” 字段
- 查 dnsmasq 是否运行：ps aux | grep dnsmasq，若启用，检查
/etc/dnsmasq.conf中的server=配置是否指向了不可达地址 - 检查环境变量干扰：echo $http_proxy $https_proxy $no_proxy；某些工具（如 curl、wget）会因 proxy 设置强制走 HTTP 代理，完全绕过系统 DNS
- 检查 /etc/hosts 是否有错误映射（如把 github.com 指向 127.0.0.1），用 getent hosts github.com 可绕过 ping/curl 的额外逻辑，更贴近真实解析链路
