DNS解析失败通常表现为域名无法访问但IP可通，常见原因包括/etc/resolv.conf配置错误、网络不通、上游DNS故障或防火墙拦截。首先检查/etc/resolv.conf中nameserver是否有效，使用dig @指定DNS测试解析能力；若公共DNS（如8.8.8.8）可解析而本地DNS不行，则问题在本地DNS或网络路径。通过ping、ip a、ip route确认网络连通性，确保网卡激活且路由正确。检查/etc/nsswitch.conf中hosts行是否包含dns，防止解析顺序错误。对于systemd-resolved系统，用resolvectl status查看DNS状态，必要时重启服务。排查防火墙是否阻止UDP 53端口，并查看journalctl日志获取线索。高级诊断可用tcpdump抓DNS流量，strace追踪程序调用，getent hosts验证NSS机制，临时修改resolv.conf测试公共DNS，或检查/etc/hosts是否存在错误映射。综合这些步骤可精准定位是本地配置还是上游问题。

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解析失败的典型症状。因为这些工具在连接到仓库之前，需要先解析仓库的域名。

Brev AI

Brev.ai：搭载Suno AI V3.5技术的免费AI音乐生成器

158

查看详情

还有，邮件客户端、即时通讯工具等依赖域名服务的应用无法正常工作。它们在连接服务器时也需要进行DNS查询，一旦失败，就会表现为无法登录、无法发送/接收消息等。

最后，系统日志中出现与名称解析相关的错误。通过

journalctl -f

实时查看日志，或者查看

/var/log/syslog

、

/var/log/messages

等文件，可能会发现

Name resolution failed

、

Could not resolve host

或

Temporary failure in name resolution

等明确的错误信息。这些日志是深层诊断的重要依据。

如何区分是本地配置问题还是上游DNS服务器问题？

区分DNS解析失败是本地配置问题还是上游DNS服务器问题，是我在排查时的一个核心思路。这就像医生诊断病症，要先确定是病人自身器官有问题，还是外部环境出了状况。

我的方法是进行“隔离测试”。

判断是否是本地配置问题：

如果以下情况发生，那么问题很可能出在你的本地系统配置上：

1. /etc/resolv.conf

   文件异常： 比如文件是空的，或者

   nameserver

   IP地址是错误的、不可达的（例如，指向了你局域网内根本不存在的IP），或者指向了一个内网DNS服务器，而这个服务器本身又没有正确配置。

2. 网络接口或路由问题： 你的网卡可能没有正确获取IP地址，或者默认网关配置错误，导致你的机器根本无法将DNS请求发送出去。

   ip a

   和

   ip route

   的输出会帮你判断。如果

   ping <nameserver_ip>

   都失败了，那肯定不是DNS服务器的问题，而是你机器的网络路径问题。

3. 本地防火墙阻挡： 你的Linux系统上运行的防火墙（如

   firewalld

   或

   ufw

   ）可能意外地阻止了UDP 53端口的对外连接。这是比较少见，但确实会发生。

4. nsswitch.conf

   配置不当： 如果

   /etc/nsswitch.conf

   中的

   hosts:

   这一行没有包含

   dns

   ，或者

   files

   在

   dns

   之前有错误的条目，系统可能就不会去查询DNS。

5. systemd-resolved

   或其他本地DNS缓存服务故障： 如果你的系统使用了

   systemd-resolved

   或

   dnsmasq

   等本地DNS缓存服务，而它们本身出现了故障或配置错误，即使上游DNS服务器正常，本地解析也可能失败。这时，

   resolvectl status

   或

   sudo systemctl status dnsmasq

   会显示异常。

判断是否是上游DNS服务器问题：

如果以下情况发生，那么问题更可能出在你配置的上游DNS服务器上：

1. dig @<your_configured_nameserver_ip> example.com

   失败，但

   dig @8.8.8.8 example.com

   成功： 这是最直接的证据。这意味着你的系统能够正常发送DNS请求，并且公共DNS服务器能够响应，但你

   /etc/resolv.conf

   中配置的DNS服务器却无法响应或返回错误。

2. ping <your_configured_nameserver_ip>

   成功，但

   dig @<your_configured_nameserver_ip> example.com

   失败： 这表明你的机器可以到达DNS服务器，但服务器本身没有提供正确的DNS服务（可能宕机、过载或配置错误）。

3. 所有客户端都无法解析： 如果你局域网内的所有设备（包括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解析失败的根源，而不是停留在表面的猜测。它们帮助我从网络底层、系统配置和应用行为等多个维度，构建出问题发生的全貌。