最稳的救急方式是直接更换阿里云CentOS Vault源，因CentOS 8官方源已于2021年底下线，需全量替换为阿里云Centos-vault-8.5.2111.repo并同步更新EPEL归档源，再清理缓存重建。
直接换阿里云 CentOS Vault 源是最稳的救急方式
CentOS 8 官方源在 2021 年底就已下线，mirrorlist.centos.org 和 vault.centos.org 都不可用，继续用默认配置执行 yum 或 dnf 必然报 Could not resolve host 或 404。此时不能修旧配置，必须全量替换为国内镜像站提供的存档源。
阿里云的 Centos-vault-8.5.2111.repo 是目前最可靠的选择——它完整同步了 CentOS 8 最后一个正式版本（8.5.2111）的所有仓库（BaseOS、AppStream、Extras），且长期可用。
- 先清空旧 repo：运行
mkdir -p /etc/yum.repos.d/backup && mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ - 再下载新源：
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo - 如果系统没装
curl，改用wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo
EPEL 源必须同步更换，否则 dnf makecache 会卡死
只换 CentOS-Base.repo 不够。EPEL 仓库（epel 和 epel-modular）也早已停更，若不一并切换，执行 dnf makecache 时会卡在 Status code: 404 for http://.../epel/8/ 或直接超时。
- 单独下载 EPEL 归档源：
curl -o /etc/yum.repos.d/epel-archive-8.repo https://mirrors.aliyun.com/repo/epel-archive-8.repo - 检查 repo 文件里是否还有
mirrorlist=行，有就手动注释掉（加#），否则dnf仍会尝试访问失效的 mirrorlist 地址 - 确认
gpgcheck=1保持开启，避免因签名验证失败导致包安装被拒
dnf clean all && dnf makecache 后仍报错？重点查这三处
缓存清理和重建不是万能的，常见失败原因很具体：
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
-
Cannot prepare internal mirrorlist：说明某个.repo文件里漏注释了mirrorlist=，逐个 grep：grep mirrorlist /etc/yum.repos.d/*.repo -
Failed to download metadata for repo 'appstream'：大概率是baseurl路径写错了，比如少了个/或写成http而非https；阿里云 vault 源必须用https协议 - 执行
dnf repolist看不到epel列表：说明epel-archive-8.repo没生效，检查文件名是否带空格或隐藏字符，用ls -la /etc/yum.repos.d/确认
别碰 centos-stream-repos，这不是兼容替代方案
有人看到红帽推荐 CentOS Stream 就想用 dnf swap centos-linux-repos centos-stream-repos，这是高风险操作。Stream 是滚动开发版，和 CentOS Linux 8 的二进制 ABI 不完全兼容，升级后可能出现 glibc 版本冲突、systemd 行为变更、甚至 SSH 连不上。
如果你只是想临时装个 net-tools 或更新几个安全补丁，Vault 源足够用；真要长期维护，应该规划迁移到 Rocky Linux 或 AlmaLinux，而不是在原系统上硬切 Stream。
Vault 源本质是快照，所有包都冻结在 8.5.2111 状态——这意味着你得自己承担后续漏洞无补丁的风险，这点比任何命令错误都关键。
