服务器上跑着yum install进度条卡了快十分钟最后报了个Cannot retrieve metalink for repository: epel. Please verify its path直接中断。这种事放在国内网络环境下真的不算稀奇默认的 CentOS 官方源服务器在境外跨海链路延迟不说还经常性丢包一个 1MB 的 rpm 包下到一半就断开重试。后来我把全线机器都换成阿里云镜像源之后装包时间从去泡杯咖啡等着变成了倒杯水的功夫就完事这个差距不是心理作用是实打实的体感。这篇文章就把 CentOS 更新 yum 源为阿里云这件事从头到尾讲透包括 repo 文件到底是怎么工作的、动手前怎么判断自己的系统版本、具体切换步骤以及换完源之后几乎每个人都会遇到的那几个坑和对应的排查方法。不管你是刚接触 Linux 的新手还是被默认源折磨了一段时间的运维照着操作基本都能顺利落地。1. 为什么 yum 源要搬家默认源在国内的慢性病1.1 慢的不只是下载速度还有元数据获取很多人以为换 yum 源只是让下载 rpm 包的速度变快其实影响最大的反而是第一步获取 repomd.xml 和元数据文件。默认的 CentOS-Base.repo 里配置的是mirrorlisthttp://mirrorlist.centos.org这种动态镜像列表yum 每次执行都要先去访问这个列表再根据返回的信息选择具体镜像站。这个过程在境外服务器上往返好几次延迟高的时候光是Loading mirror speeds from cached hostfile就能卡住好一阵子。实际表现就是你敲下yum install nginx之后终端要么一直停在 Receiving HTTP headers要么反复输出 Trying other mirror。等真正开始下载包的时候又因为跨境带宽被限速速度只能维持在几十 KB 每秒。如果是安装 gcc、docker-ce 这类依赖链条比较长的包中途断掉一次就得从头再来非常消耗耐心。1.2 换到阿里云源之后到底快了多少我自己的实测感受是在同一台配置很普通的机器上默认源装一个包含几十个依赖包的软件组反复重试三到五次才成功耗时基本在 15 分钟以上。换成阿里云镜像源之后同样的操作大概一分钟左右就完成了。这里面的差距有几个来源一是网络链路从跨境变成了国内直连二是镜像站的带宽资源充足三是元数据获取地址变得固定不再需要去解析动态 mirrorlist。所以换源这件事解决的不只是下载慢这一个问题它同时改善了超时中断、元数据获取失败、镜像选择随机导致的不稳定这几种症状。对于生产环境来说这种稳定性比单纯的速度提升更有价值。1.3 为什么选阿里云而不是其他镜像国内做开源镜像站的服务商不少阿里云镜像站的优势在于覆盖面广、同步频率高、且提供完整的 CentOS 仓库目录结构包括 CentOS 7、CentOS 8、vault 归档版本和 EPEL 扩展源。另外如果你用的是阿里云 ECS还能切换到内网镜像地址既快又不占用公网流量这个细节放到后面的维护章节细说。还有个现实原因很多 Linux 新手教程、自动化脚本里默认用的就是阿里云源社区踩坑经验和案例最多。真遇到问题搜索引擎里搜到的解决方案大概率也是基于阿里云源写的后续排查会省很多事。2. 动手前补两课repo 文件机制与系统版本识别2.1 repo 文件里的字段都在干什么yum 的软件源配置集中在/etc/yum.repos.d/目录下所有以.repo结尾的文件都会被系统读取。一个典型的 repo 文件大概长这样[base] nameCentOS-$releasever - Base baseurlhttp://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled1[base]仓库 ID必须唯一yum repolist显示的就是这个名字name仓库的说明文字不影响功能baseurl仓库的实际地址支持变量是换源时改动最核心的地方gpgcheck1启用 RPM 包签名校验防止包被篡改gpgkey校验时用的公钥文件路径enabled1是否启用这个仓库0表示禁用默认的 CentOS 系统还会带一些其他.repo文件比如CentOS-Media.repo、CentOS-Vault.repo、CentOS-Sources.repo这些默认基本都是enabled0平时不会启用所以换源的时候只处理 Base 源相关文件即可其他文件保留原样也没问题。2.2 $releasever 和 $basearch 是怎么被解析的刚接触 repo 文件的人很容易被$releasever、$basearch这两个变量搞晕。其实它们不是 yum 自动猜出来的而是来自系统本身的信息$releasever主版本号CentOS 7 就是7CentOS 8 就是8由centos-release这个 RPM 包提供的信息决定$basearch硬件架构常见值是x86_64、aarch64由系统的架构信息决定比如baseurlhttp://mirror.centos.org/centos/$releasever/os/$basearch/在 CentOS 7 x86_64 机器上会被解析成http://mirror.centos.org/centos/7/os/x86_64/。阿里云提供的 repo 文件里同样是使用变量来适配不同机器你不必手动把变量改死直接用官方给的配置即可。但如果遇到文件里写了具体版本号的情况比如 CentOS 8.5.2111这种通常意味着该版本已经停止维护需要走 vault 归档路径这个坑我放到第 4 章专门讲。2.3 动手前先确认系统版本和架构换源之前建议先执行下面三条命令把系统信息搞清楚cat /etc/redhat-release cat /etc/os-release | grep VERSION_ID uname -m第一条能直接告诉你当前是 CentOS 7 还是 CentOS 8以及具体的更新版本。第二条看VERSION_ID可以精确到 8.5 这样的数字。第三条看架构绝大多数情况是x86_64。为什么要先确认这个因为 CentOS 7 和 CentOS 8 的 repo 文件内容差别很大CentOS 8 还引入了 BaseOS、AppStream、extras 这种多仓库结构如果拿 7 的配置文件去套 8起步就是错的。另外如果你的系统是 CentOS 8.4、8.5 这种已经停止维护的版本普通路径会失效必须走 vault 源。3. 换源实操备份、下载配置、重建缓存三步走3.1 第一步备份原有 repo给回滚留条退路不管多熟练的运维动系统配置之前备份都是基本素养。yum 源配置虽然不像配置文件损坏那样会造成系统无法启动但万一新的源文件有问题、镜像站临时故障你至少能一秒切回原状。推荐的做法是把原目录整个归档而不是只改文件名mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ ls /etc/yum.repos.d/执行完ls应该只有一个backup目录没有任何.repo文件。这样做的逻辑是换源不只是替换 CentOS-Base.repo 一个文件其他默认 repo 文件里也可能包含 mirrorlist 指向把它们全部移走可以避免历史配置干扰新源。万一之后想回滚把 backup 目录里的文件移回去就行mv /etc/yum.repos.d/backup/*.repo /etc/yum.repos.d/3.2 第二步下载阿里云 repo 文件阿里云镜像站把现成的 repo 文件放在https://mirrors.aliyun.com/repo/目录下直接下载到/etc/yum.repos.d/即可。CentOS 7 系统curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repoCentOS 8 系统curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo注意 CentOS 8 这里用的是Centos-vault-8.5.2111.repo因为 CentOS 8 已经停止维护阿里云把 8 的仓库挪到了 vault 归档目录文件名里带上了具体的版本号。如果你的系统是 8.4 或者其他小版本最好先去https://mirrors.aliyun.com/repo/页面确认一下有没有对应版本的文件也可以直接打开页面看目录列表选择匹配自己版本的那个。下载完之后建议先看一眼文件内容是否正常head -n 20 /etc/yum.repos.d/CentOS-Base.repo如果输出的是正常的[base]、baseurl等配置那就没问题。如果看到的是一堆 HTML 标签说明下载到的是错误页面通常是网络没通或者地址写错了这时候不要继续往下执行先排查网络和源地址。3.3 第三步清空旧缓存重建元数据确认源生效yum 会在本地/var/cache/yum目录里缓存每个仓库的元数据换源之后如果不清缓存后续操作仍然可能引用旧数据甚至出现依赖解析错乱。所以接下来这几步是必须的yum clean all yum makecache在 CentOS 7 上很多人习惯用yum makecache fast这个参数表示只重建未过期的元数据速度更快但刚换完源的情况下建议还是用完整版yum makecache确保所有仓库的信息都被重新拉取。CentOS 8 注意makecache fast参数已经被移除了直接执行yum makecache即可不要画蛇添足。重建完成之后用这个命令验证源是否已经生效yum repolist正常输出里应该能看到类似下面的内容repo id repo name status base CentOS-7 - Base - mirrors.aliyun.com 10,272 extras CentOS-7 - Extras - mirrors.aliyun.com 515 updates CentOS-7 - Updates - mirrors.aliyun.com 3,402只要仓库地址里带mirrors.aliyun.com字样说明阿里云源已经接管了 yum接下来装什么都会走这个国内镜像。4. 换完源最容易踩的坑从 404 到 GPG Key 的完整排查4.1 CentOS 8 换源全员 404停维版本必须走 vault这是最近一两年出现频率最高的坑。很多人拿着四五年前的教程在 CentOS 8 机器上执行curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-8.repo然后yum repolist直接一片红点开报错一看全是 404。根源在于 CentOS 8 的生命周期在 2021 年底就结束了官方不再维护常规仓库路径阿里云也把相关文件移动到了 vault 归档目录。所以老的Centos-8.repo文件指向的路径已经不存在了取而代之的是带具体小版本号的路径比如8.5.2111。排查方法很简单先看服务器的小版本号cat /etc/redhat-release比如输出CentOS Linux release 8.5.2111那就要用Centos-vault-8.5.2111.repo。再用 curl 验证一下页面状态码curl -I https://mirrors.aliyun.com/centos/8/BaseOS/x86_64/os/ curl -I https://mirrors.aliyun.com/centos-vault/8.5.2111/BaseOS/x86_64/os/第一个大概率 404第二个应该返回 200。不要自己去手写 vault 拼路径直接用阿里云 repo 目录里提供的对应文件省心很多。4.2 变量解析出来的版本目录和镜像目录不一致CentOS 7 的仓库路径一直是/7/所以$releasever解析成7就能直接对上。但 CentOS 8 的 vault 目录是8.5.2111这种带后缀的形式$releasever解析出的8根本匹配不到目录于是出现 404。阿里云的 repo 文件里通常会把 baseurl 写成具体版本号这是最稳妥的做法。但如果你喜欢手动改配置一定要记住这种场景下变量反而坏事直接写死版本号就好。比如把 baseurl 写成https://mirrors.aliyun.com/centos-vault/8.5.2111/BaseOS/x86_64/os/不要写成.../centos-vault/$releasever/BaseOS/...因为变量解析不出来正确目录。同理如果你在/etc/yum.repos.d/目录下遗留了多个 repo 文件其中某个文件里$releasever对应的路径已失效整个makecache过程都会表现为部分仓库失败。检查时可以用grep -nr baseurl /etc/yum.repos.d/把每个文件的 baseurl 打出来逐个判断目录是否真实存在。4.3 GPG Key 报错别急着关掉 gpgcheck换源之后执行yum install时有可能会遇到这样的提示Retrieving GPG key from https://mirrors.aliyun.com/.../RPM-GPG-KEY-CentOS-7 GPG key retrieval failed: [Errno -1]这是因为新仓库启用了 gpgcheck但系统本地没有对应的公钥。解决办法是手动导入而不是把 gpgcheck 改成 0rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7CentOS 7 系统里公钥文件常见名是RPM-GPG-KEY-CentOS-7CentOS 8 是RPM-GPG-KEY-CentOS-Official。导入之后重新执行yum install系统会自动从这个源拉取公钥并完成校验。我个人强烈不建议用gpgcheck0来绕过RPM 包签名校验的意义是防止下载的包被第三方篡改。你换源本身就是为了走国内镜像提供的公网下载通道一旦域名解析被污染、镜像站被中间人攻击关闭校验之后装进去的东西就完全没有信任链了。内网测试环境图省事可以理解生产环境千万别这么干。4.4 旧缓存残留导致依赖解析错误换源后偶尔会遇到一种很诡异的情况明明新源地址已经生效但yum install时解析依赖仍然报错提示缺失的依赖包、或者版本冲突。这种问题往往不是源配置不对而是/var/cache/yum里残留的旧元数据和新的不一致。遇到这种状况用常规的yum clean all可能还不够彻底建议直接把缓存目录清掉再重建rm -rf /var/cache/yum/* yum makecache如果出现 Database file is locked 或者提示另一个进程正在占用先确认没有别的 yum 在跑ps -ef | grep yum确认没有遗留进程之后再清理。有时候系统重启后部分锁文件还占着可以把/var/run/yum.pid删掉但要先确认那个进程确实不存在否则会打断正在进行的安装事务。4.5 手动改源时 mirrorlist 没注释白忙一场如果你不是下载阿里云现成的 repo 文件而是想在系统默认文件基础上改 baseurl那一定要注意mirrorlist这一行。yum 判断仓库地址的优先级是如果.repo文件里同时存在mirrorlist和baseurl会优先使用 mirrorlist。很多人只改了 baseurl 没管 mirrorlist结果yum repolist一看走的还是默认镜像源白白折腾。判断方法grep -n mirrorlist\|baseurl /etc/yum.repos.d/CentOS-Base.repo如果 mirrorlist 行首没有#注释号把它注释掉或者直接删除这一行。这也是我推荐直接用阿里云现成配置的另一个原因——官方维护的版本里该注释的已经帮你注释好了不容易踩这种低级坑。4.6 一份自检清单按顺序排查解决九成问题症状可能原因第一步排查命令yum makecache报 404baseurl 指向的路径或版本目录不对curl -I访问报错里的 URL 看状态码下载地址仍然显示官方源mirrorlist 没注释grep -n mirrorlist /etc/yum.repos.d/*.repoGPG key retrieval failed本机没有对应公钥rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7安装时依赖解析错乱旧缓存元数据残留rm -rf /var/cache/yum/* yum makecache某仓库 enabled 了但 status 为 0镜像目录下没有对应架构包打开 baseurl 确认目录结构是否存在按这个顺序走下来几乎每个换源问题都能定位到具体环节而不是毫无头绪地反复重试。5. 验证与维护让阿里云源长期稳定生效5.1 用真实的装包操作验证效果配置完成之后我建议不要只看yum repolist就收工强烈推荐实际安装一个小包做一次全链路验证yum -y install wget vim-enhanced安装过程中留意下载进度和输出日志正常情况下下载速度应该能看到明显提升而且不会再出现 Trying other mirror 的反复重试。如果这条命令顺利走完说明从元数据获取、GPG 校验到包下载的整条链路都是通的。如果你安装了yum-utils还可以用yumdownloader --resolve nginx来验证下载大包时的稳定性这个工具会连带解析所有依赖并逐个下载适合测试源在依赖复杂场景下的表现。5.2 repo 文件的日常保养注意事项换好源之后有几个日常使用习惯值得养成。一是不要随手在/etc/yum.repos.d/里堆积太多来源不明的 repo 文件。有些教程会让人同时启用多个第三方源一旦仓库之间存在依赖冲突yum解析时就会疯狂尝试组合最后往往给出一个莫名其妙的错误。源要按需添加命名清晰不用的直接删。二是理解metadata_expire参数。其实 yum 会定期自动重新拉取元数据默认的过期时间足够日常使用你不需要每次装包之前都手动yum makecache。只有在源配置变更、或者怀疑元数据不新的时候才需要手动重建频繁清缓存反而浪费时间。三是不要在/etc/yum.repos.d/手动删掉系统其他源文件之前不做备份。有些云厂商镜像、虚拟化环境会自带一些定制源文件比如 epel、docker-ce 等其他仓库这些文件对你的日常装包有实际作用。判断一个 repo 文件是否有用看yum repolist的 status 列是否大于 0 即可status 为 0 的可以考虑禁用而不是直接删除。5.3 配合 EPEL 源和云服务器环境的小经验CentOS 默认源里的软件数量有限很多常用软件要用到 EPEL 扩展仓库。阿里云同样提供了 EPEL 的 repo 文件curl -o /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-7.repoCentOS 8 系统用epel-8.repo替换文件名。装完 EPEL 之后同样执行一遍yum clean all yum makecache让两个源都进入可用状态。另外如果你用的是阿里云 ECS还有一个细节部分地域提供内网镜像域名mirrors.cloud.aliyuncs.com把 repo 文件里的 baseurl 替换成内网地址之后既不需要经过公网速度还会更快且不产生公网流量费用。判断是否支持的方法是直接访问一下curl -I http://mirrors.cloud.aliyuncs.com/centos/7/os/x86_64/能正常响应就说明该地域支持直接替换即可。如果是自建机房或者本地虚拟机保持原有的公网阿里云地址就好没必要强行换内网域名。最后分享一下我自己的操作习惯新机器落地配置的时候顺序永远是先备份原有 repo再替换阿里云 Base 和 EPEL 源然后makecache最后yum repolist确认源数量和地址都对才会开始正式装包。这套流程跑得多以后基本不会遇到问题偶尔翻车也逃不出第 4 章那几个坑的范围按清单排查比重新折腾一遍快得多。