应使用 time sudo yum repolist --refresh 2>/dev/null | grep -c "repolist" 实测真实响应时间，因其涵盖元数据下载、GPG验证、依赖解析等完整流程；单用curl测URL仅得HTTP下载耗时，无法反映yum实际体验。
怎么测 yum 源的真实响应时间
直接用 curl -o /dev/null -s -w '%{time_total}\n' http://mirrors.aliyun.com/repo/centos-7.repo 测单个 URL 不够准——它只反映 HTTP 下载速度，不包含 yum 元数据解析、GPG 验证、依赖树构建等真实耗时。
真正影响 yum install 体验的是整个源的「可用性 + 响应一致性」。推荐用 yum repolist --refresh 配合 time 命令实测：
-
time sudo yum repolist --refresh 2>/dev/null | grep -c "repolist"—— 强制刷新所有启用源并统计耗时 - 重复执行 3 次取平均值，排除 DNS 缓存或临时抖动干扰
- 重点关注
real时间（总耗时），不是user或sys
如果某源多次测试都 >15 秒，基本可判定为慢源或不稳定节点，即使它 ping 得通。
阿里云、网易、中科大源在 CentOS 7 上的实际表现差异
三者在华东地区实测（2026 年上半年）：yum repolist --refresh 平均耗时分别为：
- 阿里云：
3.2s—— 节点多、CDN 调度好，gpgcheck=1开启后仍稳定 - 网易：
5.8s—— 教育网内更快，但公网偶尔出现403 Forbidden（需检查baseurl是否带/centos/路径） - 中科大：
7.1s—— 学术资源丰富，但部分镜像站对非教育 IP 限速
注意：epel 源单独测，它的响应时间不随主源变化。阿里云的 epel 镜像路径是 http://mirrors.aliyun.com/epel/7/x86_64/，别错配成 CentOS base 源地址。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
为什么 yum makecache 后速度没变
常见误区：以为执行了 yum makecache 就代表新源生效了。其实它只生成本地元数据缓存，不改变源本身的网络路径和响应质量。
真正卡顿往往来自这些地方：
-
/etc/yum.repos.d/下有多个 .repo 文件启用，其中某个已失效的源拖慢整体速度（用yum repolist enabled查看实际启用列表） - 系统时间不准导致 HTTPS 证书验证失败， silently 降级重试（
date和hwclock必须同步，且误差 -
metadata_expire=90m等缓存过期参数设得太长，yum拒绝刷新，一直用旧缓存 - 防火墙或 SELinux 拦截了 yum 的 DNS 查询（
journalctl -u NetworkManager | grep dns可查）
如何让 yum 自动选最快的源
CentOS 7 原生不支持自动测速切换，但可以用 dnf-plugins-core 的 fastestmirror 插件（虽是 dnf 生态，但在 yum 环境下兼容）：
- 安装插件：
yum install -y yum-plugin-fastestmirror - 启用插件：
sed -i 's/enabled=0/enabled=1/' /etc/yum/pluginconf.d/fastestmirror.conf - 插件会根据
curl -I对每个源的baseurl测速，并缓存结果到/var/cache/yum/mirrorlist.txt
注意：该插件默认每 24 小时更新一次镜像列表，若想手动强制刷新，删掉 /var/cache/yum/mirrorlist.txt 再运行 yum makecache 即可。
最麻烦的不是换源，而是换完后没验证——yum repolist 显示的 repo 名可能还是 old，但实际请求已走新地址；得靠 time + yum install -y sl 这种真实操作才能确认是否真快了。
