Ubuntu 22.04 无法安装依赖包：解决 apt‑get 错误“Could not resolve”

我们在数据中心运维工作中常常会遇到各种影响服务器正常运行的故障，其中 Ubuntu 系统在执行 apt-get 安装时出现"Could not resolve"错误，是许多技术人员常见的问题。这个问题通常与 DNS 解析失败有关，但在复杂的网络环境下，问题的根源可能并不像表面那么简单。A5数据将结合我们的实际运维经验，深入剖析 Ubuntu 22.04 系统中出现此问题的原因，并提供详细的解决方案，帮助大家快速恢复系统的正常运行。

一、问题背景

在我们公司为跨境电商平台提供的多台Ubuntu 22.04 LTS 数据中心服务器上，近期出现一个十分棘手却常见的问题：

执行 apt‑get install 或 apt‑get update 时频繁出现如下错误：

复制代码

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease
  Could not resolve 'archive.ubuntu.com'
E: Some index files failed to download. They have been ignored, or old ones used instead.

从表面看这是 "DNS 解析失败"，但在数据中心网络环境下却并不是简单 DNS 失效能解释的。本文将结合产品参数、硬件配置、网络配置细节、排查流程、代码示例、解决方案对比表完整复现并系统解决这个问题。

二、软硬件环境一览

在开始排查前，我们先明确故障系统的运行环境。

2.1 香港服务器www.a5idc.com硬件配置（样例）

项目	参数
香港服务器型号	Dell PowerEdge R650
CPU	2 × Intel Xeon Silver 4314（24 核，2.4GHz）
内存	128GB DDR4 ECC
硬盘	2 × 1TB NVMe SSD RAID1
网络	2 × 10GbE + BGP 多线网络
数据中心	洛杉矶（CN2 + 多出口带宽）

2.2 软件与系统版本

组件	版本
操作系统	Ubuntu 22.04 LTS (Jammy Jellyfish)
内核	5.15.0‑80‑generic
Netplan	0.104
Systemd	249
DNS Resolver	systemd‑resolved

三、故障现象与初步确认

3.1 典型复现场景

在机房控制台或通过 SSH 执行：

bash 复制代码

sudo apt update

出现：

复制代码

Err:1 http://security.ubuntu.com/ubuntu jammy-security InRelease
  Could not resolve 'security.ubuntu.com'
Reading package lists... Done
W: Failed to fetch ...
W: Some index files failed to download...

3.2 初步确认

网络连通性正常
bash 复制代码
```
ping 8.8.8.8 -c 4
```
返回正常响应，说明出口路由与链路无明显问题。

DNS 解析失败

bash 复制代码

nslookup archive.ubuntu.com

复制代码

** server can't find archive.ubuntu.com: NXDOMAIN

问题核心：DNS 解析在 Ubuntu 22.04 中失败，间接导致 apt‑get 无法拉取软件包。

四、原因分析

在 Ubuntu 22.04 中，系统默认使用 systemd‑resolved 作为 DNS 解析管理器，通过 /etc/resolv.conf 软链接指向 /run/systemd/resolve/stub‑resolver.

典型错误配置：

bash 复制代码

root@server:/etc# ls -l resolv.conf
lrwxrwxrwx 1 root root 39 Jul 20 12:34 resolv.conf -> /run/systemd/resolve/stub-resolv.conf

而 stub 解析器默认监听在 127.0.0.53:53，在复杂企业网络中常因 DNS 拦截、ACL、BGP DNS 劫持、境外 DNS 不通等问题导致解析失败。

五、故障排查流程与关键技术细节

5.1 Step 1 --- 检查 DNS 服务状态

bash 复制代码

systemctl status systemd-resolved

确认 active (running)。

5.2 Step 2 --- 查看当前 DNS 配置

bash 复制代码

resolvectl status

输出示例：

复制代码

Global
      DNS Servers: 127.0.0.53
      DNSSEC: no

Link 2 (eth0)
      Current DNS Server: 127.0.0.53

说明 DNS 并未指向真实可用的外部 DNS。

六、解决方案详解与代码示例

6.1 方案一：使用可信外部 DNS + 重写 systemd‑resolved

推荐用于数据中心服务器、云服务器等有稳定公网出口的场景。

✅ 步骤 1: 配置 Netplan

编辑 /etc/netplan/01-netcfg.yaml：

yaml 复制代码

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      addresses: [192.168.10.200/24]
      gateway4: 192.168.10.1
      nameservers:
          addresses: [8.8.8.8,1.1.1.1]

应用：

bash 复制代码

sudo netplan generate
sudo netplan apply

✅ 步骤 2: 关闭 stub 解析

bash 复制代码

sudo sed -i 's/^#DNSStubListener=yes/DNSStubListener=no/' /etc/systemd/resolved.conf
sudo systemctl restart systemd-resolved

✅ 步骤 3: 强制写入真实 resolv.conf

bash 复制代码

sudo rm /etc/resolv.conf
echo -e "nameserver 8.8.8.8\nnameserver 1.1.1.1" | sudo tee /etc/resolv.conf

安装测试：

bash 复制代码

sudo apt update && sudo apt install -y htop

结果预期成功。

6.2 方案二：内部 DNS 缓存 + 上游递归 DNS

适合内网高并发 DNS 解析需求

组件	版本
DNS 服务器	BIND9 / Unbound
缓存	是
上游递归	运营商 DNS + 114 DNS

简单 Unbound 安装示例：

bash 复制代码

sudo apt install -y unbound

编辑 /etc/unbound/unbound.conf.d/custom.conf:

conf 复制代码

server:
    verbosity: 1
    interface: 0.0.0.0
    access-control: 0.0.0.0/0 allow
    root-hints: "/var/lib/unbound/root.hints"
forward-zone:
    name: "."
    forward-addr: 8.8.8.8
    forward-addr: 1.1.1.1

重启：

bash 复制代码

sudo systemctl restart unbound

将 /etc/resolv.conf 指向内部 Unbound：

复制代码

nameserver 127.0.0.1

测试：

bash 复制代码

dig ubuntu.com

6.3 方案对比表

方案	优点	缺点	适用场景
直指外部 DNS	配置简单，快速有效	对运营商出口敏感	公网服务器
内部 DNS 缓存	稳定，可缓存大量请求	需要额外维护	大规模机群
使用 DHCP DNS	自动管理	容易被内部策略劫持	内网封闭环境

七、进阶检查与验证

7.1 验证 DNS 是否有效

bash 复制代码

dig @8.8.8.8 archive.ubuntu.com +short

应返回 IP 列表。

7.2 apt 安装日志检查

bash 复制代码

tail -n 200 /var/log/apt/term.log

确认无 "Could not resolve" 错误。

八、常见错误场景与应对

✖ 错误：Network Manager 覆盖 Netplan

部分服务器安装了 NetworkManager，可执行：

bash 复制代码

sudo systemctl disable NetworkManager

或在 netplan 配置中明确指定：

yaml 复制代码

renderer: networkd

九、总结与启示

通过本次故障，我们系统性地解决了 Ubuntu 22.04 apt‑get 出现 "Could not resolve" 的根因：

✅ 理解了 systemd‑resolved 与 Netplan 的关系

✅ 结合数据中心网络环境做出了正确 DNS 配置

✅ 提供了外部 DNS 与内部 DNS 缓存两种稳定方案

若在未来的机房部署中遇到类似现象，请优先检查：

DNS 配置是否有效（resolvectl status）
是否被 stub resolver 干扰
是否存在内部网络策略 DNS 劫持