CentOS 7.9停服后如何换阿里源？yum仓库配置与排错全指南

1. 不换源真不行：CentOS 7.9官方仓库停服后的连锁反应

接手一台CentOS 7.9服务器，我建议你第一件事先看yum源。很多人新装完系统，习惯性敲一句yum install -y vim，等了好几分钟才发现要么卡在"Loading mirror speeds from cached hostfile"，要么直接报"Could not resolve host: mirrorlist.centos.org"。原因说白了就一条：CentOS 7在2024年6月30日已经正式停止维护，官方把相关软件包全部挪去了centos-vault归档目录，原来默认仓库文件里指向mirrorlist.centos.org的地址基本都失效了。所谓换源，本质上就是让yum客户端去它该去的仓库拉取元数据和软件包，而阿里源是目前国内使用最广、维护最积极的镜像站之一，提供完整的vault归档目录和epel扩展源，延迟和带宽都比直连国外镜像有明显优势。这篇文章我就把CentOS 7.9换阿里源的完整过程、背后的原理、以及换完之后你会遇到的高频报错一次性讲清楚。

1.1 官方仓库停更后的三个直接后果

第一个后果是默认repo文件变成"死链"。新装或老旧的CentOS 7.9系统，/etc/yum.repos.d/CentOS-Base.repo里默认配的是mirrorlist.centos.org，这个域名在EOL之后不再维护，yum解析不到可用地址，自然就报错。即使能解析，原来mirror.centos.org/centos/7/路径下的包也被搬走，返回的是404页面而非repodata数据。

第二个后果是软件版本冻结。CentOS 7停止维护意味着不再有安全更新和bug修复，所有软件包停留在官方最后维护的版本上。yum源里用的$releasever变量会被系统解析成"7"，但vault目录实际存放的路径是7.9.2009这样的完整版本号，这两者之间差了一步，很多人在手动配源时就是栽在这里。

第三个后果是扩展包仓库断裂。CentOS的生态离不开EPEL，但EPEL的默认repo文件里写的是metalink地址，会重定向到fedoraproject.org，国内网络环境下经常连不上超时。你换完base源，如果不处理EPEL，后面装htop、jq、ncdu这类工具依然会卡住。

1.2 为什么大家优先选阿里源

国内可用的镜像站其实不少，清华、中科大、网易都有镜像，但我个人维护的服务器集群基本全用的是阿里源。原因有三点：第一，阿里云有大量CDN节点，在电信、联通、移动跨网络访问时的稳定性明显好于高校镜像站，高峰期也能保持稳定；第二，阿里镜像站把所有发行版的官方repo脚本做成了固定链接，比如https://mirrors.aliyun.com/repo/Centos-7.repo，下载下来就能用，不需要自己去拼路径；第三，针对CentOS 7停服这件事，阿里源专门保留了一套完整的centos-vault目录，版本号精确到7.9.2009，仓库齐全，GPG key也都在，安全性有保证。

1.3 这篇内容能帮你解决什么

如果你是刚入门Linux运维的同行，这篇能帮你搞懂yum仓库的基本结构，知道.repo文件里每项参数是干什么的，换源不再只会复制粘贴。如果你正在处理生产环境，这篇里"换源前备份"和"换源后验证"的操作可以直接照搬，排错章节里的几个典型案例也都是我实际踩过的坑。后面涉及"阿里源已归档路径"的部分对CentOS 7.9是通用有效，换到其他镜像站只要把域名替换掉，思路完全一致。

2. 换源前的地基：版本确认、repo备份和缓存清理

很多教程上来就让你下载repo文件，我把这一步放到后面是有原因的。换源本质上是一次"配置变更"，变更前不知道当前环境是什么版本、什么架构、有哪些源，出了问题根本没法回滚。我在生产环境操作过的几百台机器里，至少有三四次出现过"下载新repo文件后把所有源都搞没"的情况，如果之前没留备份，光是重建repo文件就能让人崩溃。

2.1 先确认系统版本和CPU架构

用下面三条命令把系统的"底细"查清楚：

cat /etc/redhat-release rpm -q centos-release uname -m

输出大致是：

CentOS Linux release 7.9.2009 (Core) centos-release-7-9.2009.0.el7.centos.x86_64 x86_64

这里要注意，/etc/redhat-release显示的是"7.9.2009"，而后续repo文件里baseurl中的$releasever会被解析成小版本"7"，这是个关键差异。uname -m用来确认架构，绝大多数服务器是x86_64，也有少量aarch64，后面写repo路径时要把$basearch或具体架构写对。如果系统连curl都没有，先执行yum install -y curl把基础工具补上。

2.2 备份原有repo文件：防止回滚时抓瞎

我推荐的备份方式是把原有repo文件统一移动到backup目录，而不是原地拷贝：

mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ 2>/dev/null || true

为什么用mv而不用cp？因为yum在读取repo时，/etc/yum.repos.d/目录下所有以.repo结尾的文件都会生效。如果原repo文件和新文件同时存在，未注释的mirrorlist或旧的baseurl会干扰yum的源选择，导致报错信息混乱。全部移走之后目录里干干净净，新的repo文件是唯一生效的配置来源，便于排查。如果需要回滚，把backup目录里的文件移回来即可。

如果有强迫症，也可以给备份目录打个tar包，连文件权限和修改时间一起保留：

tar czf /root/yum.repos.d.backup.tar.gz -C /etc/yum.repos.d backup

2.3 清理历史缓存：别让旧数据干扰新配置

原repo文件里往往带metadata_expire等缓存策略，yum会把之前下载的元数据缓存在/var/cache/yum/目录。这些缓存里记录的是旧仓库的URL和校验值，换源之后如果不清理，yum可能还会尝试访问旧地址，或者因为缓存里的repomd.xml签名对不上而报错。

执行两遍清理逻辑：

yum clean all rm -rf /var/cache/yum/*

yum clean all会清掉yum自身的metadata缓存，rm -rf是双保险。这一步不是什么高科技，但确实能减少后续排查时的干扰项。

3. 阿里源接入实操：baseurl、vault路径与EPEL扩展源一次讲清

准备工作做完，下面进入正题。这一节我给出两种配置方式：一种是用阿里源官方做好的repo文件一键搞定，适合大多数场景；另一种是手动编写repo文件，适合你需要精确控制仓库内容、或者要批量修改很多台机器配置的场景。两者最终效果一样，但理解了第二种的原理，出问题时你才知道怎么查。

3.1 方式一：直接下载阿里源官方的CentOS 7 repo文件

阿里镜像站维护了一套开箱即用的repo生成脚本，对CentOS 7.9来说，直接执行：

curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo

下载完之后，建议先看一眼内容再继续操作：

cat /etc/yum.repos.d/CentOS-Base.repo

这份文件已经把CentOS 7停服后的问题处理好了：它没有用已失效的mirror.centos.org/centos/7/路径，而是直接指向https://mirrors.aliyun.com/centos-vault/7.9.2009/os/$basearch/，同时gpgkey也指向vault目录下的RPM-GPG-KEY-CentOS-7。所以下载完这一份，base、updates、extras三个核心仓库就都覆盖到了。

3.2 方式二：手动编写repo文件，理解vault与releasever的关系

在某些离线环境或内网机器上，无法直接访问mirrors.aliyun.com/repo/Centos-7.repo，这时需要手动创建repo文件。以下是一份最小可用的/etc/yum.repos.d/CentOS-Base.repo，我已经把原理解释标注在旁边：

[base] name=CentOS-7.9.2009 - Base - aliyun baseurl=https://mirrors.aliyun.com/centos-vault/7.9.2009/os/$basearch/ gpgcheck=1 gpgkey=https://mirrors.aliyun.com/centos-vault/7.9.2009/os/x86_64/RPM-GPG-KEY-CentOS-7 enabled=1 [updates] name=CentOS-7.9.2009 - Updates - aliyun baseurl=https://mirrors.aliyun.com/centos-vault/7.9.2009/updates/$basearch/ gpgcheck=1 gpgkey=https://mirrors.aliyun.com/centos-vault/7.9.2009/os/x86_64/RPM-GPG-KEY-CentOS-7 enabled=1 [extras] name=CentOS-7.9.2009 - Extras - aliyun baseurl=https://mirrors.aliyun.com/centos-vault/7.9.2009/extras/$basearch/ gpgcheck=1 gpgkey=https://mirrors.aliyun.com/centos-vault/7.9.2009/os/x86_64/RPM-GPG-KEY-CentOS-7 enabled=1

注意我在这里把仓库名里直接写了7.9.2009，而不是用$releasever。这是个非常容易踩的坑：系统默认的$releasever是"7"，如果写成baseurl=https://mirrors.aliyun.com/centos-vault/$releasever/os/$basearch/，网址会变成/centos-vault/7/os/，而实际目录是/centos-vault/7.9.2009/os/，最后必然404。

有人会用echo "7.9.2009" > /etc/yum/vars/releasever来全局覆盖这个变量，我建议别这么干。因为EPEL仓库的baseurl用的是$releasever，它期望的是"7"而不是"7.9.2009"，全局覆盖会把EPEL一起搞挂。正确做法就是base仓库里写完整的7.9.2009，其他仓库该怎么写怎么写。

3.3 顺手把EPEL扩展源也换了

EPEL全称Extra Packages for Enterprise Linux，是Fedora社区维护的一批高可用软件包仓库。很多系统不内置的工具，比如htop、jq、ncdu、iotop，都在EPEL里，所以它基本上是CentOS生产环境的必备源。

安装EPEL的推荐方式是用阿里源做好的epel repo文件：

curl -o /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-7.repo

如果你的系统里已经有epel-release这个包，也可以用yum install -y epel-release安装，但装完后/etc/yum.repos.d/epel.repo默认配置的是metalink地址，国内网络访问不稳定，建议改成阿里云baseurl。修改后的核心内容：

[epel] name=Extra Packages for Enterprise Linux $releasever - $basearch baseurl=https://mirrors.aliyun.com/epel/$releasever/$basearch/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

这里$releasever可以放心用"7"，因为阿里云的EPEL目录结构就是/epel/7/x86_64/，不存在vault那种版本号漂移问题。

3.4 清理缓存并重建yum元数据

repo文件配置完成后，执行：

yum clean all yum makecache

yum makecache会把各仓库的repomd.xml和元数据下载到本地缓存。如果所有仓库都能正常访问，命令输出里会依次显示base、updates、extras、epel等仓库的缓存完成信息。完成后用yum repolist查看生效的仓库列表，正常情况下应该看到类似这样的输出：

repo id repo name status base/7/x86_64 CentOS-7.9.2009 - Base - aliyun 10,276 epel/7/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 13,731 extras/7/x86_64 CentOS-7.9.2009 - Extras - aliyun 515 updates/7/x86_64 CentOS-7.9.2009 - Updates - aliyun 2,433

最后用一条实际安装命令验证整体链路是否通畅：

yum install -y vim net-tools tree

如果这步顺利完成，说明从DNS解析、网络连接、元数据下载、GPG校验到包依赖解析，整条链路已经全部打通。

4. 换源后的常见报错与定位路径：从404到GPG key过期

换源这个动作本身不难，难的是换完了之后yum还报错。我把自己在线上环境碰到过的几类典型问题整理出来，按"如何看报错、如何定位、如何修复"的顺序写。如果你也遇到类似报错，直接对照处理。

4.1 报错一：404 Not Found，地址还在老路径上

典型报错信息：

https://mirrors.aliyun.com/centos/7/os/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found

出现这个错误的直接原因是你用的repo文件里baseurl还是老的/centos/7/os/路径，而这个路径在阿里源上已经不存在了。报错本身就是最好的定位线索：它把实际请求的URL打了出来，你一眼就能看出路径对不对。

修复方式是把baseurl替换成vault的完整路径：

sed -i 's#mirrors.aliyun.com/centos/$releasever#mirrors.aliyun.com/centos-vault/7.9.2009#g' /etc/yum.repos.d/CentOS-Base.repo

执行后再次yum repolist -v，注意看输出的Repo-baseurl字段是否已经是/centos-vault/7.9.2009/。如果还没有，说明repo内容里有其他变量干扰，直接vi打开repo文件人工确认。

4.2 报错二：GPG key没有安装，或key已经过期

换源后安装包时常见这样的warning：

warning: rpmts_HdrFromFdno: Header V4 RSA/SHA1 Signature, key ID f4a80eb5: NOKEY Retrieving key from https://mirrors.aliyun.com/centos-vault/7.9.2009/os/x86_64/RPM-GPG-KEY-CentOS-7

yum会自动尝试导入repo文件里gpgkey=字段指定的key，如果导入失败，或者系统已经存在同名key但状态异常，就会继续报"Public key ... is not installed"这类错误。修复方式是手动强行导入：

rpm --import https://mirrors.aliyun.com/centos-vault/7.9.2009/os/x86_64/RPM-GPG-KEY-CentOS-7

导入后用下面命令确认key已经在本地：

rpm -qa gpg-pubkey*

另一个麻烦事是key过期。CentOS 7的GPG key有时间期限，停服后新装的环境如果系统时间不对，或者key本身已经失效，yum makecache阶段就会报"key expired"之类的问题。要是确认是时间导致的，先把系统时间校准，比如用date -s临时同步，再重新导入key。生产环境确实有同事图省事把repo文件里的gpgcheck改成0，我要多说一句：这个方法能绕过报错，但同时也绕过了软件包签名校验，压缩包被中间人替换了你都不知道，能不用尽量不用。

4.3 报错三：EPEL源报Could not retrieve metalink

典型报错：

[epel] Could not retrieve metalink for repository: epel. Please verify its path and try again

问题出在EPEL的repo文件用了metalink，它会重定向到fedoraproject.org去获取mirror列表。内网或国内网络环境下这个地址访问不通，于是元数据获取失败。定位方法很简单：打开/etc/yum.repos.d/epel.repo，如果看到这一行：

metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever&arch=$basearch

把它注释掉，替换成阿里云的baseurl：

baseurl=https://mirrors.aliyun.com/epel/$releasever/$basearch/

然后yum clean all && yum makecache重新生成缓存，问题就解掉了。

4.4 报错四：yum repolist为空，或者根本没有读取任何repo

换源后yum repolist什么都看不到，多半是以下三种情况之一。

第一，/etc/yum.repos.d/目录下没有.repo文件。检查一下下载的新repo文件是否因为curl命令失败而没落地，ls -l /etc/yum.repos.d/看一下文件大小是否正常，有时候会生成一个0字节的CentOS-Base.repo，那等于没有配置。

第二，yum全局配置/etc/yum.conf里有reposdir=参数，它把repo目录指向了别的地方。这种情况通常出现在被其他人定制过的系统里，执行grep reposdir /etc/yum.conf确认一下。

第三，repo文件里各项参数写错了，比如enabled=0把所有仓库都关掉了。用下面的命令看详细输出，它会打印实际读取的repo信息和每个repo的URL：

yum -v repolist

4.5 报错五：Name or service not known，网络层就没通

yum报"Could not resolve host: mirrors.aliyun.com"时，问题不在yum也不在repo，而在基础网络。按顺序做三件事：

curl -I https://mirrors.aliyun.com/ cat /etc/resolv.conf env | grep -i proxy

curl -I能通就说明网络没问题；/etc/resolv.conf看DNS是否配置正确；env | grep -i proxy检查环境变量里有没有代理设置覆盖了直连。内网环境需要走代理时，在/etc/yum.conf的[main]段添加：

proxy=http://你的代理地址:端口

让yum强制通过代理出去。这类问题最容易被忽略，因为不是yum本身配置错误，而是底层网络没通。

4.6 换源排错速查表

为了方便你直接对照，我把上面几类问题整理成一张表：

5. 生产环境换源后的几条土经验：更新、启用与安全

源配置好不代表一劳永逸，后面还有几个操作决策需要你根据实际环境判断。这些话平时文档里不太会写，都是我实际维护服务器时一点点攒出来的经验。

5.1 换源后要不要yum update，我的建议是分情况

CentOS 7已经EOL，所谓yum update也只是把包更新到vault里最后的版本，不会再有任何安全补丁。如果你这台机器是生产环境，不建议无脑执行yum -y update，因为内核、glibc这类底层包一升级，很可能要求重启，而重启窗口不是你想有就有的。我的习惯是装新包时正常用yum install，依赖解析会自动从阿里源拉取对应版本的包；至于全局更新，先执行yum check-update看变更列表，再开会评估是否需要执行。

如果是刚初始化的一台新机器，装了系统还没有任何业务，那可以把基础软件包更新一遍。但要注意更新完内核版本后，重启前一定确认引导项没问题，要不在机房远程重启就真的要"开摆"了。

5.2 repo按需启用：别把第三方源混成一锅粥

EPEL、base、updates这些仓库同时开着没问题，但如果某个软件在多个repo里都有，yum默认会选择优先级最高的那个源里的版本，可能会把包替换成非预期版本。实际生产中我见过有人开了remi源，又把yum install php打进去，结果php被替换成remi源里的版本，和业务代码不兼容，折腾一晚上才找到原因。

安全做法是默认关掉不常用的仓库：

enabled=0

需要用的时候再显式指定：

yum --enablerepo=epel install jq

如果某些内核或关键软件包无论如何都不允许被某个源覆盖，可以在/etc/yum.conf里加一行：

exclude=kernel*

这样就算其他repo里有新版本内核，yum也会自动跳过。

5.3 安全习惯：gpgcheck保持开启，https优先

换源后最容易犯的错就是把gpgcheck=0写进repo文件来绕过key问题。我的观点很明确：即使是内网环境，也不要轻易关签名校验。阿里源本身是可信镜像，真正有问题的是链路中间环节，一旦被插入了恶意rpm，gpgcheck=1就是唯一防线。如果非要关，也至少限制在一个临时repo里，用完就删。

另外所有baseurl都尽量用https://mirrors.aliyun.com而不是http://。镜像站的https证书是有效的，加了https加密后，元数据和包内容在传输过程中不会被篡改，开销几乎可以忽略。

5.4 多台机器批量换源：用模板而非手动一台台配

如果你的环境里有几十台CentOS 7.9，手动一台台编辑repo费时费力还容易出错。我的做法是先在一台测试机上把repo文件配置好、验证通过，然后把/etc/yum.repos.d/目录打包：

cd /etc/yum.repos.d && tar czf /root/yum.repos.tar.gz CentOS-Base.repo epel.repo

再用循环脚本分发：

for host in 192.168.1.10 192.168.1.11 192.168.1.12; do scp /root/yum.repos.tar.gz root@$host:/root/ ssh root@$host "cd /etc/yum.repos.d && tar xzf /root/yum.repos.tar.gz && yum clean all && yum makecache" done

如果你用了Ansible，那更省事，写好playbook后一遍跑完还能统一收集执行结果。关键是先在小范围测试，确认repo文件内容没有失效路径，再大规模铺开。

最后再说一个平时不太注意的细节：阿里源虽然同步频率高，但偶尔也会出现某个包版本比官方vault延迟半天一天的情况，如果yum install时发现某个包一直拉不到，先别怀疑源配错了，用curl -I直接请求一下那个rpm的完整路径，看看阿里源上到底有没有这个文件。我在实际运维中至少有两三次都是因为官方vault归档还没同步完，导致阿里源上临时缺文件，等几个小时再刷新缓存就正常了。这就是为什么我始终建议把yum clean all && yum makecache当成一个常规排错动作，很多诡异问题清完缓存就默默消失了。换源这件事本身不复杂，但把原理和坑都理解了，后续维护才能真正省心。