企业官网建设流程全解析

1. 为什么还要折腾 CentOS 8 的镜像源

CentOS 8 在 2021 年底官方就停止了常规维护，软件源地址也做了迁移，很多朋友手头还跑着 CentOS 8 的测试机、内网服务器或者虚拟机环境，执行dnf install或者yum update的时候直接报错，提示找不到仓库地址或者连接超时。这个问题的根源在于默认的mirrorlist指向的官方源已经不可用了，需要把软件源切换到仍然保留 CentOS 8 归档的镜像站点上。

我自己的实验室里就有几台老机器跑着 CentOS 8，平时用来做编译测试和容器实验，重装系统成本太高，所以每次遇到源失效的问题都得手动修一遍。这篇文章就把我反复操作过多次的配置流程完整梳理出来，包括为什么要改、改哪里、怎么改、改完怎么验证，以及一些容易踩的坑。不管你是刚接触 Linux 的新手，还是偶尔需要维护老系统的运维人员，照着做基本都能搞定。

需要提前说明的是，CentOS 8 已经不再接收安全更新，如果条件允许，建议尽早迁移到其他仍在维护的发行版。但如果你只是临时用一下、做离线测试或者内网环境不方便迁移，那配置镜像源就是最直接的解决办法。

2. 镜像源配置的整体思路拆解

2.1 默认源为什么失效了

CentOS 8 的软件仓库配置文件放在/etc/yum.repos.d/目录下，默认情况下这些文件里的mirrorlist指向的是官方维护的镜像列表地址。系统在安装软件时，会先请求这个列表，然后从列表里挑一个可用的镜像去下载软件包。官方停止维护之后，这个列表地址要么返回 404，要么直接无法解析，导致整个安装流程卡在第一步。

另一个关键点是，CentOS 8 的仓库分为几个不同的类别：BaseOS提供操作系统核心组件，AppStream提供应用软件和运行时环境，还有extras、PowerTools等辅助仓库。每个仓库都有独立的配置文件，所以修改的时候需要逐个处理，不能只改一个就完事。

2.2 为什么选择归档镜像而不是其他方案

面对官方源失效，通常有三种处理方式。第一种是直接换用其他发行版的源，比如把 CentOS 8 的源指向某个兼容发行版的仓库，但这种做法风险很高，因为软件包依赖关系可能不匹配，容易把系统搞崩。第二种是搭建本地源，把需要的软件包提前下载好放到内网服务器上，适合完全隔离的环境，但前期准备工作量大。第三种就是切换到仍然保留 CentOS 8 归档的镜像站点，这也是最省事、最通用的做法。

归档镜像站点的原理很简单：一些机构会把 CentOS 各个历史版本的软件包完整保存下来，对外提供访问。你只需要把仓库配置文件里的地址从官方地址改成归档地址，系统就能正常拉取软件包了。这种方式的优势在于改动小、可逆、不需要额外硬件资源，缺点则是归档站点可能随时关闭，所以配置完之后最好把用到的软件包缓存到本地。

2.3 配置前需要确认的几件事

动手之前，先确认几个基本信息。第一，你的系统确实是 CentOS 8，可以用cat /etc/centos-release查看版本号。第二，你有 root 权限或者可以通过 sudo 提权，因为修改仓库配置文件需要写权限。第三，网络是通的，可以先 ping 一下目标镜像站点的地址，确认能解析、能连通。第四，如果之前改过仓库配置，建议先备份原始文件，方便出问题时回滚。

提示：如果你不确定之前有没有人改过仓库配置，可以先执行ls /etc/yum.repos.d/看看目录下有哪些文件，正常的 CentOS 8 应该有 CentOS-Base.repo、CentOS-AppStream.repo、CentOS-Extras.repo 等几个文件。

3. 核心操作步骤与关键细节

3.1 备份原始仓库配置

这一步很多人会跳过，但我强烈建议做。原因很简单：万一改错了，没有备份就得重装系统或者从别的地方拷贝配置文件，非常麻烦。备份命令很简单，把整个目录复制一份就行：

mkdir -p /etc/yum.repos.d/backup cp /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/

执行完之后可以用ls /etc/yum.repos.d/backup/确认一下备份文件都在。如果后续配置过程中出现任何异常，直接把备份文件拷回去就能恢复原状。

3.2 清理旧的仓库缓存

CentOS 8 默认会在/var/cache/dnf/目录下缓存仓库元数据和软件包。如果之前源已经失效，缓存里可能存着过期的数据，直接改配置可能会导致新旧数据混在一起，出现奇怪的报错。所以改配置之前先清一下缓存：

dnf clean all

这个命令会清空所有仓库的元数据和软件包缓存。执行完之后你会看到类似“XX files removed”的输出，说明清理成功。如果你的系统上只有 yum 没有 dnf，用yum clean all效果一样，CentOS 8 里 yum 实际上是 dnf 的软链接。

3.3 修改仓库文件指向归档地址

接下来就是核心步骤：修改/etc/yum.repos.d/下的仓库文件。需要修改的主要是 CentOS-Base.repo 和 CentOS-AppStream.repo 这两个，其他如 extras、PowerTools 也建议一并处理。修改的方式有两种：一种是直接用 sed 命令批量替换，另一种是手动编辑每个文件。

用 sed 批量替换的效率更高，适合对命令行比较熟悉的朋友。核心思路是把文件里的mirrorlist行注释掉，然后把baseurl行取消注释并改成归档地址。以 CentOS-Base.repo 为例：

sed -i 's/^mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Base.repo sed -i 's|^#baseurl=http://mirror.centos.org|baseurl=http://mirror.example-archive.org|g' /etc/yum.repos.d/CentOS-Base.repo

这里需要说明一下，mirror.example-archive.org是一个占位地址，实际使用时要替换成你能访问的归档镜像站点地址。选择镜像站点的时候，优先选地理位置近、响应速度快的，这样下载软件包会快很多。如果你不确定哪个站点可用，可以先用浏览器或者 curl 测试一下。

手动编辑的方式更直观，适合新手。用 vi 或者 nano 打开 CentOS-Base.repo，找到[baseos]、[appstream]等段落，把mirrorlist=开头的行前面加#注释掉，然后把#baseurl=开头的行去掉#，并把地址改成归档地址。每个段落都要这样处理，不能漏。

3.4 处理 AppStream 和 Extras 仓库

CentOS-AppStream.repo 和 CentOS-Extras.repo 的修改方式和 Base.repo 一样，也是注释 mirrorlist、启用 baseurl 并替换地址。AppStream 仓库比较重要，很多常用软件比如 Python、Node.js、开发工具链都在这里面，如果这个仓库没配好，装软件的时候会提示找不到包。

Extras 仓库里放的是一些额外的工具和驱动，平时用得少，但建议一并配好，免得以后需要的时候又得回来改。PowerTools 仓库默认是禁用的，如果你需要用到里面的开发库，可以把enabled=0改成enabled=1。

3.5 重建缓存并验证

所有仓库文件改完之后，执行下面的命令重建缓存：

dnf makecache

这个命令会去每个仓库拉取元数据并缓存到本地。如果配置正确，你会看到类似“Metadata cache created”的提示，每个仓库都会显示拉取的包数量。如果某个仓库报错，说明那个仓库的地址配错了或者网络不通，需要单独排查。

验证配置是否生效，最简单的方法是试着安装一个小软件：

dnf install -y tree

如果能够正常下载并安装，说明镜像源配置成功。也可以用dnf repolist查看当前所有仓库的状态，正常的话每个仓库都会显示 repo id、repo name 和 status。

4. 实操过程中容易踩的坑

4.1 地址替换不完整导致部分仓库仍然失效

这是最常见的问题。很多人只改了 CentOS-Base.repo，忘了改 AppStream 或者 Extras，结果装某些软件的时候还是报错。判断方法很简单：执行dnf repolist的时候，如果某个仓库显示 status 是 0 或者报错，就说明那个仓库没配好。解决办法就是把/etc/yum.repos.d/下所有 .repo 文件都检查一遍，确保每个文件里的 mirrorlist 都注释了、baseurl 都改了。

4.2 镜像站点选择不当导致下载速度极慢

归档镜像站点有很多，不同站点的带宽和负载情况差别很大。有些站点虽然能访问，但下载速度只有几十 KB/s，装个大点的软件包要等半天。我的经验是优先选本地区或者邻近地区的站点，如果不知道哪个快，可以同时测几个，用curl -o /dev/null -s -w '%{time_total}\n' <地址>看响应时间，选最快的那个。

4.3 缓存未清理导致新旧元数据冲突

前面提到过要执行dnf clean all，但有些人改完配置直接dnf makecache，结果新旧缓存混在一起，出现“Cannot download repomd.xml”或者“Failed to synchronize cache”之类的报错。遇到这种情况，先dnf clean all清干净，再dnf makecache重新拉取，基本都能解决。

4.4 系统时间不对导致证书验证失败

这个问题比较隐蔽。如果系统时间偏差太大，HTTPS 请求的证书验证会失败，表现为“SSL certificate problem”或者“Peer certificate cannot be authenticated”。解决办法是先同步系统时间：

timedatectl set-ntp true

或者手动设置一个接近当前的时间。时间同步之后，证书验证就能通过了。

4.5 仓库优先级和排除规则的影响

有些系统上装了额外的仓库配置，比如 EPEL 或者第三方仓库，这些仓库可能有优先级设置或者排除规则，导致某些包被屏蔽。如果你确认镜像源配好了但还是装不上某个软件，可以检查一下/etc/yum.repos.d/下有没有其他仓库文件，以及/etc/dnf/dnf.conf里有没有exclude或者priority相关的配置。

5. 常见问题速查与排查思路

5.1 报错信息与对应处理

下面整理了几个我实际遇到过的典型报错，以及对应的排查方向：

5.2 排查的基本顺序

遇到问题的时候，建议按下面的顺序排查，从简单到复杂，避免一上来就改一堆配置：

1. 先确认网络通不通，ping一下镜像站点地址
2. 再确认 DNS 解析正常，nslookup或者dig看一下域名能不能解析
3. 然后检查仓库配置文件，确认 mirrorlist 注释了、baseurl 启用了、地址写对了
4. 接着清理缓存，dnf clean all之后重新dnf makecache
5. 如果还不行，检查系统时间和证书，date看一下时间对不对
6. 最后检查有没有其他仓库文件或者全局配置干扰

5.3 一个实用的调试技巧

如果你不确定某个仓库地址是否可用，可以用 curl 直接请求仓库的元数据文件：

curl -I http://mirror.example-archive.org/centos/8/BaseOS/x86_64/os/repodata/repomd.xml

如果返回 200 OK，说明地址可用；如果返回 404 或者连接超时，说明地址不对或者站点不可用。这个方法比反复改配置、反复 makecache 要快得多，建议养成习惯。

注意：不同归档站点的目录结构可能略有差异，有的站点把 CentOS 8 放在/centos/8/下，有的放在/centos-vault/8/下，配置之前最好先用浏览器访问一下站点的根目录，确认实际的路径结构。

6. 配置完成后的收尾工作

6.1 锁定关键软件包版本

CentOS 8 已经停止维护，归档站点里的软件包版本不会再更新。如果你不希望某个关键软件在后续操作中被意外升级，可以用dnf versionlock把它锁定。先安装 versionlock 插件：

dnf install -y python3-dnf-plugin-versionlock

然后锁定指定的包：

dnf versionlock add nginx

这样即使仓库里有更新的版本，dnf 也不会自动升级它。这个技巧在维护老系统的时候特别有用，可以避免因为意外升级导致的服务不可用。

6.2 把常用软件包缓存到本地

归档站点随时可能关闭，如果你有内网环境或者经常需要重装系统，建议把常用的软件包提前下载到本地。可以用dnf download命令：

dnf download --resolve --alldeps nginx

这个命令会把 nginx 及其所有依赖包下载到当前目录。下载完之后可以拷贝到内网服务器上，用dnf install *.rpm离线安装。虽然前期麻烦一点，但后续会省很多事。

6.3 记录配置变更

如果你维护的不止一台机器，建议把这次配置的变更记录下来，包括改了哪些文件、改成了什么地址、执行了哪些命令。这样下次遇到同样的问题，直接照着记录操作就行，不用重新摸索。我自己的做法是在/root/下建一个notes目录，把每次系统配置的变更都写成一个 markdown 文件，时间长了就是一个很有用的知识库。

6.4 考虑长期迁移方案

最后说句实在话，CentOS 8 的归档源只能解一时之急，长期来看还是得迁移。如果业务允许，可以评估一下迁移到其他仍在维护的发行版，或者把应用容器化，减少对宿主机操作系统的依赖。迁移之前先做好测试，确认应用在新系统上能正常运行，再逐步切换。这个过程可能比较长，但早做比晚做好。

我个人在实际操作中的体会是，配置镜像源这件事本身不复杂，难的是遇到问题时能快速定位原因。上面整理的排查顺序和速查表，都是我踩过坑之后总结出来的，希望能帮你少走点弯路。如果你在操作过程中遇到其他奇怪的问题，欢迎一起交流。