执行 apt update 时出现 Temporary failure resolving，说明APT拿到软件源域名后无法完成名称解析。它和仓库不存在、签名过期、404响应不是同一类问题。
先判断服务器能否访问公网IP，再检查系统解析链路。直接替换软件源地址无法修复DNS故障，反而可能把原有仓库配置改乱。
从完整APT错误中提取失败域名
重新运行更新并保留完整输出：
sudo apt update记录 Temporary failure resolving 后面的域名，再检查系统是否能解析：
getent ahosts deb.debian.org
getent ahosts archive.ubuntu.com只测试系统实际使用的软件源域名。若 getent 没有结果，继续查DNS；若解析正常但APT仍失败，再检查代理、IPv6路径或仓库服务状态。
先排除服务器本身断网
DNS依赖可用的网络路径。先查看地址和默认路由，再测试一个明确的公网IP：
ip -br address
ip route
ping -c 3 1.1.1.1公网IP也无法到达时，应先处理网卡、默认网关、安全组或上游网络。不能访问IP时，把公共DNS写进配置也不会产生有效查询。
检查resolv.conf由谁管理
不要直接覆盖文件，先看它是普通文件还是符号链接：
ls -l /etc/resolv.conf
cat /etc/resolv.conf使用systemd-resolved的系统，/etc/resolv.conf常指向 /run/systemd/resolve/stub-resolv.conf，并包含 127.0.0.53。云镜像也可能由NetworkManager、systemd-networkd或DHCP客户端写入。手工改动受管理文件，续租或重启后会被覆盖。
使用resolvectl检查每条链路
在启用了systemd-resolved的系统上执行：
systemctl status systemd-resolved --no-pager
resolvectl status
resolvectl query deb.debian.org重点查看当前接口是否获得DNS服务器、是否存在默认DNS路由，以及查询失败来自哪个接口。缓存只在证据指向旧记录时清理：
sudo resolvectl flush-caches清缓存不会补回缺失的DNS服务器，也不能解决默认路由错误。
按网络管理器写入持久DNS
确认上游提供的DNS地址后，应通过实际网络管理器写入。systemd-resolved可以在 /etc/systemd/resolved.conf.d/ 中使用drop-in，例如：
[Resolve]
DNS=1.1.1.1 9.9.9.9
FallbackDNS=8.8.8.8保存后重启解析服务并复查状态。使用NetworkManager、Netplan或systemd-networkd的主机，应在对应连接配置中设置DNS。不要用 chattr +i /etc/resolv.conf 阻止系统更新，这会破坏DHCP和网络管理器的正常行为。
排查代理、容器和IPv6差异
APT代理配置、容器独立DNS和失效IPv6路径也会制造相似现象。检查APT配置片段和环境变量：
apt-config dump | grep -i proxy
env | grep -iE 'http_proxy|https_proxy|no_proxy'主机解析正常、容器内失败时，应检查容器运行时的DNS配置，不要只改宿主机缓存。需要在独立环境复现解析链路时，可以使用 萤光云 或 LightNode 建立测试机，避免在生产服务器反复切换DNS。
修复后怎样验收
先验证系统解析，再刷新软件索引：
getent ahosts deb.debian.org
sudo apt update验收标准是软件源域名稳定解析、APT完整获取索引且不再出现解析错误，服务器重启或DHCP续租后DNS配置仍有效。
FAQ
把DNS改成公共地址就一定能解决吗？ 不一定。路由中断、防火墙阻断53端口、云平台内部域名、代理和IPv6问题都可能继续导致失败，应先确认查询链路。
为什么手工修改resolv.conf后很快又变回去了？ 该文件多半由NetworkManager、systemd-resolved、Netplan或DHCP客户端管理，应把配置写入对应管理层。
温馨提示
修改前保存 /etc/resolv.conf 的链接目标和 resolvectl status 输出。先确认网络可达，再修DNS，最后才处理APT仓库本身。
