搞运维的朋友应该都有过这种经历：望着机房角落里那台运行了好几年的 CentOS 6.8 服务器，想着装个软件包，敲下yum install，结果屏幕上弹出一串红色报错。更气人的是，换了几个号称“可用”的镜像地址，还是装不上，最后只能手动找 rpm 包一个个装依赖，装到怀疑人生。
其实这不是你手气不好，也不是网络不通，而是 CentOS 6.8 这个系统版本的生命周期已经彻底结束，官方把原本提供给它的在线软件仓库全部转移到了“vault”归档区。平时我们配置的 mirrorlist 地址已经解析不到内容，yum 自然就拉不到任何包。这篇文章我就从报错现象开始讲起，把CentOS 6.8 镜像源失效的原因拆开，手把手带你把 yum 源修复好，并且把换源之后仍然会遇到的几个高频坑也一并排掉。
1. 一个典型的yum install 失败现场：报错长什么样
如果你在 CentOS 6.8 上执行 yum 安装软件，最常见的报错是这样一段：
Loaded plugins: fastestmirror Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=6.8&arch=x86_64&repo=os&infra=stock error was 14: PYCURL ERROR 6 - "Couldn't resolve host 'mirrorlist.centos.org'"有些人还会看到：
Cannot find a valid baseurl for repo: base或者是：
http://mirror.centos.org/centos/6/os/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"这三种报错表面上是不同的，但背后是同一件事：yum 在访问 CentOS 6 的仓库地址时，要么解析不到域名，要么找到域名但请求不到数据，要么干脆返回 404。
先说最容易被误导的一点：很多人一看到Couldn't resolve host，第一反应是“是不是 DNS 坏了？”于是去测ping mirrorlist.centos.org，结果发现域名能解析，甚至ping也能通。这就更迷惑了。
这里要澄清一下，Ping 通不代表 yum 能正常下载。yum 走的是 HTTP 请求，而mirrorlist.centos.org这个接口会根据你传的参数返回一个当前可用的镜像列表。当 CentOS 6 被官方标记为 EOL 之后，这套接口还会继续应答吗？理论上可以，但返回列表里的镜像地址基本都已经是失效内容，或者接口本身做了变更。于是 yum 拿到一个空列表或者失效列表，再往后走就会报Cannot find a valid baseurl。
另一种情况是直接访问mirror.centos.org下的/centos/6/os/x86_64/路径，因为 6 系列已经被整体归档，这个路径已经从当前发布目录移除，服务器返回 404。你看到的报错里带repomd.xml那个文件，这是 yum 仓库元数据的索引文件，404 说明仓库目录已经完全不存在了。
所以问题并不是你的系统出了问题，而是“这个版本的官方在线仓库已经搬家了”。搬家之后，原来那一整套 yum 源的配置路径，就全部变成无效路径。
2. CentOS 6.8 的镜像源为什么会集体失效：EOL 机制拆解
要彻底搞明白这个问题，得先知道 CentOS 的生命周期管理是怎么回事。
CentOS 是一个免费的企业级 Linux 发行版，但它不是无限期维护的。官方对每个大版本都有一个明确的维护时间表。拿 CentOS 6 来说，整个 6 系列的生命周期到 2020 年 11 月 30 日就结束了。从那个时间点以后，官方不再对这个系列提供任何安全更新、bug 修复，也不再维护它的公共软件源。
听起来像是“停止更新”而已，但实际影响比想象中大得多。生命周期结束后，原来给 6 系列提供的在线仓库会被移到一个叫vault的归档区域。所谓 vault，就是官方用来存放历史版本包的地方，好比图书馆里的“过期杂志合订本”，内容还在，但已经不在日常展架上了。
这样做带来的连锁反应就是：CentOS 6 的 yum 默认配置指向的那几个域名和路径，已经从“在线活跃仓库”变成了“归档仓库”。如果配置里用的还是旧的 mirrorlist 机制，那它根本不会去 vault 区域找，自然也就找不到任何数据。
那有人会问，为什么不直接改一下 mirrorlist 指向 vault 呢？问题在于 CentOS 6 的配置是写死在/etc/yum.repos.d/CentOS-Base.repo里的。这个文件默认长这样：
[base] name=CentOS-6.8 - Base mirrorlist=http://mirrorlist.centos.org/?release=6.8&arch=$basearch&repo=os&infra=stock #baseurl=http://mirror.centos.org/centos/6.8/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1注意看这个结构：mirrorlist那一行是优先启用的，baseurl被注释掉了。yum 在解析仓库时，如果mirrorlist存在，就会优先去请求那个接口。这个接口对于已经 EOL 的版本，返回的数据已经不再指向可用镜像。所以不管你本机网络多好，它都会卡在第一步。
理解了这层机制，解决办法也就呼之欲出了：要么禁用mirrorlist，改用baseurl直接指向 vault 归档地址；要么直接把整个 repo 文件内容替换成指向 vault 的配置。这是修复 CentOS 6.8 镜像源的核心逻辑，其他所有花里胡哨的操作，都是围绕这一条展开的。
如果你去看一些第三方公共镜像站，会发现有些站点还保留着/centos/6/os/x86_64/的目录结构，那其实是镜像站自己做了历史归档，并不意味着官方还在维护。这类地址可用，但如果镜像站调整策略随时可能失效，稳定性没有保障。所以我后续的做法里，会优先推荐使用官方 vault 区域，毕竟它是 CentOS 自己的归档空间，稳定性相对最可靠。
3. 替换为仍可用的镜像源：完整实操步骤
说了这么多，接下来直接进入实操环节。目标只有一个：让 CentOS 6.8 的 yum 能够正常安装软件包。
第一步，备份原来的仓库文件。这一步千万别省。虽然 CentOS 6.8 本身已经 EOL，但万一后面你要看默认配置做对比，有备份会方便很多。
cp /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak.$(date +%Y%m%d)第二步，编辑/etc/yum.repos.d/CentOS-Base.repo。建议直接改成下面这个样子，把原来的 mirrorlist 行注释掉，新增 baseurl 指向 vault：
[base] name=CentOS-6.8 - Base #mirrorlist=http://mirrorlist.centos.org/?release=6.8&arch=$basearch&repo=os&infra=stock baseurl=http://vault.centos.org/6.8/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1 [updates] name=CentOS-6.8 - Updates #mirrorlist=http://mirrorlist.centos.org/?release=6.8&arch=$basearch&repo=updates&infra=stock baseurl=http://vault.centos.org/6.8/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1 [extras] name=CentOS-6.8 - Extras #mirrorlist=http://mirrorlist.centos.org/?release=6.8&arch=$basearch&repo=extras&infra=stock baseurl=http://vault.centos.org/6.8/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1 [centosplus] name=CentOS-6.8 - Plus #mirrorlist=http://mirrorlist.centos.org/?release=6.8&arch=$basearch&repo=centosplus&infra=stock baseurl=http://vault.centos.org/6.8/centosplus/$basearch/ gpgcheck=1 enabled=0这里解释几个细节。
$basearch是 yum 的变量，会自动替换成x86_64或i386。CentOS 6.8 时期最常见的是 x86_64，所以你也可以直接写死成http://vault.centos.org/6.8/os/x86_64/，效果一样。保留变量形式的好处是配置文件更通用。
gpgcheck=1保持开启，这样安装包时会校验签名。别小看这个校验，尤其对于 EOL 系统，安全补丁已经停了，如果再跳过签名验证，等于门都不锁。
第三步，清理 yum 缓存并重新生成缓存。
yum clean all yum makecache如果你执行yum makecache时还是出现超时或者报错，先不要急，很可能是本机时间不对，这一点我在下一章专门讲。正常情况下，这条命令执行完会输出一堆metadata-cache的日志，最后显示Metadata Cache Created。
第四步，验证仓库是否可用。
yum repolist如果输出里能看到base、updates、extras仓库，并且每个仓库后面有一个正的包数量，那说明镜像源已经修复成功，接下来正常yum install就能用了。
有一类特殊情况需要额外说明：如果你这台机器上还配置了额外的第三方仓库，比如 EPEL 6、Remi 之类，它们同样会因为在 EOL 之后失效而报错。EPEL 6 对应的归档地址在https://archives.fedoraproject.org/pub/archive/epel/6/，处理思路一样，把仓库文件里的 baseurl 指向归档地址即可。如果觉得麻烦，最稳妥的做法是先把这些第三方仓库临时禁用，只保留基础仓库，等基础环境跑通后再逐个打开验证。
4. 换源之后仍然失败：高频排错记录
换完源之后依然报错，这种情况我见过太多次了。以下这几个坑，几乎每次帮别人处理都会碰到，我按出现频率列出来。
第一个坑：系统时间偏差太大。这是最容易忽略的，尤其对于已经跑了好几年、没做过时间同步的老机器。CentOS 6 默认用的是 ntpdate 定时同步，如果长时间失联，系统时间可能偏了几小时甚至几天。时间不对，在和 HTTPS 或带时间戳校验的仓库交互时，就会握手失败，或者 yum 认为元数据过期导致报错。你执行date看一眼，如果时间明显不对，先手动同步一下：
ntpdate -u ntp.aliyun.com如果 ntpdate 也没装，就直接手动设一个接近当前的时间：
date -s "2025-01-15 10:00:00"时间校正过来之后，再跑一次yum makecache，很多莫名其妙的问题就消失了。
第二个坑：fastestmirror插件干扰。CentOS 6 默认安装了fastestmirror插件，它会在 yum 操作时自动测试各镜像的速度，然后选择“最快”的那个。问题是，如果仓库配置里用了 vault 这类地址，插件的测速逻辑可能出错，或者测速结果为空，导致 yum 直接卡住或报错。处理办法是临时禁用插件：
yum --disableplugin=fastestmirror install 软件包名如果确认是插件问题，想彻底省心，可以直接修改/etc/yum/pluginconf.d/fastestmirror.conf，把enabled=1改成enabled=0。这样以后每次跑 yum 都干净利落。
第三个坑：GPG key缺失或过期。安装软件时如果报：
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID c105b9de: NOKEY Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6说明仓库配置里的 gpgkey 路径不对，或者 key 文件缺失。CentOS 6 的 key 文件通常位于/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6。如果你之前清理过/etc/pki/rpm-gpg目录，就需要重新安装centos-release包来恢复，或者从 vault 里面下载对应的 key 文件放回去。
第四个坑：网关、防火墙或代理屏蔽。有些内网环境只允许访问白名单域名，vault.centos.org 不在白名单里，自然就拉取不到。怎么判断是网络问题还是源问题？用 curl 直接测一下仓库地址：
curl -I http://vault.centos.org/6.8/os/x86_64/repodata/repomd.xml如果 curl 能拿到响应，但 yum 还是失败，那基本是本机 yum 配置的问题。如果 curl 直接超时，那就要去检查防火墙策略、代理设置，或者换一个能访问到的镜像地址。
第五个坑：仓库文件中残留了失效配置。很多人只改了CentOS-Base.repo，忘了/etc/yum.repos.d/目录下还有其他.repo文件，比如CentOS-Debuginfo.repo、CentOS-Media.repo。这些文件默认enabled=0不会影响使用，但有些版本的系统里CentOS-Media.repo默认启用了 c6-media 源，它指向光驱挂载路径，如果光驱没内容，yum 在处理时也会报错。排查时可以执行：
grep -r "^enabled=1" /etc/yum.repos.d/把真正启用的仓库列出来，逐个确认是否有效。
5. 这类问题的通用排查思路与避坑经验
经历过几台 CentOS 6.8 机器的修复之后，我总结出一套排查思路，以后遇到类似的“yum 装不上”问题，都可以直接套用。
先判断是网络不可达，还是仓库配置错误。最直接的办法就是 curl 测地址。能拿到响应，说明网络没问题，问题出在配置；拿不到响应，检查防火墙、DNS、代理，或者换一个源。这一步能节省大量瞎折腾的时间。
再判断是当前版本仓库整体失效，还是单个仓库配置坏了。如果执行yum repolist看到三个仓库同时报错，那大概率是镜像源地址整体失效，按本章开头的方式统一替换即可。如果只有一个仓库报错，那就只需要修那一个仓库文件。
还有一点值得多说一句：在这个问题上，很多人会盲目去网上搜“最新可用镜像地址”，然后找一堆第三方镜像站来替换。能找到可用地址自然是好事，但要注意甄别。第三方的 CentOS 6 镜像站，很多都是个人或小团队维护的，更新频次不定，可能跑着跑着就挂掉，反而留下更大的隐患。我个人的优先级是这样的：官方 vault 地址排第一，其次是信誉较好的公共镜像站，最后才是小众地址。优先级背后的逻辑是，vault 的维护主体是 CentOS 官方，尽管是归档区，但生命周期最长，风险最小。
另外，老系统的 yum 操作要养成“小步快跑”的习惯。别一次性执行什么yum update全量更新，尤其在 EOL 系统上，全量更新有可能导致内核或其他基础组件升级后和现有环境不兼容，甚至把一台能稳定运行的机器搞到不能重启。正确的做法是只安装你明确需要的软件包，需要什么就装什么，装完就收手。如果你确实想锁定一个安全版本基线，建议只更新特定软件包，或者干脆把 yum 配置成不检查更新源。
更稳妥的方案是，对于这些 EOL 系统的 yum 使用场景，考虑用“离线包 + 本地仓库”的方式。提前在一台联网机器上下载好需要的 rpm 包，做成一个本地 repo 目录，然后在内网机器上通过file://协议指向本地。这样彻底不依赖外网镜像源，也不受 EOL 影响，只是前期准备工作多一点。像有些项目对安全要求很高、在内网隔离区部署的，基本都会采用这种方式。
最后分享一个我自己常用的习惯：每次改完/etc/yum.repos.d/下的文件，我都会顺手把文件内容和修改时间记录下来，放在一个repo-change.log里。这个习惯看起来不起眼，但当你手头有好几台 CentOS 6.8 系统时，能帮你快速定位“哪台的源改过、什么时候改的、改成什么样了”。毕竟老系统的维护本来就是一份细致活，多留几个后手，总能少走几次弯路。
