### [VPS提示Temporary failure in name resolution怎么办？按解析链逐层排查](https://www.jiyueip.com/article/13500)

**Published:** 2026-07-30T08:08:46

**Author:** 斑斓助理

**Excerpt:** VPS执行apt、curl或ping域名时出现Temporary failure in name resolution，说明域名解析链路失败。本文从网络连通、resolv.conf、systemd-resolved、容器DNS与防火墙逐层定位。

VPS执行 `apt update`、`curl` 或 `ping` 域名时出现 `Temporary failure in name resolution`，通常表示系统没有把域名解析为IP地址。它不等于网站一定宕机，也不应该一上来就把 `/etc/resolv.conf` 写死。

更稳妥的做法是把解析链拆成五层：基础网络、系统解析配置、本地解析服务、上游DNS和应用或容器环境。先用只读命令确认故障在哪一层，再做最小改动。

## 第一步：区分“没网络”还是“只解析失败”

```
ip route
ping -c 3 1.1.1.1
getent hosts example.com
```

如果默认路由不存在，或者连已知IP都不可达，问题在基础网络、网卡、路由或云平台侧，改DNS不会解决。若IP可达而 `getent hosts` 失败，才继续检查域名解析链。某些环境会禁用ICMP，因此还可使用已有业务允许的TCP连接做对照，避免仅凭Ping下结论。

## 第二步：查看系统实际使用的解析配置

```
ls -l /etc/resolv.conf
cat /etc/resolv.conf
```

重点看它是普通文件，还是指向systemd-resolved、NetworkManager或其他管理器生成文件的符号链接。若文件里没有有效的 `nameserver`，或指向一个并未运行的本地地址，解析就会失败。

不要直接删除符号链接并写入公共DNS作为长期方案。这样可能暂时恢复，但会绕过系统网络管理器，导致重启、DHCP续租、VPN切换或云初始化后再次冲突。

## 第三步：检查systemd-resolved状态

Ubuntu等系统常由systemd-resolved管理DNS，可先查看：

```
systemctl status systemd-resolved --no-pager
resolvectl status
resolvectl query example.com
journalctl -u systemd-resolved --since "-30 min" --no-pager
```

如果服务未运行、上游DNS为空或某个网卡绑定了错误DNS，应回到实际网络管理入口修正。系统使用NetworkManager、netplan、cloud-init还是静态网络文件，决定了配置应该写在哪里。先确认所有者，再修改，避免多个组件互相覆盖。

## 第四步：验证上游DNS与防火墙路径

配置里出现DNS地址不代表它一定可达。检查到上游的路由，并确认本机防火墙、云安全组和网络策略没有阻断DNS流量。传统DNS常使用UDP 53，响应较大或重试时也可能使用TCP 53；只放行一种传输可能产生偶发失败。

如果仅某个上游DNS异常，可在变更窗口内切换到云厂商推荐或组织批准的备用解析器，并记录变更前后的查询结果。企业内网域名可能只能由内部DNS解析，不能直接用公共DNS替代。

## 第五步：宿主机正常，容器里仍失败怎么办

Docker或其他容器有自己的网络命名空间与DNS转发配置。宿主机 `getent` 正常而容器失败时，分别检查容器的 `/etc/resolv.conf`、Docker内置DNS、网络驱动和容器到上游的出站规则。

```
docker exec <container> cat /etc/resolv.conf
docker exec <container> getent hosts example.com
docker network inspect <network>
```

不要把宿主机的 `127.0.0.1` 直接当作容器内可用DNS；在容器里，它通常指容器自身。若使用编排平台，还要核对平台DNS服务与网络策略。

## 常见现象与下一步

| 现象  | 更可能的位置 | 下一步 |
| --- | --- | --- |
| IP地址也不可达 | 网卡、路由或云网络 | 检查默认路由和平台状态 |
| 所有程序都无法解析 | 系统解析配置或上游DNS | 检查resolv.conf与解析服务 |
| 只有容器失败 | 容器DNS或转发链 | 对照宿主机和容器配置 |
| 偶发超时 | 上游不稳定、丢包、TCP 53受阻 | 记录时间并对照多个查询 |
| 只解析不了内部域名 | 分域DNS或企业内网路径 | 恢复组织指定解析器与网络 |

## 恢复后如何验收

1.  用 `getent hosts` 验证系统解析器，而不只测试单个工具。
2.  分别查询一个已知公网域名和业务域名，确认不是缓存造成的假恢复。
3.  若涉及容器，在宿主机和容器内各验证一次。
4.  重启网络服务或实例前先确认远程管理通道与回滚方案，避免失联。
5.  检查一段时间内的日志，确认没有持续超时或频繁切换上游。

## 结论

`Temporary failure in name resolution` 是解析失败信号，不是一个固定答案。先确认IP网络，再沿 `/etc/resolv.conf`、本地解析服务、上游DNS、防火墙和容器网络逐层排查。把修复放在真正管理网络配置的组件里，才能避免重启后故障复发。

**Tags:** Linux服务器, VPS, 网络故障排查

**Categories:** 行业洞察

---