新装完 Ubuntu第一件事永远是装软件。但只要你敲下sudo apt update大概率会撞上一面墙要么卡在0% [Waiting for headers]半天不动要么干脆Could not resolve archive.ubuntu.com再要么就是慢到让你怀疑人生。这时候老手都会告诉你换源。所谓软件源Software Repository就是 Ubuntu 获取软件包的远端仓库地址。默认指向国外官方服务器网络环境差一点连接就是灾难。这篇文章专门讲怎么把 Ubuntu 的软件源切到阿里云镜像把apt恢复到“秒级响应”的状态。内容不是简单抄几条命令就完事还包括我这些年实际踩过的坑20.04 老办法什么时候失效、24.04 的deb822新格式怎么处理、换源之后Hash Sum mismatch又是怎么回事。不管是刚入门的 Linux 用户还是在服务器上反复折腾运维的开发者这都能帮你少走几趟弯路。1. 软件源到底是个什么东西为什么官方源这么难连1.1 和 apt、sources.list 之间的关系很多人把“换源”理解成“改一个配置文件”这没错但理解得稍微深一点会更好。Ubuntu 用的是apt包管理体系它从/etc/apt/sources.list和/etc/apt/sources.list.d/目录下的文件里读取软件仓库地址。所谓的源就是一段形如deb http://archive.ubuntu.com/ubuntu/ jammy main restricted universe multiverse的配置行。这行配置告诉apt三件事从哪个服务器下载、下载哪个发行版代号、要哪些软件包类别。Ubuntu 的官方仓库域名有好几个除了最常用的archive.ubuntu.com还有security.ubuntu.com安全更新、ports.ubuntu.comARM 等非 x86 架构等。这些服务器基本都在境外绕了大半个地球的流量随机丢包、连接重置都是家常便饭。打个比方官方源就是一家远在万里之外的供应商仓库每次进货都要长途跋涉等货周期长且充满不确定性。镜像源相当于在国内建了一个大型分销仓把供应商的商品全部同步一份囤在本地进货距离一下缩短到几十毫秒。1.2 不同版本的代号对应关系Ubuntu 每个发行版都有自己的代号这个代号就是源配置里的“套件名”。你写配置之前必须先搞清楚自己系统用的是什么代号这个可以在终端里执行lsb_release -a查看。我列一张常用对照表方便你直接对号入座Ubuntu 版本代号支持状态24.04 LTSnoble当前 LTS主推23.10mantic已停止维护不建议用22.04 LTSjammy稳定 LTS用户量大20.04 LTSfocal上一代 LTS仍在维护18.04 LTSbionic已停止维护老用户尽量升级不同代号的源配置不能混用。比如你在 22.04 上写了focal的源理论上也能跑但apt会认为你在请求另一个发行版的包依赖解析很容易出问题。所以无论是手改还是用工具第一件事永远是确认代号。1.3 镜像源的工作原理与同步机制阿里云镜像站本质上就是一个高频同步的拷贝仓库。它通过定时任务从 Ubuntu 官方仓库抓取元数据和.deb软件包一般几小时到一天同步一次。同步期间上游文件如果有变动镜像站会在下一个同步周期补上不会影响日常使用。这也解释了为什么你换了阿里云源之后apt update看到的软件包版本可能和官方源有极短时间的差异这属于正常现象。绝大多数情况下这种时差不会影响你安装任何软件。2. 为什么选阿里云源而不是其他镜像2.1 镜像站那么多怎么选国内可用的 Ubuntu 镜像不止阿里云一家还有清华 TUNA、中科大 USTC、华为云等。这些镜像质量都不错选哪个其实都不亏。但如果你要我在它们之间给出一个明确的推荐我会默认推荐阿里云理由很简单阿里云镜像站的带宽储备在高峰期表现稳定且在国内各个运营商的互联互通上做了比较充分的优化。清华和中科大的源学术气息浓更新频率也很及时但访问速度取决于你所在网络和校园网的互联带宽。相比之下阿里云镜像站在商业带宽上有明显优势尤其是晚高峰时段apt update的速度基本还能保住。这个差距不是概念级而是体感级的。2.2 阿里云源的结构与优势细节阿里云 Ubuntu 镜像的地址是http://mirrors.aliyun.com/ubuntu/支持 HTTP 和 HTTPS 两种协议推荐用 HTTPS可靠性更高。它的目录结构和官方源保持一致常见路径如下dists/存放发行版元数据即升级信息、包索引pool/存放真正的.deb软件包实体ls-lR.gz目录索引文件apt update拉取的是dists下的元数据apt install才从pool下载实体包。理解了这一点你就明白为什么每次只是改个源文件不需要重新安装软件因为软件包依赖关系没变只是下载的来源变了。2.3 服务器与个人电脑的使用场景差异如果你用的是阿里云 ECS 服务器还有一个隐藏福利可以把源地址改成内网镜像地址mirrors.cloud.aliyuncs.com走内网流量不占用公网带宽速度媲美本地磁盘。这个地址只有阿里云内网的机器能访问家用电脑和别的云服务器用不了。判断方式很简单在 ECS 上curl一下通不通就行。如果你的机器是别的云厂商老老实实用公网镜像地址。个人电脑和服务器换源的操作流程完全一样区别只在于你需要不需要考虑内网带宽配额。如果服务器是做业务流量的软件源占用的带宽虽然小但能省一点是一点。3. 常规做法手把手把 22.04 及以下版本切到阿里云源3.1 备份永远是最重要的一步在动手改任何系统配置之前先把原来的文件备份好。这是一个老生常谈但永远有人不做的问题。有人觉得“我记住怎么改回来就行了”结果真出了问题连原始文件长什么样都忘了。备份只需要一行命令sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak如果后续操作出了问题执行sudo cp /etc/apt/sources.list.bak /etc/apt/sources.list就能一键还原。这个备份成本极低收益极高。顺便提一句任何配置文件修改前都建议做类似的备份这是系统运维的基本素养。3.2 确认系统代号这一步的作用前面说过了直接执行lsb_release -a在 22.04 上你会看到Codename: jammy。以jammy为例下面所有配置里的jammy字样都要替换成你自己的版本代号。3.3 写入阿里云源配置传统改法就是把sources.list里的官方域名替换成阿里云域名。你可以直接编辑文件或者用sed一条命令完成替换sudo sed -i s//.*archive.ubuntu.com//mirrors.aliyun.comg /etc/apt/sources.list sudo sed -i s/security.ubuntu.com/mirrors.aliyun.com/g /etc/apt/sources.list第一条命令把archive.ubuntu.com替换成mirrors.aliyun.com第二条把安全更新源也替换掉。注意第一个sed里用了作为分隔符不是笔误是因为 URL 里本身就包含/如果还用/当分隔符写起来会非常痛苦。如果你不想用sed也可以直接编辑文件。22.04 的sources.list修改后应该长这样deb http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse这里有四个 main 开头的组件说明一下main是官方支持的自由软件restricted是官方支持的非自由软件universe是社区维护的自由软件multiverse是非自由软件。正常使用建议把这四个组件全部写上因为很多常用软件在universe组件里。比如你要装一些字体、编解码器缺了universe就会提示无法定位软件包。3.4 更新软件包索引配置写完以后执行sudo apt update如果一切正常你会看到从mirrors.aliyun.com拉取包索引列表速度明显比官方源快。跑完update之后我建议顺手执行一次sudo apt upgrade把系统软件包整体升级到最新版本。提示如果apt update过程中出现权限不足的错误看看是不是源文件属主和权限不对。正常情况下应该是root:root权限-rw-r--r--。3.5 验证是否真正生效这一步很多人会忽略。验证的方法很简单apt update结束后看输出信息里的服务器地址是不是mirrors.aliyun.com。还可以用下面这条命令确认实际下载速度time sudo apt update如果你发现update完成时间从之前的几分钟缩短到几秒到十几秒那说明源已经切换成功。如果是服务器顺手记一下下载日志里的耗时以后做对比判断网络质量时就有数据支撑。4. Ubuntu 24.04 的新坑deb822 格式源配置4.1 为什么 24.04 不按老套路来如果你是新装的 Ubuntu 24.04按照老教程去修改/etc/apt/sources.list你会发现文件里只剩下一行注释# See https://wiki.ubuntu.com/AppArmor之类的内容真正生效的源配置跑到了/etc/apt/sources.list.d/ubuntu.sources。这不是 Ubuntu 故意刁难人而是从 24.04 开始Ubuntu 全面转向了 Debian 的deb822多行格式。这种格式用字段名 值的方式描述软件源比传统的一行式写法更结构化可读性和可扩展性都更好。传统格式deb http://archive.ubuntu.com/ubuntu/ noble main restricted新格式Types: deb URIs: http://archive.ubuntu.com/ubuntu/ Suites: noble noble-updates noble-backports Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg如果你在 24.04 上强行修改旧的sources.list虽然系统也能识别但官方已经明确不推荐这种方式未来版本大概率会彻底移除。所以既然用了新系统就该用新写法。4.2 24.04 的阿里云源配置方法阿里云镜像站对 24.04 也提供了对应的deb822格式源文件可以直接下载覆盖sudo curl -fsSLo /etc/apt/sources.list.d/ubuntu.sources https://mirrors.aliyun.com/ubuntu/dists/noble/noble.list这条命令的意思是把阿里云生成的noble.list文件下载到/etc/apt/sources.list.d/ubuntu.sources位置。执行完以后打开文件你会看到里面就是上面展示的deb822格式URIs已经指向了mirrors.aliyun.com。然后照常执行sudo apt update这里有个细节值得注意noble.list文件名里的 list 后缀不要纠结它本质上就是ubuntu.sources的一个变量名。下载后是否保留原文件名其实无所谓关键是在/etc/apt/sources.list.d/目录下有一个.sources后缀的文件apt就会按deb822格式读取。4.3 两种格式的对比与迁移建议我把两种格式放在一起对比一下方便你理解对比项传统 sources.list 格式deb822 格式配置文件位置/etc/apt/sources.list/etc/apt/sources.list.d/*.sources书写方式单行紧凑多行字段式可读性一般较好支持组件配置每行一套同一文件多套官方推荐度即将淘汰新版本力推如果你是从 22.04 升级到 24.04升级过程会自动帮你把源文件迁移成新格式。但如果你是自己手改的旧配置建议在升级前先备份好原文件升级后再检查/etc/apt/sources.list.d/下有没有生成新的配置文件避免新旧配置重叠引发冲突。我在实际测试里遇到过一个情况系统升级后同时存在/etc/apt/sources.list里的旧配置和新格式的ubuntu.sources导致apt update把同一个软件源加载了两遍。解决办法很简单把旧配置注释掉或者直接把sources.list内容清空只保留新格式文件。5. 换源之后最常碰到的 5 个报错每一个都有解5.1 最常见Hash Sum mismatch换源后执行apt update偶尔会看到类似E: Failed to fetch ... Hash Sum mismatch的报错。这个问题最经典的原因是你本机系统时间不对。因为apt在下载文件时会校验时间戳系统时间偏差过大就会认为文件过期或不合法。解决办法sudo apt install ntpdate sudo ntpdate ntp.aliyun.com如果安装ntpdate有困难也可以用date -s手动把系统时间调整到当前时间附近。系统时间校准后重新执行sudo apt update大概率就好了。除了时间问题Hash Sum mismatch 偶尔也出现在镜像站同步过程中文件不完整的情况。等几分钟再试一次或者清缓存sudo rm -rf /var/lib/apt/lists/* sudo apt update5.2 404 Not Found 报错apt update时报 404十有八九是源配置里的代码和实际仓库路径对不上。比如在 24.04 上还留着focal的源地址服务器找不到这个路径就会返回 404。解决思路就一句话确认你的系统版本代号然后把所有源配置里的代号列出来逐条核对。注意检查的不只是/etc/apt/sources.list还有/etc/apt/sources.list.d/目录下所有的源文件特别是某些第三方软件源的残留配置。这些残留源一旦失效会直接导致整个apt update报错。5.3 公钥或签名验证失败有时候换源之后会遇到The following signatures couldnt be verified because the public key is not available通常是因为系统缺少对应的 GPG 公钥。在 22.04 及以下版本可以这样解决sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 公钥ID不过apt-key这种方式在新版 Ubuntu 里已经不建议使用了更推荐通过下载官方密钥文件来导入sudo gpg --keyserver keyserver.ubuntu.com --recv-keys 公钥ID sudo gpg --export 公钥ID | sudo tee /etc/apt/trusted.gpg.d/自定义名字.gpg /dev/null这里需要多说一句如果你用的是阿里云源的官方地址通常不存在公钥问题因为系统自带了 Ubuntu 官方密钥。报公钥错误大多数情况是你还在用旧的第三方源配置文件这时候直接把第三方源删掉或注释掉清理干净比想办法补公钥更靠谱。5.4 某些软件一直无法定位apt install xxx提示Unable to locate package这种情况通常不是因为源有问题而是因为软件在universe或multiverse组件里而你的源配置只启用了main和restricted。我见过有人装多媒体解码器装不上检查半天发现自己的源文件里根本没有universe。解决办法很简单把四个组件全部补上。这条配置在deb822格式里就对应Components: main restricted universe multiverse这一行。5.5 换源后 PPA 失效如果你日常安装过第三方软件系统里会有 PPA 源。apt update时可能会因为 PPA 官方源连接失败导致整个更新流程变慢甚至卡住不动。遇到这种情况最直接的办法是检查/etc/apt/sources.list.d/下对应 PPA 文件把不需要的 PPA 禁用或删除。如果确认还需要这个 PPA但更新实在太慢可以考虑把 PPA 的域名也替换成可访问的镜像地址。不过 PPA 镜像的维护成本较高大多数情况下我还是建议能不用第三方 PPA 就不用尽量用官方源和通用软件源替代。把常见问题整理成一张速查表方便你直接对照报错现象主要原因快速解决Hash Sum mismatch系统时间不准确或镜像同步中校准时间、清缓存重试404 Not Found版本代号写错核对代号清理残留源公钥签名验证失败缺少 GPG 公钥或残留第三方源导入公钥或禁用第三方源Unable to locate package组件配置缺失补全 main restricted universe multiverse更新卡住不动第三方 PPA 源不通禁用无用 PPA6. 换完源之后还应该做这几件事6.1 更新软件包到最新状态换源之后我建议尽快把系统里的软件包进行一次整体升级。很多人换了源只跑apt update不跑apt upgrade这样旧源里缓存的包索引可能和新源不一致后续安装软件时可能出现怪异的依赖冲突。执行一下sudo apt full-upgrade这个命令和apt upgrade的区别在于它会谨慎处理依赖变化可能安装或移除极少数包来满足新依赖。跑完之后系统软件包基本就是全新状态和镜像源的同步状态对齐。6.2 清理残留的旧配置和缓存如果系统之前长期用官方源/var/cache/apt/archives/下可能积攒了大量.deb安装包缓存这些缓存占了硬盘空间而且已经没用了。换源后可以顺手清空sudo apt clean如果想更彻底一点还可以把/var/lib/apt/lists/里的旧源索引清掉重新生成sudo rm -rf /var/lib/apt/lists/* sudo apt update清理缓存这个操作不会影响已安装的软件不用担心。6.3 给新人几个避坑锦囊换源这事儿看似简单实际翻车场景集中在三个点上版本代号写错、源格式用混、第三方源残留。针对这三点我总结几个非常直白的经验不要在服务器业务高峰期动源文件万一改挂了要紧急回滚高峰期操作压力更大。改了源之后的第一波apt update输出结果要仔细看如果有红字报错就停下来排查不要硬着头皮继续装软件。如果输出结尾显示Reading package lists... Done且没有E:开头的行才算真正成功。如果你在 Docker 镜像里构建环境建议直接在 Dockerfile 里写阿里云源替换命令这样每次构建基础镜像都会自动使用国内源省时省力。7. 写在最后的实际操作体会换源这件事我从最早的 14.04 一路折腾到现在的 24.04最大的体会是源的正确性比源的速度更重要。很多人一上来就急着找一个“最快的源”反而忽略了配置是否匹配自己的系统版本。一个写错的代号哪怕速度再快也是白搭。另外多留一个心眼。每次改完源文件都先跑一遍apt update再装新软件确认输出没有关键报错。如果机器上有重要服务建议先做一次快照或备份再动系统配置文件。这是我个人习惯算不上多高明的技巧但确实帮我避免了好几次不必要的麻烦。如果你手头有旧服务器还在用 18.04、20.04我的建议是尽快规划升级到 22.04 或 24.04老版本的系统源已经停服很久了装上阿里云源也只能拉到历史遗留包安全和功能都跟不上。换源只是治标跟上 LTS 节奏才是治本。