使用Linux服务器时，如果安装软件、下载文件或访问接口出现以下提示，通常需要检查域名解析：
Temporary failure in name resolution
Could not resolve host排查时，应先区分本机解析异常、DNS服务器不可达和域名记录异常，再决定是否修改配置。
本文的通用检查适用于常见Linux系统；临时修改部分适用于使用systemd-resolved的环境，永久配置部分以Netplan为例。
1. 检查当前DNS配置
先通过系统名称解析接口查询域名：
getent ahosts example.com将example.com替换为实际故障域名。正常情况下会显示地址；没有输出时，需要继续检查。
该命令也可能读取/etc/hosts等来源，返回地址不一定代表外部DNS查询成功。
查看当前解析配置及文件指向：
ls -l /etc/resolv.conf
cat /etc/resolv.conf如果系统使用systemd-resolved，再执行：
resolvectl status针对某张网卡查看：
resolvectl status ens18其中ens18需要替换为实际网卡名称，可通过以下命令确认：
ip -br addr重点检查DNS服务器地址、查询使用的网卡，以及是否存在VPN或内网域名的专用解析配置。
看到nameserver 127.0.0.53不代表配置错误。 它通常是systemd-resolved的本地解析入口，实际使用的上游DNS需要通过resolvectl status查看。
如果没有resolvectl命令，不要直接认定系统异常，应先确认DNS由哪个网络管理工具负责。
2. 对比系统DNS与指定DNS的结果
系统已安装dig时，可以对比默认解析和指定DNS的结果：
dig example.com A +time=2 +tries=1
dig @1.1.1.1 example.com A +time=2 +tries=1这里的1.1.1.1仅作示例，应选择服务器所在网络允许访问、且适合当前业务的DNS服务器。内网域名应使用对应的内部DNS。
常见结果如下：
| 查询结果 | 排查方向 |
|---|---|
| 默认查询失败，指定DNS成功 | 检查本地解析服务、当前上游DNS及查询路由 |
| 两种查询都超时 | 检查到DNS服务器的网络、访问规则和服务状态 |
NXDOMAIN |
当前DNS认为查询名称不存在，检查拼写、记录及查询环境 |
SERVFAIL |
检查上游解析、权威DNS或DNSSEC等问题 |
NOERROR但没有目标记录 |
查询已获得应答，但不一定存在所需类型的记录 |
如果怀疑UDP查询链路异常，可以对比TCP查询：
dig @1.1.1.1 example.com A +tcp +time=2 +tries=1普通DNS查询会使用UDP或TCP的53端口，需要检查出站通信及返回流量。作为普通DNS客户端，无需向公网开放本机的53端口。
没有dig时，使用systemd-resolved的系统可以先执行：
resolvectl query example.comDNS已经失效时，在线安装排查工具也可能失败，应先利用系统现有工具恢复解析。
3. 临时修改DNS验证问题
确认systemd-resolved正在运行：
systemctl is-active systemd-resolved如果当前故障来自上游DNS，并且该网卡用于普通公网解析，可以先记录原配置，再临时修改：
sudo resolvectl dns ens18 1.1.1.1 9.9.9.9
sudo resolvectl flush-caches
resolvectl query example.com
getent ahosts example.com请替换网卡名称和DNS地址，并确认所选DNS能够解析业务使用的域名。
如果修改后恢复，说明原DNS配置或相关访问路径值得继续检查，但仍需结合多次测试判断。
这类运行时设置不能代替永久配置。 网卡重建、网络管理服务重新配置或服务器重启后，设置可能被覆盖。
多网卡、VPN和内网业务环境还涉及DNS查询路由，不宜直接把所有域名都交给公共DNS处理。
4. 将修复写入永久配置
永久DNS应修改到实际负责网络配置的工具中。
| 网络管理方式 | 配置位置或方式 |
|---|---|
| Netplan | 修改现有/etc/netplan/配置 |
| NetworkManager | 修改对应的连接配置 |
| 直接使用systemd-networkd | 修改对应的.network配置 |
| ifupdown、resolvconf等 | 按当前组件的配置方式处理 |
不要同时修改多套配置，以免相互覆盖。
以下以Netplan为例。先查看现有文件并备份：
ls -l /etc/netplan/
sudo cp -a /etc/netplan "/root/netplan-backup-$(date +%Y%m%d-%H%M%S)"在实际网卡的配置块内，添加或修改nameservers：
nameservers:
addresses:
- 1.1.1.1
- 9.9.9.9以上只是需要合并的字段，不是完整配置文件。 应保留原有IP、网关、路由、DHCP及其他网卡配置，按现有层级调整缩进。
如果使用networkd后端，并且故障DNS由DHCPv4下发，可在同一网卡配置块内合并：
dhcp4-overrides:
use-dns: false若同时启用了DHCPv4和DHCPv6，networkd后端要求两组DHCP覆盖配置的键和值保持一致；IPv6路由通告也可能提供DNS，需要一并核对。
修改后先检查配置，再试用：
sudo netplan generate
sudo netplan try --timeout 120保留当前SSH连接，通过第二个SSH会话检查连接和域名解析。确认正常后，再回到原窗口按回车接受配置。
如果超时或取消，应确认运行状态是否已恢复，并检查磁盘上的配置是否正确，不要未经核对直接重启。
如果配置文件标明由cloud-init等工具生成，还需要确认其配置来源，避免后续初始化或重建时覆盖修改。
5. 宿主机正常时，单独检查容器
宿主机可以解析域名，但Docker容器中的程序仍然失败时，应进入容器环境检查：
docker exec app cat /etc/resolv.conf
docker exec app getent ahosts example.com将app替换为实际容器名称。精简镜像可能没有getent，可使用镜像已有的nslookup等工具。
容器内看到127.0.0.11通常是正常现象，这是Docker自定义网络使用的内置DNS入口。
需要检查：
-
容器是否存在单独指定的DNS配置。
-
容器能否访问所配置的DNS服务器。
-
故障域名是否只能通过内部DNS解析。
-
应用是否使用自己的解析配置或缓存。
不要把宿主机上的127.0.0.53直接当作普通桥接容器的DNS地址；容器内的回环地址指向容器自身。
如果只有容器异常，应优先检查对应容器及网络，避免直接重启整个Docker服务。
6. 验证解析和业务访问
修复后，重新测试实际故障域名：
getent ahosts example.com使用systemd-resolved的系统还可以查看：
resolvectl status
resolvectl query example.com随后复测之前失败的操作，例如访问网站：
curl --noproxy '*' --connect-timeout 5 --max-time 15 \
-sS -D - -o /dev/null https://example.com/此命令直接访问目标，不经过环境变量配置的代理。业务如果必须使用代理，应按原访问方式另外验证。
域名能够解析，只能证明解析环节有所恢复。如果仍出现连接超时、证书错误或HTTP异常，需要继续检查相应环节。
7. 注意事项
-
修改前记录原DNS，并备份网络配置。
-
DNS地址应根据服务器所在网络和业务需求选择。
-
不要直接覆盖由系统自动管理的
/etc/resolv.conf。 -
不建议通过
chattr +i锁定该文件来阻止系统更新。 -
内网域名、VPN及多网卡环境需要保留正确的解析路由。
-
远程修改网络时，应保留可用的控制台恢复方式。
8. 常见问题
为什么改了DNS，重启后又变回去了？
通常是只修改了临时状态或自动生成文件。需要把设置写入实际负责网络配置的工具，并确认DHCP、cloud-init等是否会重新下发配置。
能Ping通IP，就一定是DNS故障吗？
不能。Ping只验证特定目标的ICMP通信，不能证明DNS端口、HTTPS或其他业务协议正常。应结合域名查询和实际业务测试判断。
只有一个域名失败，需要修改整台服务器的DNS吗？
不一定。先检查该域名的记录、权威DNS、DNSSEC及是否属于内部域名。更换整机DNS可能影响其他业务。
清空缓存后仍然失败怎么办？
清理缓存只能处理部分缓存问题。上游不可达、域名不存在或配置错误，需要修复对应原因。
如果排查后仍无法恢复，可向莱卡云技术支持提供实例信息、故障时间、操作系统版本、失败域名及脱敏后的查询结果，便于进一步定位网络或解析问题。