简介在Ubuntu系统18.04版本中执行软件包更新命令时常会遇到无法解析域名的报错导致源列表无法访问这份Word技术方案文档整理了经过实际验证的解决思路与操作指引适合服务器运维人员、系统管理员以及遇到同类问题的开发者和初学者。文档完整描述了问题现象列举了常见软件源地址解析失败的情形并给出了亲测有效的处理办法包括调整域名服务器配置、更换软件源列表等关键操作。资源包内仅包含一个Word文档大小约为一百一十四KB内容精炼便于直接阅读和对照实施文档围绕现象诊断、原因定位和修复验证展开无需额外工具即可完成排查既可以帮助新手快速恢复软件更新环境也能为有经验的管理员提供一份可复用的排错清单。目前已有四千三百二十五人学习下载是处理这一系统常见网络问题的实用参考。1. “无法解析域名”不是网络断了Ubuntu18.04 的 apt update 到底卡在哪在 Ubuntu 18.04 上执行 sudo apt update最常撞见的错误不是 404而是那句“无法解析域名”。系统本身没坏网络也可能通着ping 网关能通、浏览器能开网页可 apt 就是解析不了 archive.ubuntu.com终端里反复打印 Temporary failure resolving。这个现象在刚装完系统、双系统切换、虚拟机克隆、公司内网环境下尤其常见本质是 DNS 解析链路断了一环而不是源地址写错。这篇文章把 18.04 上涉及的 /etc/resolv.conf、systemd-resolved、sources.list 三条线一起讲透从定位命令、临时救急到永久修复都给你改完不用反复重启。2. 先定位再动手三条命令看清 DNS 解析链路2.1 把报错分三类先判断是哪一段解析挂了同样是“无法解析域名”终端里实际看到的内容可能有三副面孔。我建议先别急着去改 sources.list把报错原文原样记下来然后再决定动哪一层。下面这张表可以当作快速分诊表。报错原文实际含义优先排查的位置Temporary failure resolving archive.ubuntu.comDNS 查询超时或本地解析器拒绝响应/etc/resolv.conf、systemd-resolved 状态Could not resolve archive.ubuntu.com上游 DNS 返回无记录或域名被过滤nslookup 指定公共 DNS 对比Name or service not known主机名解析失败注意是不是拼写或 search 域问题/etc/hosts、/etc/resolv.conf 的 search 行第一种最常见基本可以锁定本地解析器没有可用 DNS 服务器第二种要重点怀疑上游 DNS 本身有问题比如指到了内网 DNS 却查公网域名第三种往往被忽略很多人把 archive.ubuntu.com 写成了 archive.ubuntn.com或者 resolv.conf 里没有配 search 域导致短主机名解析不了。分清楚这三类你才知道要去改哪一层不至于白折腾一晚上。还有一类场景容易被误诊你用sudo apt install ./spark-store*.deb这类命令装本地 deb 包时报依赖解析失败终端也会出现“Unable to locate package”或解析相关字样。这本质上不是 DNS 挂而是本地索引没更新先跑一遍sudo apt update把软件源索引刷出来再说。别一竿子全怪到 DNS 头上。2.2 手动复现解析ping、getent、systemd-resolve --status定位 DNS 问题我一般按住三个命令逐步试顺序完全可以固定下来。第一条先看三层通不通第二条看四层能不能出公网第三条看域名解析走的是哪个服务器。# 1. 三层连通性ping 网关不通就查网卡和网线 ping -c 4 192.168.1.1 # 2. 四层连通性ping 一个公网 IP通说明网络链路没断 ping -c 4 223.5.5.5 # 3. 域名解析getent 走的是 glibc 的 getaddrinfo和 apt 的解析路径最接近 getent hosts archive.ubuntu.com # 4. 看 systemd-resolved 当前生效的 DNS 是哪几个 systemd-resolve --status | grep -A 4 DNS Servers第一步如果网关都不通说明网卡没拿到 IP 或者网线/无线根本没连上这时候去改 resolv.conf 是白费力气。第二步的 223.5.5.5 是公共 DNS 地址能 ping 通证明三层和四层链路都正常问题基本锁定在解析环节。第三步是关键getent hosts 和 apt 用的是同一套 glibc 解析逻辑它返回的 IP 如果是空的或者报错那就和 apt 的报错对上了。第四步看 systemd-resolved 的现状18.04 默认由它接管 DNS这里能直接看到每块网卡实际生效的 nameserver。这套步骤做完你大概率已经能判断是哪一环断了。如果你发现 getent 能解析出 IP但 apt update 照样报错那问题就不在 DNS而在 apt 本身比如 http 代理环境变量或者 sources.list 里的协议写错。2.3 谁在偷偷改写 /etc/resolv.confdnsmasq 与 NetworkManager 的冲突Ubuntu 18.04 的网络栈由 netplan 统一描述底层可能接入 NetworkManager也可能由 systemd-resolved 直接管理多个组件之间会打架。最常见的翻车现场是 /etc/resolv.conf 这个文件本身它可能是指向 systemd-resolved 的软链接也可能是 NetworkManager 生成的普通文件还可能被自己装的 dnsmasq 反复覆盖。# 查看 resolv.conf 当前是普通文件还是软链接 ls -l /etc/resolv.conf # 查看是否有 dnsmasq 进程在运行 ps aux | grep dnsmasq # 如果 dnsmasq 在跑但不是主动装的先停掉避免干扰 sudo systemctl stop dnsmasq sudo systemctl disable dnsmasqls 的输出会直接告诉你答案。如果是软链接会显示指向/run/systemd/resolve/stub-resolv.conf或/run/systemd/resolve/resolv.conf如果显示普通文件那多半是 NetworkManager 或 cloud-init 生成的。第二个命令是为了确认系统里有没有 dnsmasq 进程很多新手装完某些软件后dnsmasq 会被作为依赖带进来它默认监听 127.0.0.53 或 127.0.0.1会和 systemd-resolved 抢占解析端口造成域名查询时通时不通。这个冲突非常隐蔽你配置 resolv.conf 怎么改都生效不了因为 dnsmasq 会在后台持续改写。看到这种现象不要急着加 nameserver先把多余的 dnsmasq 停掉等 resolv.conf 不再被变更再继续后续修复。3. 修 resolv.conf 只是第一步在 Ubuntu18.04 上把 DNS 真正改对3.1 临时救急手工改 /etc/resolv.conf 和 chattr 锁文件如果线上有服务等着装没时间细查最粗暴的临时方案是直接往 /etc/resolv.conf 里写一个可用的 nameserver。这个操作能立刻让 apt update 恢复正常但请注意它只是应急不是根治。重启网卡或重启 systemd-resolved 后这个文件很可能被重新生成你的手改内容就丢了。# 改之前先备份出问题能回滚 sudo cp /etc/resolv.conf /etc/resolv.conf.bak # 写入一个公共 DNS注意是覆盖写 echo nameserver 223.5.5.5 | sudo tee /etc/resolv.conf # 为了防止重启后被覆盖可以临时锁定文件属性谨慎使用 sudo chattr i /etc/resolv.conf # 验证 cat /etc/resolv.conf sudo apt update这里关键参数是 nameserver 那一行一个文件里最多写三个 nameserver系统会按顺序挨个查询。223.5.5.5 是公共 DNS用它测试最不容易被干扰。chattr i 是把文件设为不可修改这是一个保护动作能确保任何进程都改不了它但它有副作用比如之后你想正常配置 DNS 时必须先执行sudo chattr -i /etc/resolv.conf解锁不然会提示 Operation not supported。讲实话chattr i 这个手段我很少在服务器上用。它像是给伤口贴了块膏药止疼但不治本。如果你只是临时撑过今晚可以这么干如果是生产环境我更建议你花十分钟把后面的 systemd-resolved 方案落实掉。3.2 走 systemd-resolved 改全局 DNS重启后才不丢Ubuntu 18.04 默认启用 systemd-resolved正确的做法是让它统一管理 DNS而不是手工去改 resolv.conf。你需要动两个地方一个是 /etc/systemd/resolved.conf这是全局配置另一个是 /etc/resolv.conf 的软链接指向确保系统所有程序都走 systemd-resolved 的解析接口。# 编辑全局 DNS 配置 sudo nano /etc/systemd/resolved.conf配置文件的 [Resolve] 段按下面写DNS 和 FallbackDNS 是两个不同的选型。DNS 是首选FallbackDNS 是兜底[Resolve] DNS223.5.5.5 119.29.29.29 FallbackDNS114.114.114.114 #Domains #LLMNRno改完配置文件后要让 resolv.conf 的软链接指向 systemd-resolved 生成的运行时文件。这一步非常关键很多文章只让你改 resolved.conf忘了管软链接结果 systemd-resolved 自己解析正常但 apt 还是走旧路径。# 让 resolv.conf 指向运行时的真实解析器而不是 stub sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf # 重启解析服务让配置生效 sudo systemctl restart systemd-resolved # 验证服务状态 systemd-resolve --status | head -20说清楚两个软链接目标文件的区别/run/systemd/resolve/resolv.conf里写的是真实 DNS 服务器地址程序拿到后会直接向这些地址发查询/run/systemd/resolve/stub-resolv.conf则统一指向 127.0.0.53所有查询先到本机 systemd-resolved再由它转发。18.04 上很多程序对 stub 的支持有问题所以我一般直接链到真实解析器那份。DNS 行里多个地址用空格分隔最多三个超过会被忽略。FallbackDNS 是在首选全部超时后才启用的Daily 这种长连接场景感知不明显但短期查询失败时能救命。如果这台机器后面还要跑容器或虚拟化注意 LLMNR 和 DNSSEC 这两个参数内网环境有奇怪域名时把 LLMNR 设为 no 能少踩很多坑。3.3 顺手换一套适合 18.04 的 apt 源别混版本代号DNS 修好后 apt update 可能还是慢或者报 404说明软件源本身也需要换。Ubuntu 18.04 的代号是 bionic很多新资料默认写 22.04 的 jammy直接复制过来必然出错。我的习惯是把 sources.list 整体重写不要只改一半。# 备份一份留后悔药 sudo cp /etc/apt/sources.list /etc/apt/sources.list.save # 重写整个文件这里以清华源为例 sudo tee /etc/apt/sources.list EOF deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse deb http://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse EOF # 更新索引 sudo apt update这里四个组件字段 main restricted universe multiverse 缺一不可。很多人安装第三方软件报“Package has no installation candidate”就是因为源里没开 universe 或 multiverse。bionic-security 是安全更新必须单独留一行不能想当然认为 updates 里包含它。如果你想用其他镜像站把链接前缀整体替换即可路径结构保持一致就行。特别提醒一个坑不要在同一份 sources.list 里混装 18.04 和 20.04 的源。依赖库版本差异会导致 apt 解析依赖关系时出现无法满足的冲突这时候就算 DNS 全通你也会被一堆版本不匹配报错搞到头大。我也见过教程让你用 sed 批量替换 archive.ubuntu.com 为镜像站的这是常见手法但你一定要确认替换后的链接在浏览器里能打开否则就是把一次解析错误换成了另一个 404 错误。3.4 静态 IP 服务器DNS 要写到 netplan 里才生效笔记本和虚拟机走 DHCP 时DNS 由路由下发改 systemd-resolved 就够用。但机房服务器或内网设备配的是静态 IPDNS 必须写进 netplan 配置里不然每次重启网卡系统还是会把旧的 DNS 加载回来。Ubuntu 18.04 的 netplan 默认配置文件放在 /etc/netplan/ 下文件名一般是 01-netcfg.yaml 或 50-cloud-init.yaml使用sudo nano /etc/netplan/01-netcfg.yaml编辑。network: version: 2 ethernets: eth0: dhcp4: no addresses: [192.168.1.100/24] gateway4: 192.168.1.1 nameservers: addresses: [223.5.5.5, 119.29.29.29] search: [example.local]写完执行sudo netplan apply然后用systemd-resolve --status确认 eth0 下挂的 DNS 地址是否生效。netplan 的 nameservers 段里两个参数要分清addresses 是 DNS 服务器地址列表search 是域名搜索后缀这决定了你访问短主机名时自动补全哪个域。比如 search 配了 example.local那么 ping gitlab 时系统会先解析 gitlab.example.local失败后再解析 gitlab 本身。内网环境这个 search 很关键配错会导致内网短域名永远解析不了。另外说一个 18.04 的历史包袱gateway4 这个写法在老版本 netplan 里是合法的但到了 20.04 之后被标记废弃要用 routes 替代。如果你是从旧文档复制配置看到gateway4相关警告不用慌在 18.04 上它还能工作但最好顺手改成新写法以免以后升级系统时翻车。4. 避坑手册双系统、虚拟机、公司内网和 sudo 权限的 5 个翻车现场4.1 双系统安装 Ubuntu18.04 后能上网但 apt 报域名错误现象电脑装了 Windows 和 Ubuntu 18.04 双系统Windows 下一切正常切到 Ubuntu 后无线网络能连上但 sudo apt update 就报 Temporary failure resolving。原因这个坑有 70% 的概率出在网卡和 BIOS 的电源管理上。Windows 的快速启动会锁住网卡固件状态切到 Ubuntu 后网卡处于半初始化状态虽然能拿到 IP但 DHCP 下发的 DNS 不完整还有一部分是 BIOS 里开启了节能模式网卡在低功耗状态下无法正常处理大流量 DNS 查询。解决先去 BIOS 里关掉 Fast Boot 和网卡的节能选项Windows 下执行powercfg /h off关闭快速启动。然后回到 Ubuntu用 2.2 的命令核对 DNS。如果 getent 能解析apt 还报错就在 BIOS 里把网卡的 Wake on LAN 也关掉这招对笔记本特别有效。改完后你会发现不仅 apt 正常了连开机后无线重连的速度都快了很多。4.2 虚拟机克隆后 resolv.conf 被 cloud-init 重置现象VMware 或 KVM 里克隆了一台 Ubuntu 18.04 模板机改完 DNS 一切正常但只要一重启/etc/resolv.conf 又变回原来的内容或者干脆变成空的。原因虚拟机模板通常预装了 cloud-init它会在每次开机时根据 metadata 重新生成网络配置。你手动改的 resolv.conf 在 cloud-init 运行时会被视为未托管配置直接覆盖掉。解决如果你不需要 cloud-init 管理网络就禁用它。编辑/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg写入network: {config: disabled}然后执行sudo cloud-init clean --logs清理缓存。清理完再改 netplan 或 resolved.conf重启后就不会被还原了。这里强调一下不要对这种情况用 chattr i 锁文件因为 cloud-init 会在启动早期阶段重置文件属性锁了可能导致启动流程卡住反而把问题搞大。4.3 公司内网必须用内网 DNS公共 DNS 反而惹事现象在公司局域网里把 DNS 改成公共 DNS 后外网域名能解析了但内网系统的域名全部解析失败apt update 也访问不了公司内网搭的软件源服务器。原因企业内网普遍有内部域名系统比如 gitlab.example.local、mirror.example.local 这些只有内网 DNS 服务器知道它们。公共 DNS 没有这些记录自然返回域名不存在。你以为自己在优化 DNS实际上是把内网解析链给切断了。解决把内网 DNS 地址写在 DNS 列表的第一位公共 DNS 写在后面做兜底。比如公司 DNS 是 10.10.0.2配置里写成DNS10.10.0.2 223.5.5.5。注意不要用 FallbackDNS 去写公共地址因为 FallbackDNS 的触发条件是首选全部超时如果你首选是内网 DNS 而它只是某些记录返回慢根本不会走到兜底那一步。内网机器上更稳的做法是把高频访问的内网域名直接写进 /etc/hosts绕过 DNS 整个环节。4.4 普通用户 sudo 报 “未出现在 sudoers 文件中”先别怪 DNS现象新建的普通用户执行sudo apt update输入密码后系统提示“某某 未出现在 sudoers 文件中。此事件已被记录。”然后拒绝执行。这是热词里出现频率很高的问题容易被误以为系统权限坏了连带 DNS 也出问题。原因Ubuntu 安装时创建的第一个用户在 sudo 组里但后续用useradd命令添加的用户默认不在任何管理组。Debian 系的 sudo 组名称可能叫 sudo也可能叫 admin没加入就自然没有提权资格。解决切到 root 或其他有管理员权限的账号执行下面的命令把用户加入 sudo 组# 把 username 换成你的实际用户名 sudo usermod -aG sudo username # 验证组成员关系 groups username # 确认 /etc/sudoers 文件权限正确 ls -l /etc/sudoers/etc/sudoers 的正确权限是 440属主 root。如果权限不对sudo 会直接拒绝所有普通用户。组改完后让用户重新登录一次再执行 sudo apt update。还有个别场景是远程 SSH 执行 sudo 时提示需要 tty那是 /etc/sudoers 里缺Defaults requiretty或反过来多了一行限制与 DNS 无关也要单独处理。4.5 sources.list 被改坏后 boot-repair 等修复工具装不上现象双系统引导坏了想装 boot-repair 来修按网上的教程添加了 PPAsudo apt-get install boot-repair却报错卡在“正在读取软件包列表… 完成… 正在分析软件包的依赖关系树”之后提示无法定位软件包或 404。原因boot-repair 所在的源是 universe 或独立 PPA如果 sources.list 里 multiverse/universe 被注释掉或者 PPA 源指向了空的发布版目录apt 索引里根本找不到这个包。网上不少教程只给了添加 PPA 的命令却没有提醒要先保证基础源完整。解决先把基础 sources.list 恢复到 3.3 里那样的完整状态确保 main/universe/multiverse 都打开。然后添加 PPA 并安装# 添加 boot-repair 的 PPA sudo add-apt-repository ppa:yannubuntu/boot-repair # 更新索引 sudo apt update # 安装 sudo apt install boot-repair执行 sudo apt update 时留意有没有报 “The repository ... does not have a Release file”。如果有说明这个 PPA 不提供 18.04 的 bionic 版本别再硬装换用官方 live 镜像里的 boot-repair 工具才是一步到位的路。总而言之sources.list 是 apt 的地基地基不对上楼就晃。5. 把 DNS 排查变成例行巡检固化、验证与收尾技巧5.1 一条命令串起解析与软件源连通性验证修完之后不要直接关终端花三十秒做一次完整验证确认不是“这次运气好能过、重启就打回原形”。我习惯把三个检查串成一条命令执行# 一条命令完成解析、离线和 apt 更新检查 getent hosts archive.ubuntu.com systemd-resolve --status | grep Current DNS sudo apt update 21 | tail -5中间这个systemd-resolve --status的 Current DNS 字段是关键它显示的是系统当前真正使用的 DNS 地址。如果这个值和你配置的不一样说明有别的机制在覆盖配置立刻去查 netplan 或 NetworkManager。apt update 的最后几行如果出现 “All packages are up to date” 或者 “Can not write log” 之外的错误信息就要把终端输出原文留存方便后续排查。我见过太多人改完配置不看验证结果第二天开机又被同样的问题打回原形。5.2 双栈环境下 IPv6 解析拖慢用 gai.conf 调优先级Ubuntu 18.04 默认开启 IPv6如果你的宽带或内网 IPv6 线路质量差DNS 解析时系统会优先尝试 AAAA 记录超时后才回头查 A 记录表现就是 apt update 卡顿十几秒后才开始跑。这时候需要调整 glibc 的地址排序规则。# 编辑 gai.conf去掉一行的注释 sudo nano /etc/gai.conf找到precedence ::ffff:0:0/96 100这一行把行首的井号删掉保存退出。这一行的作用是让 IPv4 映射地址的优先级高于纯 IPv6 地址也就是系统在双栈场景下优先走 IPv4。改完不用重启直接执行getent ahosts archive.ubuntu.com你会看到返回结果里 IPv4 地址排在了前面。这个修改对 apt 没有副作用但对所有网络请求都会生效如果你的环境确实需要 IPv6 优先访问某些资源就反向操作。5.3 内网机器最后的兜底把关键域名写进 /etc/hosts即使 DNS 配置全部做对内网环境依然可能因为 DNS 服务器重启、交换机策略调整导致解析临时中断。对于内网真正的核心系统我一般会把域名和 IP 的对应关系写进 /etc/hosts这是最原始也最稳定的解析方式完全绕过 DNS。# 追加到 /etc/hosts 192.168.1.10 aptcache.example.local 192.168.1.11 gitlab.example.local这里有一个前提IP 必须是静态分配否则 hosts 里的记录会失效。动态 IP 的机器不要这么干写了也是白写。另外 hosts 文件对 DNS 的优先级高于一切远程配置写错了会把原本正常的解析引导到错误 IP 上改的时候要克制只用在内网关键节点。这套操作下来你会发现 18.04 的 DNS 问题其实就那么几个源头symlink 指向、cloud-init 覆盖、dnsmasq 抢占、sources.list 版本代号写错。我现在的习惯是每台 Ubuntu 18.04 装完系统第一件事就是检查 resolv.conf 软链接指向和 sources.list 版本号把这两项确认好后面几乎不会在“无法解析域名”这种事情上翻车。希望帮到你。本文还有配套的精品资源点击获取