1. 为什么 apt 数据源值得你花十分钟认真配置很多人装完 Ubuntu 之后第一件事就是打开终端敲apt update然后看着进度条卡在某个百分比一动不动或者下载速度只有几十 KB/s心里想着“忍忍就过去了”。我刚开始用 Ubuntu 那几年也是这个心态直到有一次在客户现场部署一套服务因为 apt 源的问题整整耽误了两个小时从那以后我就养成了一个习惯拿到任何一台新的 Ubuntu 机器第一件事就是把 apt 数据源配置到位。apt 是 Ubuntu 生态里最核心的包管理工具你装的每一个软件、每一个依赖库、每一次系统更新背后都是 apt 在跟远端的软件仓库打交道。而 apt 数据源就是告诉 apt “去哪里下载这些包”的那份地址清单。默认情况下Ubuntu 官方源在国内的访问速度并不理想尤其是跨运营商、跨地域的时候延迟高、丢包多体验非常糟糕。把数据源换成国内优质的镜像站点下载速度从几十 KB/s 提升到几 MB/s 甚至十几 MB/s这是立竿见影的效果。这篇文章适合所有使用 Ubuntu 的人——不管你是刚接触 Linux 的新手还是已经用了几年但一直没认真研究过 apt 配置的老用户。我会从 apt 源的基本原理讲起把配置文件的结构拆开揉碎然后给出可以直接复制粘贴的操作步骤最后分享一些我在实际运维中踩过的坑和总结出来的排查技巧。你不需要有很深的 Linux 功底只要能打开终端、会用基本的命令行操作跟着做就行。2. apt 数据源的核心原理与配置思路拆解2.1 apt 到底是怎么找到并下载软件的要理解 apt 数据源先得搞清楚 apt 的工作流程。你可以把 apt 想象成一个图书采购员软件仓库就是各个出版社的仓库而数据源配置文件就是采购员手里的“仓库地址簿”。当你执行apt install某个软件时apt 会做这么几件事第一步读取/etc/apt/sources.list文件以及/etc/apt/sources.list.d/目录下的所有.list文件这些文件里记录了所有可用的软件仓库地址。第二步根据这些地址去下载仓库的元数据信息也就是每个仓库里有哪些包、什么版本、依赖关系是什么这些元数据会缓存在本地。第三步根据你的安装请求在缓存的元数据里找到对应的包然后从仓库地址下载实际的.deb安装包。第四步调用 dpkg 完成安装和配置。这里面有个关键点apt update这个命令做的事情就是刷新元数据缓存它并不安装任何软件只是去各个仓库把最新的包列表拉下来。很多人看到apt update很慢就以为是下载软件慢其实不是它只是在更新“仓库里有什么”这份清单。真正下载软件是在apt install的时候。所以如果你觉得 apt 慢首先要区分是 update 慢还是 install 慢两者的原因和解决思路不完全一样。2.2 为什么默认源在国内体验不好Ubuntu 官方的主仓库服务器主要部署在海外国内用户访问的时候要经过多个网络节点延迟高、带宽受限。而且官方源并没有针对国内网络环境做优化高峰期的时候丢包率很高apt 下载过程中经常出现“连接超时”“Hash Sum mismatch”这类报错。国内有不少机构和企业提供了 Ubuntu 镜像服务这些镜像站会定期从官方源同步软件包相当于把“仓库”搬到了国内。你从这些镜像站下载走的是国内网络速度和稳定性都有质的提升。常见的镜像站点包括各高校和云服务商提供的镜像服务它们覆盖了 Ubuntu 的主仓库、更新仓库、安全仓库以及各种第三方仓库。选择镜像站的时候有几个考量因素同步频率多久从官方源同步一次、覆盖范围是否包含你需要的所有仓库组件、稳定性会不会经常宕机、以及你所在网络到镜像站的连通质量。不同的镜像站在不同地区、不同运营商网络下的表现可能差异很大所以“哪个镜像站最好”这个问题没有标准答案需要根据你的实际情况来测试。2.3 配置文件的结构长什么样Ubuntu 的 apt 源配置采用了一种非常简洁的格式。打开/etc/apt/sources.list文件你会看到类似这样的内容deb http://archive.ubuntu.com/ubuntu/ jammy main restricted universe multiverse deb http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted universe multiverse deb http://archive.ubuntu.com/ubuntu/ jammy-security main restricted universe multiverse每一行的结构可以拆解为四个部分。第一个部分是deb或deb-srcdeb表示这是二进制包仓库deb-src表示源代码包仓库。第二个部分是仓库的 URL 地址。第三个部分是发行版代号比如jammy对应 Ubuntu 22.04focal对应 20.04noble对应 24.04。第四个部分是仓库组件也就是main、restricted、universe、multiverse这几个。这四个组件各有分工main是官方支持的自由软件restricted是官方支持的专有软件驱动universe是社区维护的自由软件multiverse是受版权或法律限制的软件。大多数日常使用场景下四个组件都启用是比较省心的做法避免出现“找不到某个包”的情况。另外要注意jammy-updates和jammy-security这两个后缀。-updates是稳定版更新仓库包含已经发布的安全补丁和 bug 修复-security是安全更新仓库优先级最高。这两个仓库一定要配置否则你的系统可能缺少关键的安全补丁。2.4 配置方案的选择逻辑配置 apt 源有几种常见的做法各有利弊。第一种是直接编辑/etc/apt/sources.list文件把所有官方源地址替换成镜像站地址。这种做法最直接适合全新安装的系统。第二种是在/etc/apt/sources.list.d/目录下新建一个单独的.list文件把镜像源写进去同时把原来的sources.list里的内容注释掉。这种做法更清晰方便后续管理和回滚。第三种是使用图形化工具或命令行工具自动生成配置比如software-properties-gtk或者一些第三方脚本。我个人推荐第二种做法原因很简单/etc/apt/sources.list是系统默认的配置文件系统升级或者某些操作可能会覆盖或修改它。把自定义的源配置放在sources.list.d/目录下与系统默认配置隔离管理起来更清晰出问题了也容易排查。而且这个目录下的文件可以按用途命名比如mirror.list、docker.list、nodesource.list一看就知道每个文件是干什么的。还有一个细节值得注意Ubuntu 从 24.04 开始引入了新的 deb822 格式配置文件放在/etc/apt/sources.list.d/ubuntu.sources格式跟传统的.list文件不一样。不过传统的.list格式目前仍然完全兼容你依然可以用老格式来配置。两种格式可以共存apt 会同时读取。如果你用的是 24.04 或更新的版本可以留意一下这个变化但不必强行迁移。3. 手把手实操从备份到验证的完整流程3.1 操作前的准备工作在动任何配置文件之前先做两件事确认系统版本备份原始配置。确认系统版本是为了知道你的发行版代号是什么这个代号在配置源地址的时候必须写对写错了会导致 apt 完全无法工作。lsb_release -cs这条命令会输出你的发行版代号比如jammy、focal、noble等。记下这个值后面配置的时候要用。如果你用的是比较老的 Ubuntu 版本可能没有lsb_release命令可以用cat /etc/os-release来查看输出里的VERSION_CODENAME就是代号。备份原始配置sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak这一步看起来简单但非常关键。我见过太多人改配置文件改出问题结果没有备份只能重装系统或者到处找默认配置。养成“改配置先备份”的习惯能帮你省下大量时间。3.2 选择合适的镜像站并测试连通性在正式写入配置之前建议先测试一下你打算使用的镜像站的连通性和速度。方法很简单用curl或者wget下载一个测试文件看看响应时间和下载速度。curl -o /dev/null -s -w 连接时间: %{time_connect}s\n下载速度: %{speed_download} bytes/s\n http://mirrors.example.edu.cn/ubuntu/dists/jammy/Release把 URL 里的镜像站地址和发行版代号替换成你实际要用的。这条命令会输出连接时间和下载速度你可以对几个候选镜像站分别测试选表现最好的那个。注意测试的时候要多测几次因为网络状况会有波动单次测试结果不一定准确。提示测试镜像站的时候最好用你实际会使用的协议http 或 https。有些镜像站只支持 http有些同时支持 https。https 更安全但如果镜像站的 https 证书配置有问题反而会导致 apt 报错。3.3 写入新的源配置确认好镜像站之后就可以写入配置了。我推荐的做法是在/etc/apt/sources.list.d/目录下新建一个文件比如叫mirror.listsudo nano /etc/apt/sources.list.d/mirror.list然后把下面的内容写进去注意把jammy替换成你自己的发行版代号把镜像站地址替换成你选好的deb http://mirrors.example.edu.cn/ubuntu/ jammy main restricted universe multiverse deb http://mirrors.example.edu.cn/ubuntu/ jammy-updates main restricted universe multiverse deb http://mirrors.example.edu.cn/ubuntu/ jammy-backports main restricted universe multiverse deb http://mirrors.example.edu.cn/ubuntu/ jammy-security main restricted universe multiverse这里我加了jammy-backports这个仓库包含一些从更新版本回溯移植过来的软件包不是必须的但加上没坏处。如果你不需要源代码包就不用写deb-src行这样可以节省apt update的时间。写完之后把原来的/etc/apt/sources.list里的内容全部注释掉避免重复配置导致冲突。你可以用sed命令批量注释sudo sed -i s/^deb /#deb / /etc/apt/sources.list或者直接用编辑器打开手动在每一行前面加#。注释完之后sources.list文件里应该全是注释行不会生效。3.4 刷新缓存并验证结果配置写好后执行更新sudo apt update如果配置正确你会看到 apt 从你指定的镜像站地址拉取元数据速度应该明显比之前快。输出里会显示每个仓库的Hit、Get、Ign等状态。Hit表示缓存还有效Get表示正在下载新的元数据Ign表示忽略通常是文件不存在或不需要更新。更新完成后可以验证一下当前生效的源apt-cache policy这条命令会列出所有仓库的优先级和地址。你也可以用grep快速检查grep -rh ^deb /etc/apt/sources.list /etc/apt/sources.list.d/这条命令会输出所有生效的deb行你可以确认一下地址是不是你配置的镜像站。最后做一个实际安装测试随便装一个小软件看看下载速度sudo apt install -y htop如果下载速度正常说明配置成功。如果还是慢或者报错就需要排查了。3.5 参数选择与配置细节说明在配置过程中有几个参数和细节值得展开说一下。关于协议的选择http 和 https 各有优劣。https 在传输过程中加密安全性更好但会带来额外的 CPU 开销和握手延迟。对于 apt 源这种公开的、不涉及敏感信息的场景http 其实完全够用而且速度通常更快。不过如果你的网络环境对 http 流量有限制那就必须用 https。我的建议是优先用镜像站官方推荐的协议如果没有特别说明http 和 https 都可以试一下选速度快的那个。关于backports仓库这个仓库里的软件包是从更新的 Ubuntu 版本移植过来的版本比较新但稳定性没有经过充分验证。如果你需要某个软件的新版本而官方仓库里的版本太旧可以启用 backports。但如果你追求稳定可以不加这个仓库。关于deb-src这是源代码仓库。普通用户不需要配置只有当你需要自己编译软件、或者用apt source命令下载源码的时候才需要。启用deb-src会显著增加apt update的数据量和时间因为源代码包的元数据比二进制包大很多。所以除非有明确需求否则不要启用。还有一个容易被忽略的点/etc/apt/sources.list.d/目录下的文件必须以.list结尾才会被 apt 读取。如果你建了一个mirror.conf或者mirror.txtapt 是不会理它的。这个细节看起来不起眼但我见过有人因为这个原因折腾了半天。4. 常见问题与排查技巧实录4.1 apt update 报错的典型场景与处理配置 apt 源的过程中最容易遇到的问题就是apt update报错。下面整理了几种最常见的报错信息和对应的排查思路。报错信息可能原因排查方法Could not resolve mirrors.example.edu.cnDNS 解析失败或镜像站域名写错用ping或nslookup测试域名解析Connection timed out网络不通或镜像站不可达用curl测试镜像站连通性404 Not Found发行版代号写错或仓库路径不对检查lsb_release -cs的输出和配置文件里的代号Hash Sum mismatch元数据缓存损坏或镜像站同步不完整执行sudo apt clean后重新apt updateNO_PUBKEY缺少仓库的 GPG 公钥用apt-key或gpg导入对应的公钥Repository does not have a Release file仓库配置不完整或镜像站未同步该仓库检查仓库地址和组件名称是否正确Hash Sum mismatch这个报错特别常见尤其是在镜像站正在同步的时候。镜像站从官方源同步数据需要时间如果同步到一半你去拉元数据就可能拿到不完整的文件导致哈希校验失败。解决办法很简单等几分钟再试或者换一个同步状态正常的镜像站。你也可以执行sudo apt clean清空本地缓存然后重新apt update。NO_PUBKEY报错通常出现在添加第三方仓库的时候比如 Docker、Node.js 的官方仓库。这些仓库用自己的 GPG 密钥签名你需要先把公钥导入到系统里。导入的方法根据 Ubuntu 版本不同有所差异老版本用apt-key add新版本推荐用gpg配合signed-by参数。具体的操作方式可以参考对应仓库的官方文档。4.2 镜像站同步延迟导致的问题镜像站不是实时同步的通常每隔几小时同步一次。如果你在官方源刚发布了一个安全更新而镜像站还没同步过来你执行apt update的时候就看不到这个更新。这种情况在安全更新发布后的几个小时内比较常见。如果你对安全更新的时效性要求很高可以临时切换回官方源来获取最新更新等镜像站同步后再切回来。或者你可以配置多个源把官方源和镜像源都写上apt 会从所有源里找最新的版本。不过这样做会增加apt update的时间而且如果两个源的版本不一致可能会引起一些奇怪的问题。我的建议是日常用镜像源遇到紧急安全更新的时候临时切官方源。还有一种情况是镜像站的某个仓库组件没有同步。比如某些镜像站只同步了main和universe没有同步multiverse。如果你需要安装multiverse里的软件就会找不到。所以在选择镜像站的时候最好先确认一下它覆盖了哪些仓库组件。大多数主流镜像站都是全量同步的但一些小型的、个人维护的镜像站可能不全。4.3 多源配置的冲突与优先级管理有时候你需要同时配置多个 apt 源比如系统源用镜像站Docker 源用官方源Node.js 源用另一个镜像站。这种情况下不同源之间可能会产生冲突比如同一个软件在多个源里都有版本还不一样。apt 有一套优先级机制来决定从哪个源安装软件。优先级信息可以在/etc/apt/preferences文件里配置也可以通过apt-cache policy命令查看当前生效的优先级。默认情况下所有源的优先级都是 500apt 会选择版本号最高的那个。如果版本号相同则按照源在配置文件里的顺序来选择。如果你发现某个软件安装的版本不对可以用apt-cache policy 包名来查看各个源提供的版本和优先级然后通过Pin机制来调整。不过对于大多数日常使用场景不需要这么精细的控制保持默认行为就好。注意添加第三方源的时候一定要确认这个源的可靠性和安全性。不可信的源可能包含恶意软件包安装后会对系统安全造成威胁。只添加你信任的、有良好声誉的源。4.4 我踩过的几个坑和独家建议第一个坑有一次我在一台生产服务器上直接编辑sources.list改到一半网络断了SSH 会话中断文件处于半写状态。结果 apt 完全不能用只能通过其他方式恢复。从那以后我改任何配置文件都用sudo tee或者先写到临时文件再mv过去避免写入过程中断导致文件损坏。第二个坑有次帮朋友配置 apt 源他用的 Ubuntu 版本比较老我按照新版本的格式写了配置结果发行版代号对不上apt 报了一堆 404。后来才发现他的系统是 18.04代号是bionic而我写的是focal。所以再次强调配置之前一定要确认发行版代号。第三个坑某些云服务商的 Ubuntu 镜像默认就配置了内部源这些源只能在云服务商的网络内访问。如果你把这样的机器迁移到其他网络环境apt 就会失效。遇到这种情况需要把源地址改成公网可访问的镜像站。我的独家建议是配置完 apt 源之后不要只跑一次apt update就完事。多跑几次观察速度是否稳定。然后在不同时间段测试因为网络状况会随时间变化。如果某个镜像站在你常用的时间段表现不好就换一个。另外把配置好的sources.list.d/mirror.list文件备份一份到你的笔记或者配置管理工具里下次装新机器的时候直接复制过去省时省力。5. 进阶话题自动化配置与版本迁移5.1 用脚本一键完成 apt 源配置如果你经常需要给多台机器配置 apt 源手动操作就太慢了。写一个简单的 shell 脚本把配置过程自动化是一个很实用的做法。脚本的核心逻辑就是检测发行版代号、备份原配置、写入新配置、刷新缓存。#!/bin/bash set -e MIRRORhttp://mirrors.example.edu.cn/ubuntu CODENAME$(lsb_release -cs) BACKUP_DIR/etc/apt/backup_$(date %Y%m%d_%H%M%S) mkdir -p $BACKUP_DIR cp /etc/apt/sources.list $BACKUP_DIR/ 2/dev/null || true cp -r /etc/apt/sources.list.d $BACKUP_DIR/ 2/dev/null || true cat /etc/apt/sources.list.d/mirror.list EOF deb $MIRROR $CODENAME main restricted universe multiverse deb $MIRROR $CODENAME-updates main restricted universe multiverse deb $MIRROR $CODENAME-backports main restricted universe multiverse deb $MIRROR $CODENAME-security main restricted universe multiverse EOF sed -i s/^deb /#deb / /etc/apt/sources.list apt update这个脚本做了几件事把原始配置备份到一个带时间戳的目录里写入新的镜像源配置注释掉原来的sources.list最后执行apt update。脚本里用了set -e任何一步出错都会停止执行避免把系统搞得更乱。你可以把这个脚本保存成setup-apt-mirror.sh加上执行权限以后在新机器上直接跑就行。当然脚本里的镜像站地址和发行版代号需要根据实际情况调整。如果你想让脚本更智能可以加上镜像站连通性测试的逻辑自动选择最快的镜像站。5.2 系统大版本升级后的源配置迁移Ubuntu 每两年发布一个 LTS 版本很多人会在新版本发布后升级系统。升级之后apt 源的发行版代号需要从旧的改成新的否则 apt 会找不到对应的仓库。比如从 20.04 升级到 22.04代号从focal变成jammy。如果你用的是传统格式的配置文件需要把所有focal替换成jammy。可以用sed批量替换sudo sed -i s/focal/jammy/g /etc/apt/sources.list.d/mirror.list但要注意如果你的配置文件里还有其他包含focal字样的内容比如某个第三方源的 URL 里恰好有这个词也会被替换掉。所以执行之前最好先grep确认一下grep -n focal /etc/apt/sources.list.d/mirror.list确认无误后再执行替换。替换完成后执行apt update验证。如果报 404说明代号可能写错了或者镜像站还没有同步新版本的仓库。对于使用 deb822 格式的 Ubuntu 24.04 及以上版本配置文件在/etc/apt/sources.list.d/ubuntu.sources格式是这样的Types: deb URIs: http://mirrors.example.edu.cn/ubuntu/ Suites: noble noble-updates noble-backports noble-security Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg这种格式更结构化修改的时候直接改URIs和Suites字段就行。Signed-By指定了用于验证仓库签名的密钥文件这个一般不需要改。5.3 容器与虚拟机环境下的源配置差异在 Docker 容器或者虚拟机里配置 apt 源跟在物理机上有些差异。Docker 容器通常基于精简的 Ubuntu 镜像里面可能没有lsb_release命令也没有nano或vim编辑器。你需要先装这些工具或者用其他方式获取发行版代号。在容器里获取发行版代号可以读/etc/os-release文件. /etc/os-release echo $VERSION_CODENAME这条命令会直接输出代号不需要额外安装任何工具。写入配置文件的时候如果容器里没有编辑器可以用cat配合重定向cat /etc/apt/sources.list.d/mirror.list EOF deb http://mirrors.example.edu.cn/ubuntu/ jammy main restricted universe multiverse deb http://mirrors.example.edu.cn/ubuntu/ jammy-updates main restricted universe multiverse deb http://mirrors.example.edu.cn/ubuntu/ jammy-security main restricted universe multiverse EOF在虚拟机里配置 apt 源跟物理机基本一样。但要注意虚拟机的网络模式如果是 NAT 模式虚拟机的网络流量会经过宿主机转发可能会影响 apt 的下载速度。如果是桥接模式虚拟机相当于独立设备网络表现跟物理机一致。如果你在虚拟机里发现 apt 特别慢可以先检查一下网络模式。另外在构建 Docker 镜像的时候很多人会在 Dockerfile 里配置 apt 源。这时候要注意配置源的步骤应该放在apt install之前而且最好把apt update和apt install放在同一个RUN指令里避免缓存层导致源配置不生效。这是一个很常见的坑我见过不少人在 Dockerfile 里分开写RUN apt update和RUN apt install结果安装的时候用的还是旧的源。5.4 源配置的长期维护策略apt 源不是配置一次就永远不用管的。镜像站可能会变更地址、停止服务或者调整同步策略。你需要定期检查一下源配置是否还有效。一个简单的检查方法是定期执行apt update观察是否有报错。如果某个源持续报错就需要考虑更换。另外关注你使用的镜像站的公告有些镜像站会在维护前发布通知提前知道可以避免措手不及。如果你管理多台机器可以考虑用配置管理工具来统一管理 apt 源配置。比如 Ansible 可以用apt_repository模块来管理源Puppet 和 Chef 也有对应的资源类型。这样当镜像站地址变更时只需要改一处配置所有机器都能同步更新。对于个人用户来说最简单的维护策略就是把配置好的源文件保存一份到云笔记或者代码仓库里每次装新系统的时候直接复制。同时每隔几个月检查一下镜像站是否还在正常服务如果发现速度变慢或者经常报错就换一个。这个习惯花不了多少时间但能避免很多突发问题。6. 一些补充的实操细节和体会关于 apt 源的配置还有一些零散但实用的细节值得提一下。apt update的输出里每个仓库前面会有一个状态标记Hit表示本地缓存还有效Get表示正在下载新数据Ign表示忽略。如果你看到大量Ign可能是仓库配置有问题或者镜像站上没有对应的文件。Err则表示出错了需要重点关注。apt update的速度不仅取决于镜像站还跟本地 DNS 解析速度有关。如果你发现连接建立很慢可以尝试在/etc/hosts里把镜像站的域名和 IP 直接映射跳过 DNS 查询。不过镜像站的 IP 可能会变所以这个方法只适合临时加速不适合长期使用。还有一点apt update和apt upgrade是两个不同的操作。update只刷新元数据upgrade才会实际升级软件包。很多人把这两个搞混以为apt update就是升级系统。实际上定期执行apt update apt upgrade才是保持系统更新的正确姿势。如果你用的是 Ubuntu 桌面版系统会自动提醒你有更新可用但服务器版通常需要手动执行。我在实际使用中的体会是apt 源配置这件事看起来简单但细节很多。不同的 Ubuntu 版本、不同的网络环境、不同的使用场景都可能需要不同的配置方式。最重要的不是记住某个具体的配置而是理解 apt 的工作原理知道出问题的时候从哪里入手排查。掌握了这些不管遇到什么情况你都能自己找到解决办法。最后分享一个小技巧如果你不确定某个镜像站是否包含你需要的仓库组件可以直接用浏览器或者curl访问镜像站的目录列表。比如访问http://mirrors.example.edu.cn/ubuntu/dists/jammy/看看里面有没有main、universe、multiverse这些目录。有的话就说明这个镜像站同步了对应的组件可以放心使用。这个方法比盲目配置然后报错再排查要高效得多。