前阵子翻出一台快吃灰的 CentOS 6.10 服务器，准备把上面的旧系统数据导出来，结果刚敲下yum install就开始卡在 0%，进度条死活不动，最后直接超时报错。一开始我以为是网络波动，试了几次都一样，后来才反应过来：这台机器的 yum 源还指着官方 mirrorlist.centos.org，而 CentOS 6 早在 2020 年底就停止维护了，官方仓库下架后，老系统如果还想装软件，最省事也是国内最熟的路子就是把源切成阿里源。

这篇就把我整个换源过程写下来，重点放在 CentOS 6.10 的完整操作上，毕竟这是最近大家搜得最热的关键词。顺手也整理一下 pip、npm、Maven、Docker、apt 这些常用软件的阿里源地址和配置方式，给还在跟老系统、慢镜像死磕的朋友做个参考。

1. 为什么宁可换源也不硬等官方仓库

1.1 直连官方源的真实体验

很多人第一次意识到需要换源，都是被"卡进度条"教会做人的。yum、apt 这类包管理器下载元数据时，如果网络不好，表现就是0% [running]挂在那里，或者反复重试后丢出一句Connection timed out。

原因不复杂：CentOS 官方仓库服务器主要部署在海外，国内直连要过国际链路，晚高峰尤其明显。yum 是个对网络抖动很敏感的机制，它要先拉 repomd.xml、再校验仓库元数据，每包一次网络往返，掉了就得从头再试。相比下载 RPM 包本身，这种频繁的小请求反而最容易卡死。

1.2 阿里源到底是什么

很多人把"阿里源"当成一个神秘的东西，其实它的本质就是官方仓库的国内镜像副本。阿里云镜像站（mirrors.aliyun.com）通过定期同步机制，从上游官方仓库拉取文件，再放到自己的 CDN 节点上分发。你在国内访问它，链路短、带宽大、丢包少，速度和稳定性自然好很多。

这里有个容易误解的点：镜像站不是"盗版源"，也不是单独维护一套软件包，它和你从官方装到的软件包内容完全一致，只是下载位置换成了国内。同步周期通常在小时级到天级，对绝大多数软件来说，新鲜度完全够用。

所以换源这件事的适用范围很明确：国内服务器、本地开发环境、公司内网主机，只要是访问官方源费劲的地方，都值得换。尤其对 CentOS 6.10 这类官方已经停更、仓库被下架的系统来说，换源不是优化网络体验，而是"能不能继续装软件"的生存问题。

2. CentOS 6.10 更换阿里源完整实操：停维系统的自救方案

2.1 先认清状态：为什么 6.10 必须走 centos-vault

CentOS 6 在官方停止维护后，原本的/centos/6/仓库路径就不再接收新的更新，官方把所有归档内容挪到了 vault 目录。阿里云镜像站同样保留了centos-vault这个归档路径，所以 CentOS 6.10 换源时，baseurl 不能写常规的mirrors.aliyun.com/centos/6/...，而要写mirrors.aliyun.com/centos-vault/6.10/...。

很多教程没提这一茬，直接让用户把 URL 里的官方域名换成阿里云域名，结果老系统换上之后依然 404。原因就是路径层级对不上。

动手之前先确认系统版本：

cat /etc/redhat-release

如果输出是CentOS release 6.10 (Final)，那下面的操作可以直接照抄。如果是 6.9、6.8，把路径里的 6.10 改成对应的版本号即可。

2.2 备份原 repo 文件（回滚的底牌）

换源第一步不是删文件，而是先备份。我习惯建一个专门的备份目录，把/etc/yum.repos.d/下所有 repo 文件挪进去，而不是直接改动原文件。这样万一换源失败，或者镜像站路径又变了，还能快速切回原来的配置排查问题。

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

这一步做好之后，即使后续操作乱成一锅粥，至少系统不会因为缺 repo 文件而彻底没法用包管理器。

2.3 写新 repo：base、updates、extras 一条龙

备份完成后，新建一个CentOS-Base.repo文件，内容直接写死阿里云 vault 路径。注意这里我故意没用$releasever变量，而是写死 6.10，是因为老系统的 yum 在变量展开时偶尔会有版本识别的问题，与其排查变量，不如直接把路径写死，干净利落。

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

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

这里有个细节值得说一下：为什么要保留 gpgcheck=1？GPG 校验虽然多一道步骤，但能保证下载的 RPM 包确实来自 CentOS 官方签名体系。老系统上如果 gpgkey 配置在本地文件里（比如/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6），你也可以直接用file://方式引用，效果一样。

2.4 EPEL 6 的取舍与 key 校验

CentOS 6 时代很多软件要从 EPEL（Extra Packages for Enterprise Linux）仓库装，比如 htop、iftop 这些。但 EPEL 6 同样已经官方归档，阿里云镜像站的 epel 目录目前主要维护还在生命周期内的版本，epel/6这个路径不一定还在同步。

我的建议是：先把 base 和 updates 换好，确认能正常安装基础包，再去单独处理 EPEL。先把 EPEL 的 repo 文件写出来，用curl检查一下路径是否有效，再决定保留还是禁用。

vi /etc/yum.repos.d/epel.repo

[epel] name=Extra Packages for Enterprise Linux 6 - $basearch baseurl=http://mirrors.aliyun.com/epel/6/$basearch failovermethod=priority enabled=1 gpgcheck=0

先别急着留这个文件，用下面这条命令确认镜像站上是否还有对应目录：

curl -I http://mirrors.aliyun.com/epel/6/x86_64/repodata/repomd.xml

如果返回 200，说明这个源还能用；如果 404，就把文件里enabled=1改成enabled=0，暂时禁用 EPEL，先保证系统基础源正常。gpgcheck 这里我临时置为 0，是为了在归档源上避免 GPG key 过期导致整个仓库不可用，内网测试机可以这么干，生产环境建议想办法找到 EPEL 6 的归档 GPG key 再开校验。

2.5 清理缓存并验证

配置写完之后，老规矩，清理缓存再重建元数据：

yum clean all yum makecache

yum clean all这步千万别省。yum 会缓存之前的 repomd.xml 和元数据索引，不清理的话，换了新源可能还在读旧缓存，结果就是你已经换了源，但命令报的错还是老源时代的错，非常误导人。

验证是否生效，最直接的办法是装一个小软件试试：

yum install -y vim

如果能看到base、updates仓库的下载进度条，并且顺利装完，说明源已经通了。还可以用yum repolist看一下当前启用的仓库列表和软件包数量。看到正常的软件包数量不是 0，基本就可以放心使用了。

3. CentOS 7/8 换源：顺手解决的模板化配置

3.1 CentOS 7 的 repo 写法

CentOS 7 还在支持期内时，换源比 6.10 简单得多。因为$releasever变量在 CentOS 7 上展开就是 7，路径不会乱。把 repo 文件写成这样：

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

CentOS 7 的 EPEL 还在维护，所以epel/7路径一般都是可用的：

[epel] name=Extra Packages for Enterprise Linux 7 - $basearch baseurl=http://mirrors.aliyun.com/epel/7/$basearch gpgcheck=1 gpgkey=http://mirrors.aliyun.com/epel/RPM-GPG-KEY-EPEL-7 enabled=1

换完之后依然是yum clean all && yum makecache，再验证。

3.2 CentOS 8 停维后要走 vault 路径

CentOS 8 在 2021 年底结束维护，所以它也面临和 6.10 一样的归档问题。不同的是，CentOS 8 的仓库结构变成了 AppStream、BaseOS、PowerTools 等模块化目录，不能像 CentOS 7 那样一个 base 仓库搞定所有事。

CentOS 8 换阿里源时，baseurl 应该指向centos-vault/8.5.2111/这个归档版本路径。这里以 8.5.2111 为例，因为那是最后一个标准发行版本：

[BaseOS] name=CentOS-8 - Base - mirrors.aliyun.com baseurl=http://mirrors.aliyun.com/centos-vault/8.5.2111/BaseOS/$basearch/os/ gpgcheck=1 enabled=1 [AppStream] name=CentOS-8 - AppStream - mirrors.aliyun.com baseurl=http://mirrors.aliyun.com/centos-vault/8.5.2111/AppStream/$basearch/os/ gpgcheck=1 enabled=1 [PowerTools] name=CentOS-8 - PowerTools - mirrors.aliyun.com baseurl=http://mirrors.aliyun.com/centos-vault/8.5.2111/PowerTools/$basearch/os/ gpgcheck=1 enabled=1

3.3 顺手清理多余 repo 的排查经验

我见过不少换源失败的情况，其实是/etc/yum.repos.d/里残留了一堆旧 repo 文件导致的。比如系统里同时存在CentOS-Base.repo、epel.repo、remi.repo、docker-ce.repo，如果某个仓库指向的域名已经失效，yum 会在处理元数据时因为取不到那个仓库的 repomd.xml 而报错，连带把其他正常仓库也卡住。

换源时建议先执行yum repolist all，把当前所有启用的仓库列出来看一遍。凡是status列显示为 0 或者已经废弃的仓库，直接禁用掉，不用客气。老系统中的 repo 文件，多一个就多一个故障点。

4. 常用开发工具的阿里源配置清单

除了操作系统本身的源，开发工具链的下载源也是日常卡顿重灾区。这里把我平时用得最多的几个配置方式都列出来，都是可以直接抄作业的。

4.1 pip 源（Python）

Python 包的官方 PyPI 源在国内访问也是一言难尽，阿里云 PyPI 镜像地址是：

# 临时指定源安装 pip install -i https://mirrors.aliyun.com/pypi/simple/ requests # 写入全局配置，以后不用每次带参数 pip config set global.index-url https://mirrors.aliyun.com/pypi/simple/

执行pip config set后，配置会写入~/.pip/pip.conf或~/.config/pip/pip.conf。如果是在公司内网统一管理环境，也可以把配置放到全局/etc/pip.conf里，效果对所有用户生效。注意一点：阿里云 PyPI 源只支持 simple 协议，不支持普通的 PyPI 页面访问，使用 pip 时路径必须是pypi/simple/，少写一个simple就会报 404。

4.2 npm 源（Node.js）

很多文章会把 npm 的"阿里源"和阿里云镜像站混在一起讲，实际上 npm 的镜像由 npmmirror 团队维护，域名是 registry.npmmirror.com，也就是大家以前熟悉的淘宝 npm 镜像。老的 registry.npm.taobao.org 已经迁移到新域名，还在用老域名的最好及时换掉。

npm config set registry https://registry.npmmirror.com # 验证是否生效 npm config get registry

也可以在使用时临时指定：

npm install lodash --registry=https://registry.npmmirror.com

4.3 Maven 源（Java）

Java 项目依赖下载慢，基本是所有 Maven 用户的共同记忆。阿里云 Maven 仓库的公共地址是https://maven.aliyun.com/repository/public，它聚合了中央仓库、JCenter 等多路来源。在 Maven 的settings.xml里配置：

<mirror> <id>aliyun</id> <mirrorOf>central</mirrorOf> <name>aliyun maven mirror</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

如果项目里还依赖了 Spring 等框架的专用仓库，可以把mirrorOf改成*，让所有依赖都走阿里云聚合仓库。Gradle 用户则在build.gradle里加：

repositories { maven { url 'https://maven.aliyun.com/repository/public' } }

4.4 Docker CE 源和镜像加速器

Docker 有两层"源"：一层是安装 Docker 本身的 yum/apt 仓库，另一层是拉取镜像用的 registry 加速器，不要搞混。

安装 Docker CE 时，CentOS 系统用阿里源的 repo：

yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

如果服务器上还没有 yum-config-manager，可以手动下载 repo 文件到/etc/yum.repos.d/，然后替换文件里的 download.docker.com 为 mirrors.aliyun.com/docker-ce，再执行yum makecache。

镜像加速器则是在/etc/docker/daemon.json里配置：

{ "registry-mirrors": ["https://你的加速器专属地址.mirror.aliyuncs.com"] }

这个专属地址需要登录阿里云容器镜像服务控制台，在"镜像加速器"页面复制粘贴，每个人账号不同，不能直接照抄网上的地址。改完配置文件后重启 Docker 生效：

systemctl daemon-reload systemctl restart docker

docker pull 的时候，拉镜像的进度条会明显快很多。

4.5 Ubuntu/Debian 的 apt 源

Ubuntu 换阿里源比较简单，直接替换archive.ubuntu.com域名即可：

sudo sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list sudo apt update

这里有一个细节：security.ubuntu.com我一般不建议一起替换。安全更新仓库的同步有更严格的要求，镜像站不一定能够保证和官方完全同步。留着他官方地址，最多是速度稍慢一点，但能保证安全补丁第一时间拿到。

以下是常用源的速查表，方便收藏：

5. 换源之后最容易踩的坑（我是怎么排查的）

5.1 404：路径变了还是版本号没写对

换源后最常见的报错是404 Not Found，表现形式是 yum 提示找不到 repodata/repomd.xml。这类问题的排查思路是：先确认报错的是哪个仓库，再用浏览器或者 curl 直接访问对应的 baseurl 路径。

我第一次换 CentOS 6.10 的时候就是吃了路径的亏：把 source URL 写成了mirrors.aliyun.com/centos/6.10/os/，结果一直 404。后来 curl 试到centos-vault/6.10/才发现，归档路径和常规路径是完全分开的。遇到 404，第一反应应该是去镜像站目录列表看一眼实际路径长什么样，而不是反复重试。

5.2 gpgkey 校验失败

换了新源之后有时会报GPG key retrieval failed，或者Public key for xxx.rpm is not installed。这说明 gpgcheck=1 但系统里没有对应的 GPG key。

解决办法有两种。第一种是手动导入 key：

rpm --import http://mirrors.aliyun.com/centos-vault/6.10/os/x86_64/RPM-GPG-KEY-CentOS-6

第二种方法是，在仓库配置里用file://指向本地已有的 key 文件：

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

如果本机装过配套的 centos-release 包，本地大概率已经存在这个 key 文件。生产环境建议保留 gpgcheck=1 并妥善导入 key，内网测试机临时把 gpgcheck 改成 0 排查问题可以，但不要把 gpgcheck=0 当作长期配置。

5.3 缓存欺骗：不 clean 就白换

很多时候源明明换对了，命令报的错却还是老源时代的提示，比如一直指向一个已经不存在的域名。这就是 yum 缓存里的旧 metadata 在作怪。

yum 会把仓库的元数据缓存到本地，下次执行安装操作时，如果缓存没过期，它会优先用缓存。换了新 repo 文件后不执行yum clean all，yum 可能还在读旧仓库的缓存索引，自然还是连接旧地址。

我的习惯是：任何一次换源，不管配置多简单，都先 clean all 再 makecache，绝不做例外。别嫌这两条命令啰嗦，它能帮你避开大量玄学报错。

5.4 老系统的 https 兼容性

CentOS 6.10 自带的 yum 基于 Python 2.6，在处理某些 https 源时，会因为证书链问题报CERTIFICATE_VERIFY_FAILED。我在这台老服务器上试过 https 的 baseurl，结果直接卡在证书校验，后来换成 http 的 baseurl 才顺利通过。

所以我在上面的 repo 配置里都写的是http://，而不是https://。这个选择针对老系统是务实的：CentOS 6.10 的软件源仓库里本身没有高敏信息，国内镜像站的链路也相对可控。如果你一定要在生产环境走 https，建议先把 ca-certificates 和 yum 相关组件在最小范围内升级到位，再切 https 源。

5.5 系统时间不准也会导致源连接失败

还有一个非常隐蔽的坑：老服务器如果长时间断过电、清过 CMOS，系统时间可能会漂移。https 源在 TLS 握手阶段会校验证书有效期，如果本机时间比真实时间偏了好几年，哪怕证书和路径都完全正确，也会握手失败。

排查这种问题只需要看一眼：

date

如果时间明显不对，直接用date -s设置成当前时间，或者配置好 NTP 同步。这个问题很容易被忽略，因为它跟源地址一点关系都没有，但症状却和源失效一模一样。

换源操作做到这里，CentOS 6.10 以及常用开发工具的国内源就都搞定了。最后再说点个人体会：老系统换源，本质上是把命运交给第三方镜像站的维护周期，阿里源用着确实快，但谁也不能保证归档目录永远不变。我的习惯是换完源之后，把yum.repos.d里的所有 repo 文件在本地备份一份，同时把当前机器上装过的关键软件版本记录下来，哪天镜像站路径又调整了，三分钟就能切到备用方案。如果你也在维护类似的旧机器，别嫌麻烦，先把备份这一步做了，后面能省很多事。