前两周帮朋友搭一套测试环境CentOS 7.9 刚装完我顺手敲了下yum -y install vim结果进度条卡在下载阶段半天不动最后直接Could not resolve host。切到另一台机器想拉个docker pull nginx同样一直卡在等待层数据的界面。这种场景对经常碰 Linux 的人来说太熟悉了命令没敲错软件也没坏但 yum 源和 docker 镜像就是下载失败。今天就把这两类问题彻底掰开聊一聊从根因、排查到配置一次性讲透。这篇文章适合刚接触 Linux 的新手、在实验室或公司内网被网络环境困住的同事也包括需要批量装机和离线部署的运维。内容不绕弯子全部是我实际踩过坑之后沉淀下来的方案照着做基本能把下载失败的问题解决九成。1. 先搞清楚 yum 和 docker 各自卡在哪一步1.1 yum 源下载失败的典型表现yum 包管理器的默认仓库地址指向 CentOS 官方站点和 CentOS 镜像站点这些服务器绝大多数部署在海外。从国内网络环境直接访问海外服务器时受链路延迟、运营商路由调度等因素影响经常出现三种情况域名解析超时、TCP 连接被重置、TLS 握手卡死。具体到终端上你会看到类似这样的报错Could not resolve host: mirror.centos.orgConnection timed outCannot retrieve metalink for repository: epel. Please verify its path and try again或者干脆进度条停在base/7/x86_64/filelists_db这种元数据下载阶段一动不动。这里要强调一个容易误判的点很多人第一反应是“防火墙拦截”或“DNS 配置错了”于是去改/etc/resolv.conf甚至关掉 firewalld折腾一圈毫无效果。核心原因很简单——默认仓库服务器离我们太远链路质量差yum 拿不到完整的仓库元数据。yum 的工作流程是先读取/etc/yum.repos.d/下的.repo文件拿到仓库地址再下载repomd.xml和各类元数据文件然后才能进入真正的软件包下载。只要元数据这一步失败整个流程就卡住后面的包下载自然无从谈起。1.2 docker 镜像拉取失败的典型表现docker 镜像下载失败的逻辑和 yum 很像只是多了一层 registry 协议。默认情况下docker pull从 Docker Hub 拉取镜像Docker Hub 的镜像分发节点同样大量部署在海外。国内直连时最常见的现象是docker pull nginx后进度条长时间停在Waiting或只拉了一两个人气层就不动了报错error pulling image configuration: received unexpected HTTP status或net/http: TLS handshake timeout进度条偶尔动一下但速度只有几十 KB/s一个几百 MB 的镜像能拉半小时很多人以为“docker 下载慢”是 docker 本身的问题实际上慢和失败都发生在镜像层数据的下载阶段。docker 会先把镜像层拆分成一个个 blob按层并行下载每一层都得从 registry 走 HTTPS 拉取。链路差的时候任何一个层下载超时都会导致整个 pull 失败。理解这一点你就能明白为什么单纯加大超时时间并不管用——问题不在于等得不够久而是访问路径本身不稳定。2. yum 源配置把仓库从海外换到国内镜像2.1 备份原 repo 文件再动手配置 yum 源之前第一件事不是删除而是备份。我见过不少新手一上来就把/etc/yum.repos.d/下的文件全都删了结果想回退的时候只能重新装系统。正确的做法是先把原始配置打包留底mkdir -p /etc/yum.repos.d/backup cp -r /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/ rm -f /etc/yum.repos.d/*.repo这里先复制备份再清空目录是为了后续只保留我们新生成的源配置避免多个仓库文件互相干扰。备份完成后系统暂时没有可用源这个状态是正常的不用慌。提示如果服务器上有内部仓库、第三方商业源或其他定制 repo不要一把梭全删。建议先grep -rl baseurl /etc/yum.repos.d/看一下有哪些文件再把不需要的移走保留必须的。2.2 用阿里云镜像源配置 CentOS 7阿里云、清华 TUNA、华为云都维护了长时间稳定运行的 Linux 软件镜像站对 CentOS 7 都有完整同步。这里以阿里云源为例一条 curl 命令就能把官方 base repo 下载到位curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo下载完成后建议先看一眼文件内容确认 baseurl 是不是指向了mirrors.aliyun.com。顺便把 EPELExtra Packages for Enterprise Linux扩展源也配一下EPEL 里有很多不在基础源里的常用软件curl -o /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-7.repo配完源之后要清理并重建 yum 缓存。yum 会把仓库元数据缓存到本地不清理的话下次仍可能碰到旧缓存被损坏或源地址已变更的问题yum clean all yum makecachemakecache这个动作很关键它会实际连接仓库下载元数据并生成缓存。如果这一步能顺利走完说明源配置已经通了。实测下来阿里云源在 CentOS 7 上的makecache一般 10 到 30 秒内就能完成具体取决于网络和机器性能。2.3 验证源是否生效很多人在配置完源之后就直接yum install其实应该先做两步验证。第一步看仓库列表是否正常加载yum repolist这个命令会列出所有启用的仓库及其软件包数量。如果看到base、extras、updates、epel都在列表里且包数为正常范围说明源加载没问题。第二步是实际装一个小包验证比如yum -y install tree能秒装成功就说明整个链路已经通了。如果你用的是 CentOS 8 或新一代 RHEL 系系统命令会变成dnf但配置文件的位置和思路完全一致。高版本的仓库文件地址在阿里云镜像站点上都有对应的.repo文件换成对应版本号下载即可。这里不展开每个版本核心逻辑是一样的替换 baseurl清理缓存验证 repolist。3. 局域网/离线环境本地 yum 源的两种建法3.1 挂载 ISO 做最小本地源有些服务器在内网隔离区连公网镜像站点都不通这时候本地源是最可靠的方案。最简单的做法是把系统安装 ISO 挂载上去用 ISO 里自带的 RPM 包和仓库元数据搭建一个最小源。mount -o loop /path/to/CentOS-7-x86_64-DVD.iso /mnt如果服务器有光驱也可以直接mount /dev/cdrom /mnt。挂载完成后在/etc/yum.repos.d/下新建一个local.repo[local] nameLocal CentOS ISO baseurlfile:///mnt enabled1 gpgcheck0注意baseurl的写法file://加路径后面跟的是 ISO 挂载点的绝对路径。gpgcheck0表示跳过 GPG 密钥校验因为 ISO 里的包签名可能有特殊情况内网环境为了省事通常直接关掉。然后执行yum clean all yum makecache yum repolist如果 repolist 里出现了local仓库说明 ISO 本地源配置成功。这个方案的优点是快、稳、不依赖网络缺点是软件包版本停留在 ISO 发布时的快照安装新软件时可能提示找不到某个包。只适合装基础环境和少量固定版本的软件。3.2 用 createrepo 搭建 RPM 共享源当你手里有一批 RPM 安装包想共享给局域网内的多台机器用时就需要用createrepo来生成仓库元数据。原理很简单yum 的仓库本质上就是一个带repodata目录的文件夹createrepo做的就是扫描 RPM 包并生成索引。首先在一台能访问这些 RPM 的机器上创建目录结构mkdir -p /data/yumrepo cp /some/path/*.rpm /data/yumrepo/ createrepo /data/yumrepocreaterepo命令执行后会在/data/yumrepo下生成repodata目录里面就是仓库的索引信息。如果后续往里新增了 RPM 包需要重新执行createrepo --update /data/yumrepo来更新索引。接下来把这个目录通过 HTTP 或 NFS 共享出去。用 nginx 是最常见的做法简单配置一个静态文件服务即可也可以用python3 -m http.server 80 --directory /data/yumrepo快速验证但生产环境别这么干。客户端机器上的 repo 配置如下[localrepo] nameRPM Shared Repo baseurlhttp://server-ip/yumrepo/ enabled1 gpgcheck0记得在 nginx 配置里给/yumrepo/路径设置autoindex on;否则客户端无法列表目录。这个方案特别适合 Hadoop、DM 数据库等需要分发大量 RPM 包的场景就我个人经验公司内部搞离线环境时这种本地源比每个人各自挂 ISO 好用得多因为版本统一、更新集中。4. Docker 镜像下载加速从配置加速器到自建仓库4.1 原理daemon 层是怎么加速的Docker 的客户端命令docker pull实际上是把请求发给本地 docker daemon由 daemon 去 registry 服务端拉镜像。daemon 提供了一个registry-mirrors配置项可以指定一组镜像加速器地址。拉取镜像时daemon 会优先从这些加速器站点查询和下载镜像层而不是直接访问 Docker Hub。打个比方你本来要去国外总店取货现在楼下开了个加盟仓库货是同一个品牌但从楼下拿快得多。镜像加速器本质上就是 Docker Hub 在国内的只读缓存节点镜像内容与 Docker Hub 保持同步但访问速度快几个数量级。这个机制不需要对客户端镜像做任何标记或修改配置后直接原生支持。明白这个原理你就会知道所谓“加速器”不是靠某种特殊网络技术变快的而是把数据源搬到了离你近的地方。所以配置的核心就是找到离你近、同步及时、且能稳定访问的镜像仓库地址。4.2 配置 registry-mirrors 加速器以 CentOS 7 上通过 systemd 管理的 docker 为例配置方法如下。先编辑 daemon 配置文件没有就新建vim /etc/docker/daemon.json写入以下内容{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com, https://docker.nju.edu.cn ] }配置完成后一定不要漏掉下面这两步。很多新手改了文件不重启服务然后问我为什么没生效systemctl daemon-reload systemctl restart docker重启后验证配置是否真正加载docker info | grep -A5 Registry Mirrors如果能看到你填写的加速器地址列表说明配置生效了。这里有个实际测试的结论加速器地址会不定期失效或变慢所以不要写完就一劳永逸。我的做法是配置多个地址docker 会在一个地址拉取失败时自动尝试下一个这样单个源挂了也不至于全线瘫痪。另外家里用宽带和公司用专线的表现差异很大最靠谱的办法是配置后立刻docker pull nginx docker pull mysql:5.7实测一把。4.3 自建 registry 或使用云厂商镜像仓库加速器解决了“拉取”加速的问题但一个团队如果既要对外发布镜像又希望内网分发足够快就需要自己的镜像仓库。标准的 registry 镜像可以一行命令跑起来docker run -d -p 5000:5000 --name registry --restartalways \ -v /data/registry:/var/lib/registry registry:2启动后本地打 tag 并推送docker tag nginx:latest 192.168.1.100:5000/nginx:v1 docker push 192.168.1.100:5000/nginx:v1注意自建 registry 默认走 HTTPS 或需要 TLS 配置。如果是在内网用 HTTP 或 IP 地址直接访问需要在每台客户机的/etc/docker/daemon.json里加上insecure-registries{ insecure-registries: [192.168.1.100:5000] }同样要systemctl daemon-reload systemctl restart docker才能生效。这里有个我踩过的坑只配置了insecure-registries但没加registry-mirrors导致 docker info 里只显示前者。这两个配置互不排斥想加速又用内部仓库就同时填。除了自建用云厂商提供的容器镜像服务比如阿里云容器镜像服务、腾讯云容器镜像服务也是常见方案。这类服务的思路是把镜像推送到云端私有仓库各服务器从云端仓库拉取。它自带公网加速能力比自建 registry 省去了维护成本适合没有专职运维团队的小环境。本质上还是那句让 docker daemon 从一个又快又稳定的地址拿数据下载失败的问题就自然解了。5. 离线场景docker 镜像的 save 与 load5.1 联网机器上把镜像打成 tar 包有些部署环境更极端服务器不通公网也没有内网 registry。这时候最实用的办法是在一台能联网的机器上先把镜像拉下来导出成文件再拷进目标机器导入。命令很简单docker pull nginx:latest docker save -o nginx.tar nginx:latest为了节省传输体积可以打包时顺便压缩docker save nginx:latest | gzip nginx.tar.gzdocker save会把镜像的所有层和元数据完整打包。这里有个容易混淆的点docker save是打包整个镜像docker export则是把容器文件系统导出两者用途完全不同离线分发镜像必须用save。如果你要分发多个镜像可以在 save 命令后跟多个镜像名docker save -o all-images.tar nginx:latest mysql:5.7 redis:75.2 目标机器导入镜像并验证把 tar 文件拷到目标机器后用docker load导入docker load -i nginx.tar如果用的是 gzip 压缩包docker load会自动识别压缩格式不需要先解压。导入完成后执行docker images | grep nginx确认镜像出现在列表里。之后就可以正常docker run了。这个方法在无外网环境部署 GitLab、Guacamole、DM8 这类重量级镜像时特别好用因为这类镜像体积动辄几百 MB 到好几 GB在线拉取几乎不可能离线包反而是最稳的途径。我处理过的最小离线部署场景是一台只能通过 U 盘拷文件的物理机整套环境就靠saveload两个命令搬过去的。5.3 构建自定义镜像时如何配合离线源如果你需要在离线环境用 Dockerfile 构建自定义镜像基础镜像同样可以走离线导入流程。先在联网机器上把基础镜像 save 下来比如docker pull centos:7 docker save -o centos7.tar centos:7导入到目标机器后Dockerfile 里的FROM centos:7就不会再去网上找了。还有一个容易被忽略的细节Dockerfile 中如果有RUN yum install这类指令在构建过程中容器内会重新走一遍 yum 源解析。此时如果容器内部默认源不可用构建会卡在安装软件包的步骤。解决办法是提前准备好对应的 yum 源配置在 Dockerfile 里把 .repo 文件复制进容器或者在基础镜像里提前配置好国内源这样离线构建时也能顺利装完依赖。这个坑我实际遇到过不止一次尤其是php、hadoop这类需要装大量系统依赖的镜像构建时半数时间都耗在 yum 环节。6. 常见问题与排查技巧实录6.1 问题排查速查表把实际运维中频率最高的几类问题整理成一张速查表方便你对着排查。每个问题后面写的都是我自己调试过的处理路径不是理论推导。问题现象排查思路最终处理方案Could not resolve host报错先ping mirrors.aliyun.com再cat /etc/resolv.conf看 DNS配置可用的 DNS如 223.5.5.5重新makecacheyum 提示仓库元数据校验失败看是不是 GPG 校验问题或缓存损坏yum clean all确认 gpgcheck 配置重新 makecacheyum repolist空列表检查.repo文件是否被移动到 backup 目录确认/etc/yum.repos.d/下存在 .repo 文件且后缀正确docker pull 卡在 Waiting大概率是默认 Hub 访问受限配置 registry-mirrors 并重启 dockerdocker info看不到加速器daemon.json 格式错误或没重启用python3 -m json.tool /etc/docker/daemon.json检查 JSON重启 dockerdocker load后 images 为空用了docker export生成的 tar用docker save重新打包再 load构建镜像时 yum 安装失败容器内没走国内源在 Dockerfile 中提前放入国内源 .repo 文件自建 registry push 失败未配置 insecure-registries 或证书问题内网环境把 http 地址加入 insecure-registries重启 docker这里面最常被忽略的是 JSON 格式问题。daemon.json里的逗号、引号写错一个整个文件就会解析失败docker 启动后配置不生效但也不报明显错误非常坑。我的建议是每次改完都先python3 -m json.tool校验一遍。6.2 几个值得养成的习惯排查这类下载失败问题我自己的经验是按顺序来先确认网络通不通再确认配置对不对最后才怀疑服务本身。比如 yum 出问题第一件事就是用curl -I http://mirrors.aliyun.com/centos/7/os/x86_64/测一下源地址能不能访问通了你再去看 repo 文件不通就先解决 DNS 和路由问题。docker 也一样curl -I https://docker.nju.edu.cn先探一下加速器地址是否可达能达到再动 daemon.json。直接上来改配置很多时候是在一个没通的地基上盖楼。另外一个小习惯每次配置完源之后我会顺手执行yum -y update看整体流程是否顺畅。如果 update 能跑完说明 base、extras、updates 三个核心仓库全都正常。docker 这边则固定用docker pull hello-world做冒烟测试这个镜像只有几十 KB能快速验证链路问题是它下载慢到一定程度时最能暴露问题等它成功了你再去拉大镜像就放心了。把这两个固化到你的装机流程里比临到用时再排查节省大量时间。还有一个很多人容易忽略的细节系统时间。HTTPS 连接依赖证书校验如果服务器时间偏差太大访问云镜像站点和 docker registry 都会出现x509: certificate has expired or is not yet valid之类的报错。排查这类问题前先date -s 2025-...手动校正或者配置好 chrony、ntp 时间同步说不定就直接好了。我在内网机器上遇到过不下三次全部是时间漂移导致的 TLS 握手拒绝跟源本身一点关系没有。