VPS 能 Ping 通公网 IP，SSH 也可以正常登录，但执行 apt update、curl 或程序访问域名时却提示 Temporary failure in name resolution。这类故障看起来像服务器断网，实际经常只是 DNS 解析链路出了问题。
临时把 DNS 改成一个公共地址有时能恢复，但系统重启、DHCP 更新或网络服务重载后又失效。更稳妥的做法是先区分网络不通、DNS 服务器不可达、resolv.conf 配置错误，还是 systemd-resolved 自身异常。
下面就按从网络到解析器的顺序，讲清 VPS 域名解析失败时应该怎么查。
一、先确认是不是DNS问题
先测试公网 IP 连通性：
ping -c 4 1.1.1.1再测试域名：
ping -c 4 example.com如果 IP 能通而域名解析失败，问题大概率在 DNS。若 IP 也不通，应先检查默认路由、网卡状态、云平台网络和防火墙，别在 DNS 配置上绕圈。
有些服务器禁用 ICMP，Ping 不通不一定代表网络断开。还可以用 curl 访问一个明确的 IP，或检查 ip route 中是否存在默认路由。
二、查看系统实际使用的解析器
先读取 /etc/resolv.conf：
cat /etc/resolv.conf
ls -l /etc/resolv.conf文件里可能直接列出 DNS 服务器，也可能是指向 systemd-resolved 生成文件的符号链接。看到 127.0.0.53 不代表 DNS 填错，它通常是本机的 systemd-resolved stub resolver。
使用 systemd-resolved 的系统可以执行：
resolvectl status重点查看网卡对应的 DNS Servers、Current DNS Server、协议状态和默认路由。不要只看 /etc/resolv.conf 一行 nameserver，就忽略背后真正管理它的网络服务。
三、直接测试DNS服务器
安装了 dig 后，可以先按系统默认配置查询：
dig example.com再指定 DNS 服务器对比：
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com默认查询失败、指定服务器成功，说明本机默认解析配置或上游 DNS 有问题。所有指定查询都超时，则需要检查 UDP/TCP 53 端口、云网络限制和服务器到外部 DNS 的路由。
如果只有某一个域名失败，可能是域名本身的权威 DNS、DNSSEC 或记录配置异常，而不是 VPS 的全局解析故障。用多个域名交叉测试能避免误判。
四、systemd-resolved异常怎么处理
先看服务状态与日志：
systemctl status systemd-resolved --no-pager -l
journalctl -u systemd-resolved -b --no-pager服务未启动时可以尝试启用并重启，但先确认发行版是否本来就使用它。某些系统由 NetworkManager、netplan、dhclient 或云初始化程序直接管理 DNS，强行切换解析器可能造成新的冲突。
systemd-resolved 正常但缓存异常时，可以执行：
sudo resolvectl flush-caches
sudo systemctl restart systemd-resolved重启后再次查看 resolvectl status，确认上游 DNS 已正确绑定到联网网卡。
五、resolv.conf为什么会反复被覆盖
手动编辑 /etc/resolv.conf 后暂时恢复，重启又失效，说明它由其他组件自动生成。常见管理者包括 systemd-resolved、NetworkManager、netplan、DHCP 客户端和云平台初始化程序。
| 文件或工具 | 常见管理方式 | 正确修改位置 |
|---|---|---|
| resolvectl | systemd-resolved | resolved.conf或网络配置 |
| nmcli | NetworkManager | 连接配置文件 |
| netplan | Ubuntu网络配置 | /etc/netplan/*.yaml |
| dhclient | DHCP客户端 | DHCP配置或云网络 |
不要用不可变属性强行锁住 resolv.conf。这会让网络服务、DHCP 和运维工具无法正常更新配置，服务器迁移或网卡变化后更难排查。
六、防火墙和容器也会影响解析
DNS 主要使用 UDP 53，但响应较大、区域传输或部分回退场景也会使用 TCP 53。出站防火墙过严时，两种协议都要检查。
Docker 容器解析失败而宿主机正常，问题可能在 Docker 内置 DNS、容器网络或 Compose 的 DNS 设置。先在宿主机和容器内分别测试，不要直接改宿主机全局解析器。
如果服务器使用代理、VPN 或多网卡，不同接口可能下发不同 DNS 和路由域。resolvectl status 能看到按接口分配的解析设置，这比简单覆盖一个公共 DNS 更可靠。
七、公共DNS不是万能修复
公共 DNS 可以用于对比测试，但某些云平台提供的内部域名、私有网络和托管服务必须使用平台 DNS。把所有解析强制改成公共 DNS 后，公网域名恢复，内网服务反而可能无法访问。
跨地区部署时，还要考虑 DNS 可达性和稳定性。选择节点时可对比 萤光云 和 LightNode 等平台的网络与节点情况，但单台 VPS 的解析配置仍应以系统和云网络实际下发为准。
长期方案应写在真正的网络管理配置中，并准备至少两个可靠上游 DNS。修改后重启网络服务或服务器进行验证，确认设置不会再次被覆盖。
八、我的排查顺序
我会先测试 IP 和域名，确认故障边界；再查看路由、resolv.conf 和 resolvectl status；随后用 dig 对比默认 DNS 与指定 DNS，最后查管理配置和防火墙。
这种顺序能避免把网络故障误当 DNS，也能避免临时修改覆盖现场。先弄清谁在管理解析配置，再决定从哪个文件改，才不会一重启就失效。
常见问题
问：把DNS改成8.8.8.8就一定能解决吗？
答：不一定，外部DNS可能不可达，私有域名也可能依赖云平台提供的DNS。
问：resolv.conf里的127.0.0.53是错误配置吗？
答：不一定，它通常是 systemd-resolved 的本地 stub 地址，应结合服务状态检查。
问：为什么宿主机能解析，Docker容器不能？
答：可能是容器内置DNS、Docker网络、出站防火墙或Compose配置问题。
问：DNS查询只需要开放UDP 53吗？
答：不够稳妥，部分场景会回退到TCP 53，两种协议都应按需允许。
问：手动修改resolv.conf后为什么重启失效？
答：它可能由systemd-resolved、NetworkManager、netplan或DHCP自动生成。
温馨提示
域名解析失败时，不要第一步就删除符号链接或锁死 /etc/resolv.conf。先确认公网 IP 是否可达，再找出当前系统由谁管理 DNS。
稳定的修复应该能经受网络重载和服务器重启。临时 nameserver 只适合验证方向，最终配置必须落到真实的网络管理组件中，同时兼顾公网和私有域名解析。
