刚装完一台 CentOS 7，第一件事既不是装 nginx，也不是改 SSH 端口，而是先把 repo 源换掉——这句话我在带新人的时候说过不下几十遍。原因很朴素：CentOS 7 默认的 yum 仓库地址指向官方境外站点，加上 7 版本已经进入生命周期终点，官方把软件包目录整体挪进了归档区，很多老教程里的地址现在直接返回 404，于是 yum install 什么都是红字一片。所以「CentOS 7 安装后的 repo 源管理」这件事，看着像是个五分钟的小操作，实际上牵扯到镜像站路径规则、repo 文件字段语义、$releasever 变量解析、GPG 签名校验、缓存刷新机制，以及离线环境怎么自建仓库这一整套东西。这篇文章就是把这套东西一次讲透，从「为什么改」讲到「怎么改」「改完怎么验证」「出错了怎么查」，适合刚接触 CentOS 的运维新人，也适合手上有几台老机器还没迁移、需要临时维护的老手。

1. 装完 CentOS 7 第一件事：先搞清默认 repo 源到底坑在哪

很多人对源管理的理解停留在「复制一段配置覆盖过去」的层面，结果一换机器、一换网络环境就翻车。要真正把这件事做稳，得先理解默认源到底出了什么问题，不然你永远是在背命令而不是在解决问题。

1.1 默认源的三个现实问题

第一个问题是网络可达性。CentOS 7 的CentOS-Base.repo里默认启用的是mirrorlist字段，它指向一个镜像列表接口。yum 每次执行时会先去请求这个接口，拿到一份镜像站列表，再从中挑一个下载元数据。这个过程在国内网络环境下经常超时，表现就是yum makecache卡住几十秒然后报Cannot retrieve metalink for repository。它不是配置错了，纯粹是链路慢。

第二个问题是目录结构变更。CentOS 7 在 2024 年 6 月 30 日结束维护后，官方把 7 版本的软件包从主镜像目录迁移到了归档目录，主目录下的7/os/x86_64这类路径逐步失效。你如果照抄五年前的教程，baseurl写的是老路径，yum 会明确回你一句Cannot find a valid baseurl for repo: base/7/x86_64。这个报错我在不同的机器上见过至少几十次，绝大多数原因就是路径过期。

第三个问题是扩展仓库缺失。默认的 Base 仓库里没有 EPEL，也没有 SCLo（Software Collections），更不会有 Docker CE 这类第三方仓库。也就是说，即使你把 Base 源换好了，yum install epel-release之前的很多常用包依然装不上。这就需要你在源管理阶段就把扩展仓库的规划一起想好，而不是装一个包配一次源。

1.2 镜像源选型：别只看「哪个快」

国内可用的镜像站不少，常见的有阿里云、腾讯云、华为云、清华 TUNA、中科大 USTC、网易等。很多教程会直接告诉你「用阿里云就完了」，但从工程角度，选型至少要看四个维度：

这里有个容易忽略的点：归档目录和主目录是两套路径。主目录一般形如/centos/7/os/x86_64/，归档目录一般形如/centos-vault/7.9.2009/os/x86_64/。注意归档路径里带的是完整小版本号7.9.2009，不是7。这意味着如果你要指向归档，baseurl不能再用$releasever变量，而必须写死小版本号，这是一个非常关键的细节，后面第 3 章会详细展开。

另外，选镜像前建议先做一次连通性探测。我习惯的做法是先只发一个 HEAD 请求，看返回码和响应头，而不是直接改配置：

curl -sI https://mirrors.aliyun.com/centos-vault/7.9.2009/os/x86_64/repodata/repomd.xml | head -5

返回200才说明这个路径下真的有 repodata，返回404就说明路径错了，此时无论你怎么改gpgcheck、怎么清缓存都没用。这一步花十秒钟，能省掉后面半小时的瞎折腾。

1.3 CentOS 7 停止维护之后，源管理策略要跟着变

这一点必须单独说。CentOS 7 停止维护之后，主仓库不再接收安全更新，这意味着如果你继续挂在主目录上，短期内yum还能用，但你已经拿不到补丁了。所以对存量机器，大致有三条路线：

第一条是继续用归档源维持现状，把baseurl指向 vault 路径，保证软件包还能装、还能查询。这条路线适合短期过渡、内网测试机、以及那些短期内无法迁移的历史系统。

第二条是迁移到兼容发行版，比如 Rocky Linux、AlmaLinux、openEuler、Anolis OS 等。这类系统提供迁移工具或至少提供一致的包管理体验，长期看是正路。但迁移是项目级动作，不可能在「装完机器顺手配个源」这个阶段完成。

第三条是把机器降级为纯离线/内网环境，源只从内网仓库拉，彻底断开与外网的依赖。这条路线在工业现场、隔离网段里非常常见，第 5 章会专门讲。

我的建议是：短期用归档源先把机器跑起来，同时在源文件里用注释标明「这是临时方案，迁移计划编号 XXX」，避免半年后接手的人一脸茫然。这种注释看似多余，实则是运维交接里最值钱的东西。

2. 动手前必读：repo 文件的结构与 yum 的工作机制

直接抄配置能解决 80% 的问题，但剩下 20% 会让你怀疑人生。花十分钟搞清楚.repo文件里每个字段是干什么的，以及 yum 在背后做了什么，后面排错会快得多。

2.1 一个 .repo 文件里到底写了什么

CentOS 7 的仓库配置文件统一放在/etc/yum.repos.d/目录下，文件名以.repo结尾。yum 启动时会读取这个目录下所有.repo文件，把里面每个[section]当成一个独立仓库。一个典型的仓库段落大概长这样：

[base] name=CentOS-7 - Base baseurl=https://mirrors.example.com/centos-vault/7.9.2009/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled=1

字段不多，但每个都有讲究：

• [base]是仓库 ID，全局唯一，yum --disablerepo=base里的base就是它。注意这个 ID 和文件名无关，改文件名不会改 ID。
• name只是给人看的显示名，随便写不影响功能，但建议规范，因为yum repolist输出里第一列就是它。
• baseurl和mirrorlist二选一，同时存在时mirrorlist优先（除非你显式关掉）。这就是为什么很多人明明把baseurl改成了国内地址，yum 还是慢——因为mirrorlist那一行没注释掉。
• gpgcheck=1表示对下载的 rpm 做签名校验。强烈建议保持为 1，关掉它等于放弃了软件包来源可信性校验，是典型的安全隐患。
• gpgkey指向公钥文件或公钥下载地址。用file://指向本地/etc/pki/rpm-gpg/下的文件最稳，因为不依赖网络。
• enabled=1控制是否默认启用。经验做法是：常用仓库设 1，偶尔用的设 0，需要时用--enablerepo临时打开，避免误装。

2.2 $releasever、$basearch 和路径拼装逻辑

baseurl里的$releasever和$basearch是 yum 运行时替换的变量。$basearch好理解，就是 CPU 架构，x86_64 机器上是x86_64，ARM 上是aarch64。$releasever稍微绕一点：它取自系统里已安装的centos-release包版本，CentOS 7.9 上通常解析成7。

问题就出在这儿——归档路径需要的是7.9.2009，而$releasever给你的是7。所以要用归档源，你有三种处理方式：

第一种，直接把路径写死成7.9.2009，最直观，缺点是系统小版本升级后要手工改。第二种，用$releasever配合额外变量，但 yum 本身不支持自定义变量，得靠脚本或配置注入。第三种，把$releasever的值「改写」，可以在/etc/yum/vars/目录下建一个同名文件来覆盖：

echo "7.9.2009" > /etc/yum/vars/releasever

这个目录是 yum 的变量覆盖目录，里面每个文件对应一个变量名，文件内容就是变量值。这一招非常好用，尤其是你有大量机器需要统一指向同一个归档版本时，比逐台改 repo 文件省事得多。但要注意副作用：一旦覆盖了releasever，所有用到$releasever的仓库都会跟着变，包括第三方仓库，所以改之前先grep -r 'releasever' /etc/yum.repos.d/看一眼影响面。

2.3 元数据缓存：为什么改完源必须清缓存

很多人改完 repo 文件立刻yum install，然后发现行为没变化，就以为改错了。其实大概率是缓存在作怪。yum 会把仓库的元数据（包列表、依赖关系、文件列表）缓存到/var/cache/yum/$basearch/$releasever/下面，默认有较长的过期时间。改源之后，缓存里的元数据还是旧源下载的，yum 可能直接复用。

所以标准动作永远是这一对命令：

yum clean all yum makecache

yum clean all清掉所有缓存，包括元数据、rpm 包、插件缓存；yum makecache重新下载元数据并建立索引。老教程里常写yum makecache fast，fast参数在 CentOS 7 上是合法的，它表示尽可能复用已有的有效元数据。但在换源的场景下，我建议直接用不带参数的makecache，因为你要的就是「全部重来」，任何复用都可能是隐患。

注意：yum clean all之后第一次makecache会比较慢，因为要下载全部仓库的元数据。如果卡住不动，不要急着 Ctrl+C，先看是不是某个没关掉的仓库在超时，可以在另一个终端tail -f /var/log/yum.log观察。