简介：这份技术方案文档面向使用 Ubuntu 18.04 的开发者与运维人员，针对执行 sudo apt update 时频繁出现「无法解析域名」报错的问题，提供经过实测验证的排查与修复思路。内容覆盖 cn.archive.ubuntu.com、ppa.launchpad.net、packages.microsoft.com、mirrors.ustc.edu.cn 等多个源地址解析失败的典型场景，帮助读者定位 DNS 配置、网络代理或源列表异常等根因。资源包共 1 个 docx 文件，约 114KB，以图文结合的方式记录问题现象与解决过程，便于对照自身环境快速复现与验证。目前已有 4325 人学习下载，适合刚接触 Linux 或需要快速恢复 apt 正常使用的读者参考，可从中获取完整的排错路径与配置调整要点，减少反复试错的时间成本。

1. Ubuntu 18.04 上 sudo apt update 报“无法解析域名”：先别急着重装系统

一台还能正常开机、能进桌面的 Ubuntu 18.04，执行sudo apt update却甩出一串Temporary failure in name resolution或者Could not resolve 'archive.ubuntu.com'，这种场景我见过太多次。机器没坏，网卡灯也亮着，浏览器甚至能打开网页，偏偏 apt 说解析不了域名。很多人第一反应是系统坏了，准备重装，其实绝大多数情况下只是 DNS 解析链路在某个环节断了。这个标题要解决的就是这件事：让sudo apt update重新能解析域名，把软件源正常拉下来。适合正在用 Ubuntu 18.04 做开发、部署 labelimg、装 ROS 或者 rosdep 的人，也适合那些系统放了一段时间没动、突然要更新却发现 apt 罢工的运维。下面按“先判断故障层级，再逐层修”的顺序讲，每一步都能直接抄。

2. 先分清是 DNS 挂了还是网络根本没通：三层排查法

apt update报域名解析失败，字面意思是 DNS 查询没结果，但根因可能在三层里的任意一层：物理/链路层没通、IP 层能通但 DNS 服务器不可达、DNS 配置本身错了。不先分层，直接改/etc/resolv.conf，很可能改完还是报错，白折腾。

2.1 用 ping 和 nslookup 把故障锁到具体一层

先确认网卡有没有拿到 IP，再看能不能通外网 IP，最后才看 DNS。三条命令按顺序跑：

# 1. 看网卡状态和 IP，确认接口是 UP 且有地址 ip addr show # 2. 直接 ping 一个公网 IP，绕过 DNS，测 IP 层通不通 ping -c 3 223.5.5.5 # 3. 用 nslookup 显式指定 DNS 服务器查域名，测 DNS 层 nslookup archive.ubuntu.com 223.5.5.5

逻辑说明：第 1 条如果看到state DOWN或者没有inet地址，问题在网卡或 DHCP，跟 DNS 无关。第 2 条如果 ping IP 都不通，说明路由或网关有问题，改 DNS 没用。第 3 条如果指定了能用的 DNS 服务器还是查不到，才轮到怀疑本机 DNS 配置。参数上-c 3是发 3 个包就停，避免卡住；223.5.5.5只是拿来当参照的公共 DNS，你也可以换成网关地址试。

2.2 看 /etc/resolv.conf 到底写了什么

Ubuntu 18.04 默认用systemd-resolved管理 DNS，/etc/resolv.conf往往是个指向../run/systemd/resolve/stub-resolv.conf的软链接，里面可能只有127.0.0.53。这个 stub 地址本身没错，但如果systemd-resolved服务没跑起来，或者上游 DNS 没配，解析就会失败。

# 看 resolv.conf 是不是软链接，指向哪里 ls -l /etc/resolv.conf # 看 systemd-resolved 的运行状态 systemctl status systemd-resolved # 看当前实际生效的 DNS 服务器 systemd-resolve --status | grep -A2 "DNS Servers"

逻辑说明：如果systemd-resolved是inactive (dead)，那127.0.0.53这个 stub 就没人应答，apt 自然解析不了。systemd-resolve --status会列出每个网卡实际拿到的 DNS，比直接看resolv.conf更准。参数上grep -A2是把匹配行和后面两行一起显示，方便看 DNS 列表。

2.3 判断是全局 DNS 坏还是某个源站解析不了

有时候archive.ubuntu.com解析不了，但www.baidu.com能解析，这说明 DNS 服务器本身在工作，只是某些域名被污染或超时。反过来如果所有域名都解析不了，那就是本机 DNS 配置或网络出口的问题。

# 分别测两个不同域名，对比结果 nslookup www.baidu.com nslookup archive.ubuntu.com # 看 apt 具体报的是哪个域名解析失败 sudo apt update 2>&1 | grep -i "resolve\|resolve"

逻辑说明：如果只有archive.ubuntu.com失败，可以考虑换软件源镜像；如果全都失败，就回到 2.1 和 2.2 去修 DNS 配置。2>&1是把标准错误也重定向到标准输出，这样 grep 才能抓到 apt 的报错。

3. 三种能直接抄的修复路径：从临时改到永久生效

排查完知道问题在哪一层，接下来就是修。修复方案按“改动范围从小到大”排：先试临时改 DNS 验证，再改 systemd-resolved 配置做持久化，最后处理网卡配置文件。三条路径不是互斥的，通常走完第二条就能解决。

3.1 临时改 /etc/resolv.conf 验证 DNS 是否可用

这是最快的验证手段，但注意：在 Ubuntu 18.04 上直接编辑/etc/resolv.conf可能重启后被覆盖，所以只用来确认“换个 DNS 能不能好”。

# 备份原文件（如果是软链接，先删链接再建实体文件） sudo cp /etc/resolv.conf /etc/resolv.conf.bak sudo rm /etc/resolv.conf # 写入两个可用的 DNS 服务器 sudo tee /etc/resolv.conf <<'EOF' nameserver 223.5.5.5 nameserver 119.29.29.29 EOF # 立刻测试解析 nslookup archive.ubuntu.com

逻辑说明：tee配合 heredoc 可以一次性写入多行，避免用echo反复追加。223.5.5.5和119.29.29.29是两个国内常用的公共 DNS，响应快。如果这一步之后nslookup能出结果，说明问题就是 DNS 服务器不可达，接下来要做的是让这个配置持久化，而不是每次重启手动改。参数上nameserver最多写 3 个，系统按顺序尝试。

3.2 改 systemd-resolved 配置做持久化

Ubuntu 18.04 的持久化 DNS 配置在/etc/systemd/resolved.conf，改完重启服务，systemd-resolved会把配置同步到 stub 解析器。

# 编辑 resolved.conf，取消 DNS 行的注释并填入服务器 sudo sed -i 's/^#DNS=.*/DNS=223.5.5.5 119.29.29.29/' /etc/systemd/resolved.conf # 如果上面没匹配到，手动确认这一行存在 grep "^DNS=" /etc/systemd/resolved.conf # 重启解析服务 sudo systemctl restart systemd-resolved # 确认生效 systemd-resolve --status | grep "DNS Servers"

逻辑说明：sed -i是原地修改文件，s/^#DNS=.*/DNS=.../把被注释的 DNS 行替换成实际配置。如果文件里根本没有#DNS=这一行，sed不会报错但也不会改，所以要用grep确认。重启服务后，systemd-resolve --status里应该能看到你填的 DNS。注意：有些机器上/etc/resolv.conf是手动创建的实体文件，systemd-resolved不会覆盖它，这时要确保resolv.conf里写的是nameserver 127.0.0.53，让请求走 stub。

3.3 处理 netplan 或 NetworkManager 下发的 DNS

如果 DNS 是网卡配置里下发的，改resolved.conf可能被覆盖。Ubuntu 18.04 桌面版用 NetworkManager，服务器版常用 netplan。先确认用的是哪个。

# 看 netplan 配置文件 ls /etc/netplan/ cat /etc/netplan/*.yaml # 看 NetworkManager 连接里有没有忽略 DNS nmcli dev show | grep DNS

逻辑说明：netplan 的 YAML 里如果写了nameservers: addresses: [...]，那 DNS 由 netplan 控制，改resolved.conf会被覆盖。这时应该改 YAML 再sudo netplan apply。NetworkManager 下可以用nmcli con mod <连接名> ipv4.dns "223.5.5.5"再nmcli con up <连接名>。参数上<连接名>用nmcli con show查。这一步的关键是：不要同时改多个地方，否则排查时不知道哪个生效。

4. 避坑与排查：apt update 解析失败的 5 个血泪现场

修 DNS 这件事，翻车往往不在命令本身，而在环境细节。下面 5 条是我自己踩过或者帮人排查时反复遇到的，每条按现象、原因、解决写。

4.1 现象：改了 resolv.conf 重启后又失效

原因：Ubuntu 18.04 的/etc/resolv.conf如果是软链接到systemd-resolved的 stub 文件，手动编辑会被服务重启覆盖；如果是实体文件，又可能被 NetworkManager 或 netplan 重写。解决：先ls -l /etc/resolv.conf确认是链接还是实体。是链接就走 3.2 改resolved.conf；是实体且被覆盖，就在 netplan 或 NetworkManager 里配 DNS，别直接改文件。

4.2 现象：ping IP 通，nslookup 指定 DNS 也通，但 apt 就是解析失败

原因：apt 可能走了代理配置，或者/etc/apt/apt.conf.d/里有残留的代理设置，导致请求发到了不可达的地址。解决：检查env | grep -i proxy和grep -ri proxy /etc/apt/apt.conf.d/，把不需要的代理行注释掉。另外确认/etc/hosts里没有把archive.ubuntu.com指到错误 IP。

4.3 现象：只有 archive.ubuntu.com 解析不了，其他域名正常

原因：默认的archive.ubuntu.com在国内访问不稳定，DNS 查询可能超时或被返回异常结果。解决：换国内镜像源，编辑/etc/apt/sources.list，把archive.ubuntu.com和security.ubuntu.com替换成mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn。改完先sudo apt update验证。注意备份原文件。

4.4 现象：systemd-resolved 服务起不来，报端口占用

原因：有些机器上装了 dnsmasq 或其他解析服务，占用了 53 端口，systemd-resolved的 stub 监听失败。解决：sudo ss -ulnp | grep :53看谁占着，如果是 dnsmasq 且不需要，sudo systemctl stop dnsmasq && sudo systemctl disable dnsmasq，再重启systemd-resolved。如果两个都需要，就改其中一个的监听端口，但更简单的做法是统一用一个。

4.5 现象：虚拟机里 apt update 解析失败，宿主机正常

原因：虚拟机网络模式是 NAT，但虚拟网卡的 DNS 没正确下发，或者虚拟机时间偏差太大导致 DNS 查询被拒。解决：先date看时间，偏差超过几分钟就sudo ntpdate ntp.aliyun.com同步。然后确认虚拟机网络是 NAT 还是桥接，NAT 模式下 DNS 通常由虚拟化平台转发，检查平台网络设置里有没有禁用 DNS。桥接模式则和宿主机同网段，DNS 应该一致。

5. 让 apt 长期稳定解析：一个我固定用的检查脚本

修好一次不代表以后不出问题。系统放几个月、换了网络环境、装了新服务，DNS 都可能再出幺蛾子。我习惯在机器上放一个自检脚本，每次 apt 报解析错误先跑它，30 秒定位到层。

#!/bin/bash # apt-dns-check.sh：快速定位 apt 域名解析故障层级 echo "=== 1. 网卡与 IP ===" ip -brief addr show | grep -v "DOWN" echo "=== 2. 网关连通性 ===" GW=$(ip route | awk '/default/ {print $3; exit}') ping -c 2 -W 2 "$GW" >/dev/null 2>&1 && echo "网关 $GW 可达" || echo "网关 $GW 不可达" echo "=== 3. 公网 IP 连通性 ===" ping -c 2 -W 2 223.5.5.5 >/dev/null 2>&1 && echo "公网 IP 可达" || echo "公网 IP 不可达" echo "=== 4. DNS 解析测试 ===" for d in archive.ubuntu.com www.baidu.com; do if nslookup "$d" >/dev/null 2>&1; then echo "$d 解析正常" else echo "$d 解析失败" fi done echo "=== 5. 当前 DNS 服务器 ===" systemd-resolve --status 2>/dev/null | grep "DNS Servers" || cat /etc/resolv.conf | grep nameserver

逻辑说明：脚本按 2.1 的三层顺序输出，每层给一个明确结论。ip -brief addr是简洁模式，过滤掉 DOWN 的接口。ip route取默认网关，awk '/default/ {print $3; exit}'只取第一个默认路由的网关地址。ping -W 2是超时 2 秒，避免卡住。DNS 测试用nslookup的退出码判断，成功返回 0。最后一步优先用systemd-resolve --status，如果命令不存在（比如系统没装 systemd-resolved）就回退到读resolv.conf。

参数上，-c 2是发 2 个包，-W 2是每个包等 2 秒，这两个值在排查时够用又不拖时间。如果你在容器里跑，systemd-resolve可能不可用，脚本会自动走resolv.conf分支。

这个脚本我一般放在/usr/local/bin/下，chmod +x之后随时能跑。它不修问题，只告诉你问题在哪一层，修的时候心里有底。另外提醒一句：如果apt update报的是Could not resolve但nslookup手动查同一个域名却正常，优先怀疑 apt 的代理配置和/etc/hosts，这两个地方最容易藏“后悔药”——改的时候忘了备份，出问题想回滚都难。我现在的习惯是动任何网络配置文件之前先cp一份带日期的备份，这个习惯帮我省过至少三次重装系统的时间。希望帮到你。

本文还有配套的精品资源，点击获取