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或企业内网路径 | 恢复组织指定解析器与网络 |
恢复后如何验收
- 用
getent hosts验证系统解析器，而不只测试单个工具。 - 分别查询一个已知公网域名和业务域名，确认不是缓存造成的假恢复。
- 若涉及容器，在宿主机和容器内各验证一次。
- 重启网络服务或实例前先确认远程管理通道与回滚方案，避免失联。
- 检查一段时间内的日志，确认没有持续超时或频繁切换上游。
结论
Temporary failure in name resolution 是解析失败信号，不是一个固定答案。先确认IP网络，再沿 /etc/resolv.conf、本地解析服务、上游DNS、防火墙和容器网络逐层排查。把修复放在真正管理网络配置的组件里，才能避免重启后故障复发。
