Linux上诊断DNS解析失败，核心在于系统地排查网络配置、DNS服务器设置以及本地解析器状态。这通常意味着从本地配置文件入手，逐步验证网络连通性，并最终确认上游DNS服务器是否正常响应。
解决方案当我遇到Linux系统上DNS解析失败的情况，比如
ping google.com提示
Temporary failure in name resolution，或者
curl无法连接到域名，我的第一反应是：这多半是
/etc/resolv.conf出了问题，或者是网络根本就没通。解决这类问题，我通常会按以下步骤来。
首先，我会直接查看
/etc/resolv.conf文件。这是Linux系统进行DNS查询的“指南针”。
cat /etc/resolv.conf
这里面应该有至少一行
nameserver，后面跟着一个IP地址，这就是你的系统用来查询域名的DNS服务器。如果这个文件是空的，或者指向了一个错误的IP，那问题就显而易见了。有时候，这个文件会被网络管理工具（比如NetworkManager或systemd-resolved）动态生成或覆盖，所以即使你手动修改了，也可能在重启网络后失效。我还会留意
search关键字，它定义了在解析短主机名时会尝试的域名后缀。
如果
nameserver地址看起来没问题，我会尝试直接测试这些DNS服务器。
dig @<nameserver_ip_from_resolv.conf> example.com
例如，如果
/etc/resolv.conf里写的是
nameserver 192.168.1.1，我就会运行
dig @192.168.1.1 google.com。如果这个命令成功返回了IP地址，说明DNS服务器本身是工作的。如果失败，那可能就是DNS服务器有问题，或者我的机器根本无法连接到它。为了进一步验证，我还会尝试公共DNS服务器，比如Google的
8.8.8.8：
dig @8.8.8.8 google.com。如果公共DNS能解析，而我的配置的DNS不行，那问题就指向了我的本地DNS服务器或网络路径。
接着，我会检查网络连通性。如果DNS服务器都ping不通，那解析失败也就不足为奇了。
ping -c 3 <nameserver_ip>
如果ping不通，我就会检查我的网络接口是否正常工作：
ip a ip route
确认网卡是否激活，IP地址和子网掩码是否正确，以及默认网关是否指向了正确的路由器。有时候，最简单的网络配置错误，比如IP地址冲突或者网线没插好，就会导致一系列看似复杂的DNS问题。
再深挖一点，我会检查
/etc/nsswitch.conf。这个文件决定了系统查找主机名、密码等信息的顺序。确保
hosts:这一行包含了
dns，例如
hosts: files dns。这意味着系统会先检查
/etc/hosts文件，然后才去查询DNS。如果这里配置不当，DNS查询可能根本就不会被触发。
对于使用
systemd-resolved的系统，情况会稍微复杂一些。
/etc/resolv.conf往往是一个符号链接，指向
/run/systemd/resolve/stub-resolv.conf或
/run/systemd/resolve/resolv.conf。我会用
resolvectl status来查看
systemd-resolved的当前状态、配置的DNS服务器以及缓存情况。
systemctl status systemd-resolved resolvectl status resolvectl query example.com
如果
systemd-resolved出现问题，重启服务
sudo systemctl restart systemd-resolved有时能解决。
最后，防火墙也是一个不能忽视的因素。虽然不常见，但如果本地防火墙（如
firewalld或
ufw）阻止了UDP 53端口的对外连接，那DNS查询自然无法进行。
sudo firewall-cmd --list-all sudo ufw status
我还会检查系统日志，特别是
journalctl -u systemd-resolved或
dmesg，看看有没有相关的错误信息，这些往往能提供一些线索。 DNS解析失败通常有哪些常见迹象？
当Linux系统遭遇DNS解析失败时，它往往不会直接告诉你“DNS挂了”，而是以各种各样的应用层错误来表现。在我看来，最明显的几个迹象包括：
首先，最直观的，就是浏览器无法打开网页。你会看到浏览器显示“此站点无法访问”、“DNS_PROBE_FINISHED_NXDOMAIN”或者类似的错误信息。这几乎是DNS问题的标志性表现。
其次，命令行工具通过域名访问失败，但通过IP地址访问成功。这是一个非常关键的诊断点。比如，你尝试
ping google.com可能会得到
Temporary failure in name resolution或
Name or service not known的错误，但如果
ping 142.250.187.174(Google的一个IP) 却能正常通达。同样，
ssh user@yourserver.com失败，但
ssh user@192.168.1.100成功，这都强烈指向DNS问题。
再者，软件包管理器无法更新或安装软件。当你运行
sudo apt update或
sudo yum update时，如果遇到类似“无法解析域名”的错误，导致无法连接到软件源服务器，那也是DNS解析失败的典型症状。因为这些工具在连接到仓库之前，需要先解析仓库的域名。
Teleporthq
一体化AI网站生成器，能够快速设计和部署静态网站
182
查看详情
还有，邮件客户端、即时通讯工具等依赖域名服务的应用无法正常工作。它们在连接服务器时也需要进行DNS查询，一旦失败，就会表现为无法登录、无法发送/接收消息等。
最后，系统日志中出现与名称解析相关的错误。通过
journalctl -f实时查看日志，或者查看
/var/log/syslog、
/var/log/messages等文件，可能会发现
Name resolution failed、
Could not resolve host或
Temporary failure in name resolution等明确的错误信息。这些日志是深层诊断的重要依据。 如何区分是本地配置问题还是上游DNS服务器问题？
区分DNS解析失败是本地配置问题还是上游DNS服务器问题，是我在排查时的一个核心思路。这就像医生诊断病症，要先确定是病人自身器官有问题，还是外部环境出了状况。
我的方法是进行“隔离测试”。
判断是否是本地配置问题：
如果以下情况发生，那么问题很可能出在你的本地系统配置上：
-
/etc/resolv.conf
文件异常： 比如文件是空的，或者nameserver
IP地址是错误的、不可达的（例如，指向了你局域网内根本不存在的IP），或者指向了一个内网DNS服务器，而这个服务器本身又没有正确配置。 -
网络接口或路由问题： 你的网卡可能没有正确获取IP地址，或者默认网关配置错误，导致你的机器根本无法将DNS请求发送出去。
ip a
和ip route
的输出会帮你判断。如果ping <nameserver_ip>
都失败了，那肯定不是DNS服务器的问题，而是你机器的网络路径问题。 -
本地防火墙阻挡： 你的Linux系统上运行的防火墙（如
firewalld
或ufw
）可能意外地阻止了UDP 53端口的对外连接。这是比较少见，但确实会发生。 -
nsswitch.conf
配置不当： 如果/etc/nsswitch.conf
中的hosts:
这一行没有包含dns
，或者files
在dns
之前有错误的条目，系统可能就不会去查询DNS。 -
systemd-resolved
或其他本地DNS缓存服务故障： 如果你的系统使用了systemd-resolved
或dnsmasq
等本地DNS缓存服务，而它们本身出现了故障或配置错误，即使上游DNS服务器正常，本地解析也可能失败。这时，resolvectl status
或sudo systemctl status dnsmasq
会显示异常。
判断是否是上游DNS服务器问题：
如果以下情况发生，那么问题更可能出在你配置的上游DNS服务器上：
-
dig @<your_configured_nameserver_ip> example.com
失败，但dig @8.8.8.8 example.com
成功： 这是最直接的证据。这意味着你的系统能够正常发送DNS请求，并且公共DNS服务器能够响应，但你/etc/resolv.conf
中配置的DNS服务器却无法响应或返回错误。 -
ping <your_configured_nameserver_ip>
成功，但dig @<your_configured_nameserver_ip> example.com
失败： 这表明你的机器可以到达DNS服务器，但服务器本身没有提供正确的DNS服务（可能宕机、过载或配置错误）。 - 所有客户端都无法解析： 如果你局域网内的所有设备（包括Windows、macOS等）都无法解析域名，并且它们都使用同一个DNS服务器（比如你的路由器IP），那么很可能是路由器提供的DNS服务出了问题，或者路由器转发的上游DNS服务器出了问题。
简而言之，我的诊断流程是：先确保自己的机器能“说话”（网络通畅，本地配置正确），再看“听众”（上游DNS服务器）是否能“回应”。如果我的机器用公共DNS能解析，但用自己配置的DNS不能，那八成是自己配置的DNS服务器有问题。
解决DNS解析问题时，有哪些高级技巧或工具可以利用？在处理那些棘手的DNS解析问题时，除了常规的
dig和
ping，我还有一些更深入的技巧和工具可以利用，它们能帮助我看到表面之下发生的事情。
1.
tcpdump或
Wireshark抓包分析： 这是我最喜欢也是最强大的工具之一。如果我怀疑DNS请求根本没有发出，或者发出了但没有收到响应，或者收到了错误的响应，
tcpdump能给我答案。
sudo tcpdump -i any port 53 -nn
这个命令会监听所有网络接口上所有UDP/TCP 53端口的流量。当我尝试
ping google.com时，我会看到我的机器是否发出了DNS查询请求（通常是UDP），以及是否有来自DNS服务器的响应。如果我看到查询请求发出去了，但长时间没有响应，或者响应是
NXDOMAIN（域名不存在），这就能提供非常具体的线索。
Wireshark提供了更友好的图形界面和更强大的协议分析能力。
2.
strace追踪系统调用： 当一个程序（比如
curl或
wget）解析域名失败时，我可能会用
strace来看看它在底层做了什么。
strace -e trace=network,file -f <command_that_fails>
strace可以显示程序打开了哪些文件（比如
/etc/resolv.conf、
/etc/nsswitch.conf），以及进行了哪些网络相关的系统调用（如
socket、
connect、
sendto、
recvfrom）。这能帮助我确认程序是否尝试读取了正确的配置文件，以及是否尝试向正确的IP地址发送了DNS请求。
3.
getent hosts <hostname>验证NSS配置：
getent命令会按照
/etc/nsswitch.conf中定义的顺序，查询各种数据库。
getent hosts example.com
如果
getent hosts无法解析，而
dig却可以，这通常意味着
/etc/nsswitch.conf配置有问题，或者本地的
nscd(Name Service Cache Daemon) 缓存服务有问题。
4. 临时修改
/etc/resolv.conf进行快速测试： 如果我怀疑当前配置的DNS服务器有问题，我不会立即去修改NetworkManager的配置，而是会临时覆盖
/etc/resolv.conf来测试公共DNS。
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf echo "nameserver 1.1.1.1" | sudo tee -a /etc/resolv.conf
然后尝试解析。如果成功了，我就知道问题出在原来的DNS服务器上。测试完毕后，通常重启网络服务（如
sudo systemctl restart NetworkManager）就能恢复到之前的配置，或者手动删除这些临时添加的行。
5. 检查
/etc/hosts文件： 这是一个非常基础但又容易被忽视的地方。
/etc/hosts文件拥有最高的解析优先级。如果某个域名在这里被错误地指向了某个IP，或者被指向了
127.0.0.1，那么即使你的DNS配置完全正确，该域名也无法被正确解析。
cat /etc/hosts
6.
host命令： 虽然
dig更强大，但
host命令在某些场景下更简洁，尤其适合快速查询一个域名的A记录。
host example.com host -t MX example.com # 查询邮件交换记录
这些工具和技巧，让我能更深入地剖析DNS解析失败的根源，而不是停留在表面的猜测。它们帮助我从网络底层、系统配置和应用行为等多个维度，构建出问题发生的全貌。
以上就是Linux怎么诊断DNS解析失败的详细内容，更多请关注知识资源分享宝库其它相关文章！
相关标签： linux go windows 防火墙 浏览器 路由器 端口 工具 mac curl ai switch 路由 cURL 接口 var windows macos 数据库 udp wireshark tcpdump linux ssh 大家都在看： 如何在Linux命令行中使用alias命令提高效率 如何在Linux中排查网络拥塞？ Linux命令行中tar命令的详细教程 Linux命令行中的管道与重定向详解 Linux tc命令流量控制使用方法
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。