简介针对 Ubuntu 18.04 执行 sudo apt update 时频繁出现“无法解析域名”报错的问题这份 docx 技术方案文档给出了亲测有效的排查与修复思路适合因 DNS 异常、软件源不可达或代理配置错误而无法更新软件包的中级 Linux 用户及运维人员参考。资源包共含 1 个 docx 文件大小约 114KB内容以命令行为主线覆盖典型错误现象、原因定位、检查命令与修复步骤。已有 4325 人次学习浏览文中针对 cn.archive.ubuntu.com、ppa.launchpad.net 等多个官方与第三方软件源域名解析失败的情形逐一分析对 Ubuntu 18.04 软件源配置不当、DNS 失效等问题有直接指导作用。读者可参照文档顺序检查 DNS 与网络连接、调整软件源或切换可用镜像源从而让 apt update 恢复正常避免软件安装和系统升级受阻整体方案步骤清晰、可操作性强适合在真实环境中快速落地。1. sudo apt update 报“无法解析域名”先把这笔账算到 DNS 头上吃灰半年的 ThinkPad 重新开机第一件事自然是 sudo apt update结果红字刷屏“无法解析域名 cn.archive.ubuntu.com”“无法解析域名 ppa.launchpad.net”连微软、谷歌的第三方源也跟着一起报错。很多人第一反应是软件源坏了于是忙着换阿里云、换清华源折腾半天依旧连不上。这笔账得算清楚报错写的是“无法解析域名”说明系统压根不认识这个域名跟源服务器通不通没有半点关系问题出在 DNS 解析这一环。Ubuntu 18.04 默认把 DNS 查询交给 systemd-resolved 的 127.0.0.53 本地入口这个入口一旦拿不到可用的上游 DNSapt update 里配置的所有软件源会集体报错。这篇记录两条亲测有效的解决路径一条改完立刻恢复、但重启后要重新配置另一条用 resolvconf 把 DNS 固化下来、长期稳定。适合双系统用户、老机器玩家以及所有被 18.04 网络栈折腾过的运维。2. 解析链路诊断127.0.0.53 与 systemd-resolved 的三条定位命令2.1 报错文本里藏着信息区分“无法解析域名”和“连接超时”先学会读 apt 的输出。apt update 对每个软件源会打印三种状态之一命中Hit、获取Get、忽略Ign。命中和获取都说明域名解析成功、连接也建立了区别只在于是否重新下载了索引而“忽略”则说明这个源被 apt 跳过可能是索引无变化也可能是出错后被跳过。真正显眼的是这样两行错误:4 http://ppa.launchpad.net/obsproject/obs-studio/ubuntu bionic InRelease 无法解析域名“ppa.launchpad.net”这段文字包含两个关键信息。第一“无法解析域名”对应 getaddrinfo() 返回的 EAI_NONAME意思是 DNS 查询没有拿到任何结果如果网络链路本身不通apt 会打印“连接超时”或“无法连接”两类错误的排查方向完全不同——前者查 DNS 配置后者查路由与防火墙。第二报错清单里同时出现了 cn.archive.ubuntu.com、ppa.launchpad.net、packages.microsoft.com 这些互不相关的域名它们分散在不同 CDN 和服务器上不可能同时宕机唯一的共同点是都经过同一个 DNS 出口。看到这种多点同时失败基本可以断定问题出在系统解析域名这一层而不是源列表本身。拿到一手错误信息后不要急着换源。先判断是“所有域名都解析不了”还是“只有软件源解析不了”前者基本锁定 DNS 或网络问题后者才需要怀疑 source.list。实际现场绝大多数是前者——所有源集体报“无法解析域名”这时候换源毫无意义。另外注意一个容易误判的细节即使报错刷了满屏apt 底部仍可能打印“有 382 个软件包可以升级”这个数字是基于本地缓存的旧索引算出来的不代表源真的连通了别被这一行误导。2.2 127.0.0.53 是什么systemd-resolved 的动态视图与本地缓存Ubuntu 18.04 的 /etc/resolv.conf 不是传统意义上的静态文件而是 systemd-resolved 动态生成的视图。用 cat 查看它开头是几行管理提示最后一行才是关键$ cat /etc/resolv.conf # This file is managed by man:systemd-resolved(8). Do not edit. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run systemd-resolve --status to see details about the uplink DNS servers # currently in use. # # Third party programs must not access this file directly, but only through the # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way, # replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 options edns0 search DHCP HOST唯一的 nameserver 是 127.0.0.53它是 systemd-resolved 的本地 stub resolver监听本机回环的 53 端口。系统中所有程序的 DNS 查询先到它这里再由它转发给真正的上游 DNS。程序看到的 resolv.conf 永远只有一个本地地址上游地址藏在 systemd-resolved 内部必须单独用命令查。理解了这层结构就能明白为什么网上很多教程让你直接改 resolv.conf 加 nameserver 8.8.8.8结果重启就失效resolv.conf 只是 systemd-resolved 根据自身配置生成的产物服务一重启就按原配置重新生成手工追加的内容会被覆盖。这也是我坚持用 resolvconf 方案的原因——与其跟动态文件较劲不如把 DNS 写进生成它的源头配置里。提示18.04 里 /etc/resolv.conf 有时会变成普通文件而不是软链接这是 NetworkManager 或用户手工干预过的痕迹。用 ls -l /etc/resolv.conf 看类型能帮你判断这台机器上到底是谁在管 DNS。2.3 先用三条命令定位ping、dig、systemd-resolve --status改配置之前先把问题定性。我一般按这个顺序敲三条命令ping -c 4 223.5.5.5这条命令测试本机到公网 IP 的连通性223.5.5.5 是阿里公共 DNS 的 IP。如果 IP 通而域名不通说明网络链路没问题焦点在 DNS如果 IP 都不通先查网卡、路由和网关DNS 是更后面的事。注意部分网络会丢弃出站 ICMPping 不通不能断定断网但 ping 通基本能说明三层链路是好的。dig cn.archive.ubuntu.com 223.5.5.5 shortdig 手动指定 DNS 服务器查询域名绕过系统配置直接向公网 DNS 发起查询。返回 A 记录说明公网 DNS 能解析问题锁定在系统本地解析链路返回空或者 NXDOMAIN才需要怀疑域名本身。如果机器没装 dnsutils 包可以用 nslookup 代替但 dig 的输出最直观short 参数只打印最终地址没有干扰信息。systemd-resolve --status这条命令打印 systemd-resolved 当前实际使用的上游 DNS按网卡分组显示。重点看 DNS Servers 那一行如果是空的或者写的是 127.0.0.1说明没有可用的公网上游stub resolver 压根不知道把查询转发给谁。新版系统里这条命令改名为 resolvectl status18.04 下还是老名字两条都敲一遍也不会有副作用。三条命令跑完至少能判断网络通不通、公网 DNS 能不能解析、系统当前挂在哪个上游 DNS 上。下面两个换 DNS 的方案本质就是把第三个问题的答案从“没有上游”或“上游不可用”改成“明确指定一个能用的公网 DNS”。如果三条命令的结果互相矛盾比如 ping 通、dig 也通但 apt 还是报解析失败优先级最高的怀疑对象是 apt 命令的环境变量用 env | grep -i proxy 检查 http_proxy、https_proxy、all_proxy 是否被设成了不可达地址。apt 走代理时域名解析由代理完成代理失效就会向外表现为“无法解析域名”实际上和系统 DNS 毫无关系去掉失效的代理地址后立即恢复。3. 临时止血改 resolv.conf 让 apt 立刻恢复重启会失效3.1 操作步骤备份、补三行 nameserver、重启网络服务方案一适合急着用 apt 装包、不想折腾系统配置的场景。第一步备份原文件防止改完无法还原sudo cp /etc/resolv.conf /etc/resolv.conf.bak备份是因为方案一改的是动态生成的视图重启后会被覆盖一旦中间出了别的变故至少能拿备份对照原始状态。接着编辑文件sudo vim /etc/resolv.conf在文件末尾追加三行nameserver 8.8.8.8 nameserver 8.8.4.4 nameserver 127.0.0.1保存退出Esc 后输入 :wq后重启网络服务让配置生效sudo /etc/init.d/networking restart18.04 里如果提示找不到这个脚本说明这台机器走的是 systemd 管理的网络栈用替代命令sudo systemctl restart networking逻辑说明nameserver 是 glibc resolver 读取的上游 DNS 列表按顺序尝试。8.8.8.8 和 8.8.4.4 是 Google Public DNS负责解决原系统上“没有可用上游”的问题第三行 127.0.0.1 是保留项如果机器上正好有程序监听本机 53 端口提供 DNS 服务这一行会让它参与解析没有也不影响只是每次解析要等它超时后才会轮到下一行。重启网络服务的作用是让系统立刻重新读取 resolv.conf。实际上 glibc 在每次解析时都会读文件不重启也可能生效但重启能保证网络栈整体处于一致状态后续排查少一个变量。注意如果 vim 用不惯可以用 sudo nano /etc/resolv.conf操作更直观。只要是 root 权限修改效果完全一样。3.2 为什么重启会失效resolv.conf 只是生成出来的产物方案一的局限其实文件开头的注释已经写明This file is managed by man:systemd-resolved(8). Do not edit. 它由 systemd-resolved 动态生成手工追加的 nameserver 会立刻生效但下次重启、NetworkManager 重新应用配置、或者 systemd-resolved 服务重启时文件会被重新生成你写的内容消失。所以方案一适合“今天必须把 apt update 跑通”的现场不适合当长期配置。这也是我强调备份的原因。不少人改完 resolv.conf几天后系统重启发现 DNS 又乱了想改回去却不知道原文件长什么样。备份之后至少能确认原始状态是不是只剩 127.0.0.53 一行也方便判断问题是出在系统默认配置还是别的服务覆盖。如果你确定只是临时用一下又不想进 vim 手敲可以用 tee 直接覆盖整个文件sudo tee /etc/resolv.conf EOF nameserver 223.5.5.5 nameserver 119.29.29.29 EOF逻辑说明这个方法把 resolv.conf 整个替换成只含两行国内 DNS 的内容比追加更干净排除了 127.0.0.53 混合使用时可能出现的解析顺序问题。tee 写文件需要 sudo 权限命令里已经体现。临时方案建议把这种方法也记下来有些机器上 vim 没装或编辑器配置异常tee 是最快的替换手段。3.3 参数选择8.8.8.8、114.114.114.114、223.5.5.5 怎么选方案一里我沿用原文实测的 8.8.8.8 和 8.8.4.4这是 Google Public DNS全球通用但国内部分网络环境对它的 UDP 53 出站并不稳定如果配置完仍然解析不了优先怀疑这一对是不是被网络拦了。国内更常用的组合是nameserver 223.5.5.5 nameserver 119.29.29.29223.5.5.5 是阿里公共 DNS119.29.29.29 是腾讯 DNSPod两者在国内的连通性普遍比 Google DNS 好。114.114.114.114 也可以用但它带有较重的过滤策略个别域名解析结果可能异常所以我不把它放在第一位。选型逻辑记住两条。第一上游 DNS 必须从本机能访问写一个永远不可达的地址只会增加每次解析的超时时间。第二nameserver 列表是顺序尝试的第一个超时才轮到第二个所以把最信任、最快的地址放最前面不要为了“保险”堆四五个。glibc resolver 的超时行为可以通过 resolv.conf 里的 options 调整比如追加一行 options timeout:1 attempts:1 把每次上游等待从默认的 5 秒缩短到 1 秒重试 1 次apt 整体速度会明显改善尤其适合 DNS 上游不稳定但又不至于完全连不上的场景。3.4 确认生效看 apt 输出从 Err 变成 Hit改完先验证系统确实用了新 DNScat /etc/resolv.conf dig cn.archive.ubuntu.com short systemd-resolve --status | grep -A 5 DNS Serversdig 能返回 IP说明解析链路已经通了。然后重新执行更新sudo apt update注意对比输出之前报“错误”的 ppa.launchpad.net、cn.archive.ubuntu.com 应该变成“命中”Hit或者“获取”Get。命中和获取都是正常状态区别只是索引有没有变化。如果仍有个别源报错回到第 2 章的三条诊断命令重点检查是不是 8.8.8.8 出站被拦以及 apt 是否走了失效的代理环境变量。这里再提醒一句apt update 输出里出现“有 382 个软件包可以升级”不代表源健康这个数字是本地旧索引算出来的。真正要盯的是有没有 Err 和“无法解析域名”字样。另外有一种情况是刚改完立刻执行 apt 是好的过几分钟再跑又报错这多半是 NetworkManager 在后台把 resolv.conf 重写回了原样。遇到这种临时方案救不了你直接跳到第 4 章用 resolvconf 固化或者先把 NetworkManager 的 DNS 接管关掉。4. 持久化方案resolvconf 接管 DNS重启也不丢4.1 安装 resolvconf把 DNS 写进静态文件方案二的核心思路不直接碰 /etc/resolv.conf而是装一个叫 resolvconf 的工具让它来统一管理这个文件的生成。这样你写的 DNS 存放在专门的静态文件里resolvconf 每次生成 resolv.conf 时都会把你的配置合并进去重启不会丢。sudo apt install resolvconf这一步有个鸡生蛋的问题如果当前域名解析已经断了apt install 本身也连不上源。实际处理顺序有两种先用第 3 章的临时方案把 apt 恢复到能用的状态再回来执行这一步或者手动下载 resolvconf 的 deb 包用 sudo dpkg -i 安装。在 18.04 官方源里这个包很小、依赖也不复杂实践中先恢复 apt 再安装是最省事的路径。装完之后编辑静态配置文件 /etc/resolvconf/resolv.conf.d/basesudo vim /etc/resolvconf/resolv.conf.d/base写入内容nameserver 8.8.8.8 nameserver 8.8.4.4 nameserver 127.0.0.1保存退出执行更新命令sudo resolvconf -u逻辑说明base 文件是 resolvconf 的静态输入源内容会合并到最终生成的 /etc/resolv.conf。-u 参数强制触发一次重新生成。这里保留 8.8.8.8、8.8.4.4 作为系统兜底127.0.0.1 的作用与第 3 章方案一里一致——本地有 DNS 监听服务时参与解析没有则会被 resolvconf 过滤掉。理论上这一步做完cat /etc/resolv.conf 就应该能看到 8.8.8.8。4.2 resolvconf -u 做了什么合并输入并重写 resolv.confresolvconf 的输入来源不是只有 base 文件它把多个来源按优先级合并最终输出一份 /etc/resolv.conf。常见的输入源可以用一张表概括输入来源文件路径优先级接口自定义配置/etc/resolvconf/resolv.conf.d/ 下以接口名命名的文件最高DHCP 动态下发由 dhclient 等写入的运行时配置较高静态兜底配置/etc/resolvconf/resolv.conf.d/base最低执行 sudo resolvconf -u 后它把所有来源按优先级合并重新生成 /etc/resolv.conf。查看最终产物$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 8.8.8.8 nameserver 8.8.4.4注意一个细节base 文件里写了三行最终文件只显示两行。这是因为 resolvconf 对回环地址有自己的处理逻辑静态配置里的 127.0.0.1 没有被保留。这不是错误运行中的系统实际用的就是文件里能看到的那两行。如果机器上确实需要本地服务参与 DNS正确的做法是在相应网卡接口文件里配置而不是写在 base 里。要确认配置真的持久化重启后再查一次sudo reboot开机后重新 cat /etc/resolv.conf只要还有 8.8.8.8 和 8.8.4.4说明配置不是临时生效。这是方案二和方案一的本质区别方案一改的是生成结果方案二改的是生成源。从维护角度讲长期使用的机器我建议直接用方案二哪怕重装系统备份一个 base 文件就能秒级恢复 DNS 配置。注意如果你用的是静态 IP 而非 DHCP别忘了在 netplan 或 interfaces 文件里同步 DNS 配置否则 network 服务重启后旧配置会再次覆盖 resolv.conf。4.3 为什么有人说方案二“没生效”优先级、NetworkManager 与覆盖关系网上“装了 resolvconf 没用”的反馈不少大部分集中在三个场景。第一个场景是 DHCP 下发 DNS 抢占优先级。resolvconf 的合并逻辑里动态来源通常排在静态 base 文件前面。如果 DHCP 下发了一个当前不可用的 DNS典型例子是笔记本在公司拿到内网 DNS回家后继续沿用导致域名解析时好时坏glibc 先尝试不可用地址、超时之后才轮到 base 文件里的 8.8.8.8。排查方法ls /etc/resolvconf/resolv.conf.d/ 看有没有以接口名命名的动态配置把不可用的地址清掉或者直接在 base 文件里补齐想要的 nameserver让它至少有个兜底。第二个场景是 NetworkManager 的 DNS 接管。桌面版 18.04 里 NM 默认参与 DNS 管理它可能在 resolvconf 生成之后用自己的配置覆盖掉 resolv.conf。判断方法改完并执行 resolvconf -u 之后过几分钟再 cat 一次如果内容又变回只有 127.0.0.53 或 NM 写入的其他地址说明被 NM 覆盖了。解决办法是编辑 /etc/NetworkManager/NetworkManager.conf在 [main] 段加一行 dnsnone然后重启 NetworkManager或者直接在 NM 的连接配置里把 IPv4 DNS 改为手动填入 223.5.5.5 和 119.29.29.29。两种方式二选一不要同时用否则下次排查时连谁在管 DNS 都说不清。第三个场景是 resolvconf 服务没有真正启用。安装后没执行 sudo resolvconf -u或者服务被 mask都会表现为配置不生效。检查命令sudo systemctl status resolvconf sudo systemctl enable resolvconf状态不是 active、enable 输出不是 enabled 时先启动服务再更新配置。这个原因最基础却最常见——很多人装完包就直接去改文件忘了服务本身要先跑起来。还有一个实际遇到的情况服务器上用 netplan systemd-networkd 接管网络resolvconf 生成的配置在 netplan apply 之后被 systemd-resolved 重新覆盖。这种场景要改的是 /etc/netplan/ 下的 yaml 文件在对应网卡的 nameservers 字段里写 addresses。判断标准始终是一条先确定这台机器上到底是谁在生成 resolv.conf然后顺着生成方去改配置。桌面上是 NetworkManager 与 resolvconf 之争服务器上是 netplan 与 resolvconf 之争方法论完全一样。5. 避坑记录改完 DNS 还连不上五个翻车现场方案一方案二都跑通不代表以后不会翻车。下面五条是我在不同机器上实际踩过的坑按“现象 → 原因 → 解决”的顺序写覆盖桌面版、服务器、DHCP 环境和本地 DNS 监听几个常见场景。遇到问题先对照现象不要一上来就重装系统。5.1 现象base 文件里写好了 DNS重启后配置又变回原样原因桌面版 18.04 的 NetworkManager 默认接管 resolv.conf 的生成resolvconf 刚写完NM 过几分钟或重启后就把文件覆盖回自己的版本。这是方案二最常见的“没生效”现场但其实不是 resolvconf 的问题而是有另一个服务在跟它抢文件。解决编辑 /etc/NetworkManager/NetworkManager.conf在 [main] 段加一行 dnsnone然后执行 sudo systemctl restart NetworkManager或者在 NetworkManager 的连接设置里把 IPv4 DNS 改为手动填入 223.5.5.5 和 119.29.29.29。改完先用 cat /etc/resolv.conf 确认再重启一遍系统做最终验证。验证时注意看文件头部注释如果还是由 systemd-resolved 生成说明你改对了生成方。5.2 现象写了 8.8.8.8apt 依然报无法解析域名原因8.8.8.8 走的是 UDP 53 端口部分网络环境对出境 DNS 请求做了拦截或者响应包在回程被丢弃表现为配置正确但解析一直超时。这种情况不是配置语法错而是上游 DNS 本身不可达。解决换国内 DNS 测试执行 dig 223.5.5.5 cn.archive.ubuntu.com short能返回 A 记录说明这个上游可用。如果所有公网 DNS 都不可达用 sudo tcpdump -ni eth0 port 53 抓包看请求有没有出网卡、响应有没有回来定位是网络拦截还是本机防火墙问题。注意 tcpdump 需要 root 权限抓 DNS 流量时端口过滤写 port 53 就够了不会刷屏。5.3 现象局域网里能 ping 通网关但所有域名都解析失败原因DHCP 下发了一个不可用的 DNS 地址。典型的例子是路由器配置里填了内网 DNS或者办公网分配了只在公司内部有效的 DNS离开那个环境后全部失效。此时网络链路是通的但每次解析都失败现象和系统 DNS 配置错误几乎一样。解决按方案一或方案二把系统级 DNS 覆盖成公网地址同时用 nmcli device show 确认当前生效的 DNS 来源看 DHCP 是否每隔一段时间重新下发一次、把配置又冲掉。固定办公场景下直接在路由器 DHCP 设置里把 DNS 改成公网地址更省事省得每台机器单独排查。5.4 现象命令都还没跑到 apt先提示用户不在 sudoers 文件中原因当前用户没有 sudo 权限命令执行直接失败。这个错误在搜“apt update 无法解析域名”的人群里出现率不低因为很多人第一步敲的就是 sudo apt update如果用户不在 sudo 组连 apt 的启动都看不到更别说 DNS 问题。解决用管理员账户执行 sudo usermod -aG sudo 用户名让该用户重新登录后再执行 sudo apt update。如果卡在密码提示这一步分不清是用户密码还是别的记住 Ubuntu 的 sudo 默认用的是当前用户自己的密码。这个坑和 DNS 无关但拦在 DNS 排查前面先把它处理掉再继续。5.5 现象base 文件里写了 127.0.0.1解析慢到怀疑人生原因127.0.0.1 上根本没有程序监听 53 端口。glibc 对每个域名先尝试第一个 nameserver等它超时之后才轮到下一行于是每次解析都比正常情况多等好几秒apt update 整体被拖得很慢看起来像网络故障实际是解析链路上有个死地址。解决确认本地确实有程序在 127.0.0.1:53 监听再写这一行。检查监听状态用 ss -ulpn | grep :53没有输出就说明这一行不该存在。把 base 文件里的 127.0.0.1 删掉重新 resolvconf -u解析速度立刻恢复正常。6. 验证与善后apt update 通过之后把源和缓存一起收尾apt update 重新跑通后别急着关终端。先把验证做完——这个结论不只在 18.04 上成立Debian 系的其它版本遇到同类报错排查链路基本一致。我一般顺手做四件事把这次排障的成果固定下来。第一件确认可升级列表和源健康度。执行 apt list --upgradable看看那 382 个可升级包是不是都在列表里。如果列表内容明显缺失说明有源没刷新完整回头检查一下报错残留。第二件把 sources.list 里默认的 cn.archive.ubuntu.com 换成国内镜像。用 sed 批量替换最省事sudo sed -i s/cn.archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g /etc/apt/sources.list替换完之后再跑一次 sudo apt update确认新源也能命中。这一步和 DNS 修复是配套的DNS 决定你能不能解析域名源决定你解析之后访问哪台服务器两者都理顺apt 才算真正好用。第三件清理 apt 缓存把之前失败下载累积的残留清掉。sudo apt clean 清空 /var/cache/apt/archives 下的 deb 包sudo apt autoclean 只清已无用的旧包两个命令按需选择。之后 /var/lib/apt/lists 里旧索引会在下次 update 时自动覆盖。第四件把 DNS 配置固化到开机自启。如果用的是方案二执行 sudo systemctl enable resolvconf 并确认状态是 enabled如果用的是方案一在笔记本上还得多记一件事——每次重启后可能要重新加一遍 nameserver。这不是方案一的缺陷而是 systemd-resolved 动态文件机制决定的习惯就好。如果怕自己改的时候手抖建议把原文档里那两张报错和修复后的输出截图存下来对照着操作至少不会改错文件。从那以后我每次装完 Ubuntu 18.04 的第一件事就是先装 resolvconf、写死 base 文件里的 DNS、再换国内源最后才装其它软件。顺序固定了就再也不会半夜被 apt 报错叫醒去改 resolv.conf。希望这次的排查过程能帮到你至少让你下次看到满屏“无法解析域名”时知道该往哪看。本文还有配套的精品资源点击获取