Docker 拉镜像慢这件事只要是国内玩容器的人基本都躲不过。明明网速不差一执行docker pull就卡在等待层下载进度条半天不动这就是镜像源连通性在拖后腿。我自己的服务器之前就是这样拉一个几十 MB 的镜像都要几分钟后来花了一个下午把各类国内镜像源整理测试了一遍总算把拉取速度压到了秒级。这篇文章就把我踩过的坑和目前实测可用的方案整理出来方便大家按需配置。这次更新是在 9 月 8 日重新验证过的主要补充了几个新出现的社区镜像也剔除了一些已经失效或明显变慢的地址。可以放心的是下面提到的配置方式和验证逻辑不管镜像源列表以后怎么变都能让你快速找出当前能用的一套组合。1. 为什么 Docker 镜像拉取这么慢先说清楚慢在哪里。Docker 默认从 Docker Hub 拉取镜像这个仓库的服务器部署在海外国内直连的时候网络链路长、丢包率高尤其在拉取一些层数多的大镜像时每个 layer 都要单独走一遍完整请求稍微有一点不稳定就会反复重试给人的体感就是“卡死”。我见过不少朋友以为是 Docker 版本问题或者机器性能不够其实大多数情况就是网络问题。判断方法很简单如果docker pull卡住时你去 ping Docker Hub 的域名或者直接看连接状态延迟高得离谱甚至丢包那基本就实锤了。镜像源registry mirror就是为了解决这个问题的。它本质上是一个 Docker Hub 的缓存代理你配置好之后Docker 拉镜像时会先去镜像源请求。如果这个源里已经有对应镜像的快照就直接从国内服务器下载速度自然快得多如果源里没有它再回源到 Docker Hub 拉取并缓存下来下次有人拉同一镜像就快了。还有一个容易被忽略的点镜像源不只是解决“拉不到”的问题它还解决“拉得慢、拉不稳定”的问题。因为国内镜像源服务器通常会做层压缩和并发优化同样的镜像走国内源往往比直连 Docker Hub 省掉非常多的时间。所以配置国内镜像源本质上就是给 Docker 的拉取请求加了一层本地化缓存代理。这个思路和前端开发用 CDN 加速静态资源是同一个道理——把内容分发到离用户更近的节点减少跨网传输损耗。2. 镜像源选型解析公有云加速器和公共镜像站谁更稳现在国内能用的 Docker 镜像源大致分两类公有云厂商的加速器和社区维护的公共镜像站。两者各有优劣我在实际使用中是把它们混着配的互为备份。公有云加速器典型的就是阿里云镜像加速器。这类服务背后有云厂商的带宽和基础设施支撑稳定性和速度都是顶级的。缺点是通常需要注册云账号获取一个个人专属的加速地址格式一般是https://xxxx.mirror.aliyuncs.com。这个地址虽然说是“专属”但实际使用上并没有严格的身份鉴权只要拿到地址就能用所以网上也流传着很多公开的阿里云加速器地址。社区公共镜像站例如 DaoCloud、1Panel、还有一些开发者自建的聚合镜像站。这类镜像源的最大特点就是免注册、零门槛拿到地址直接写进配置就能用。缺点也很明显——稳定性全看维护者的服务器状况和带宽成本经常出现某个镜像源突然失效、速度骤降的情况。我自己的实践经验是优先配置一两个公有云加速器作为主力然后补充一两个社区镜像站作为备用。因为 Docker 配置多个镜像源之后拉取时会按顺序逐个尝试如果第一个源拉不到会自动回退到下一个多配几个并不会拖慢正常拉取速度反而增加了容灾能力。下面把两类镜像源的对比整理成表格方便大家对照选择类型代表优点缺点适用场景公有云加速器阿里云个人加速器地址速度快、稳定性强、带宽充足需要注册账号获取专属地址生产服务器、长期使用的开发机社区公共镜像站DaoCloud、1Panel 等公益源免注册、即配即用可能失效、速度波动大临时测试、个人开发环境、备用源这里要特别说一句镜像源这个东西比大多数人想象中“脆弱”。我之前遇到过社区镜像站因为服务器到期直接关停的情况头一天还用得好好的第二天拉镜像就报超时。所以不要把一个镜像源当成永久依赖每次配置完之后把验证方法记下来隔一段时间就批量测一次发现问题及时替换。3. 手把手配置国内镜像源加速配置镜像源的核心动作是修改 Docker 守护进程的配置文件。不同系统、不同 Docker 安装方式配置文件的位置和修改方式略有区别下面分场景说明。3.1 Linux 系统 daemon.json 配置方式Linux 下 Docker 的守护进程配置集中在/etc/docker/daemon.json文件里如果文件不存在就新建一个。修改前建议先备份原文件这个习惯能救命的别嫌啰嗦。# 备份原配置 sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak # 编辑配置文件 sudo vim /etc/docker/daemon.json在文件里写入以下内容其中registry-mirrors字段就是镜像源列表按优先级从上到下排列{ registry-mirrors: [ https://docker.m.daocloud.io, https://docker.1panel.live, https://hub.rat.dev ] }保存退出后重启 Docker 服务让配置生效sudo systemctl daemon-reload sudo systemctl restart docker然后执行docker info查看配置是否生效。在输出信息里找到Registry Mirrors这一段如果能看到你刚写的地址就说明配置成功了docker info | grep -A 5 Registry Mirrors正常会输出类似这样Registry Mirrors: https://docker.m.daocloud.io/ https://docker.1panel.live/ https://hub.rat.dev/顺便说一句重启 Docker 会中断所有正在运行的容器如果你服务器上有不能停的业务记得先确认一下重启窗口。如果是测试机那就无所谓了直接重启就行。3.2 Docker DesktopWindows/macOS图形化配置如果你用的是 Docker Desktop配置方式更简单不需要碰命令行配置文件。打开 Docker Desktop点击右上角设置图标进入Settings → Docker Engine这里会显示一个 JSON 编辑框默认内容一般是这样的{ builder: { gc: { defaultKeepStorage: 20GB, enabled: true } }, experimental: false }在这个 JSON 里加上registry-mirrors字段{ builder: { gc: { defaultKeepStorage: 20GB, enabled: true } }, experimental: false, registry-mirrors: [ https://docker.m.daocloud.io, https://docker.1panel.live, https://hub.rat.dev ] }点击右下角的Apply restart按钮Docker Desktop 会自动重启并加载新配置。重启完成后在终端执行docker info同样可以验证配置是否生效。Windows 用户如果遇到改完配置重启失败的情况不要慌先检查一下 JSON 格式是否合法。registry-mirrors字段特别容易在加的时候忘了逗号导致整个 JSON 解析失败Docker 就会直接拒绝启动。这种问题在编辑 JSON 时非常常见改完代码块后一定要留意一下逗号的位置。4. 镜像源可用性验证与批量测速配置完镜像源不代表万事大吉因为有些源虽然能写进配置但实际已经失效或者速度极慢。所以配置完成后强烈建议做一轮可用性验证。4.1 用 curl 快速检测镜像源连通情况Docker Registry API 有一个标准的健康检查端点访问/v2/路径如果能正常返回 HTTP 状态码通常是 200 或 401说明这个源当前是活的。我平时会用curl批量测试成本极低curl -s -o /dev/null -w %{http_code} %{time_total}s https://docker.m.daocloud.io/v2/ curl -s -o /dev/null -w %{http_code} %{time_total}s https://docker.1panel.live/v2/ curl -s -o /dev/null -w %{http_code} %{time_total}s https://hub.rat.dev/v2/每行输出第一个字段是 HTTP 状态码第二个字段是请求耗时。只要状态码是 200 或者 401就说明源可用输出000或者直接超时那基本可以断定这个源有问题。时间字段的单位是秒这个值越小说明连通性越好。我测试下来状态码正常且耗时在 0.5 秒以内的源拉镜像时通常都能跑出比较理想的速度。如果耗时超过 2 秒就算能用速度多半也快不到哪去建议直接从列表里踢掉。4.2 用 docker pull 验证实际拉取效果curl 测试只能说明网络层面通不通真正的效果还是要用docker pull来验证。我推荐拉一个hello-world或者alpine这种小镜像既快又不占磁盘空间。先清掉本地已有的缓存镜像防止从本地缓存直接命中看不出真实效果docker rmi hello-world:latest 2/dev/null docker pull hello-world拉取时注意观察输出如果镜像层下载速度很快说明镜像源生效了。alpine镜像虽然也不大但比hello-world多一些层更贴近真实使用场景docker pull alpine:latest这里有个小技巧拉取的过程中Docker 输出会显示每一层镜像的下载进度和耗时。如果看到Waiting、重试、速度忽快忽慢多半是当前镜像源不太给力可以考虑调整镜像源顺序把表现最好的那个放到最前面。4.3 镜像源的日常维护习惯镜像站失效这件事几乎是所有用国内镜像源的人都会遇到的。我自己经历过几次之后养成了一个习惯每次准备配置镜像源之前先花两分钟把这几个候选地址全部 ping 一遍这是成本最低的排雷方式。建议在手机或者笔记软件里存一份「候选镜像源清单」每隔一两周就用前面的 curl 命令批量测一次。一旦发现某个源失效就把它从清单里挪到“已失效”分区同时把新的可用源补充进来。这样真正需要改配置的时候手里随时有一份可用的源列表不用临时一个一个去试。5. 常见问题与排查实录配置镜像源的过程中有几个问题出现的频率特别高我把实际遇到的场景和解决方法整理一下。5.1 配置之后 docker info 看不到镜像源这个问题的绝大多数原因是 Docker 配置文件格式错误。JSON 语法容错率很低多一个逗号、少一个引号Docker 直接拒绝加载整个配置文件但服务还能以默认配置启动所以表面上看起来 Docker 是正常的实际上你的配置根本没生效。排查思路很明确先看 Docker 服务状态有没有报错再检查 daemon.json 的 JSON 合法性。可以把文件内容丢到在线的 JSON 校验工具里检查或者直接在终端执行sudo dockerd --validate这个命令会帮你校验配置文件如果有语法错误会直接打印出提示信息。校验通过后再重启 Docker一般就能看到镜像源了。还有一个容易忽略的点如果你用的是 rootless 模式安装的 Docker配置文件路径不在/etc/docker/daemon.json而是在~/.config/docker/daemon.json。用普通用户权限去改/etc/docker下的文件是没用的。5.2 镜像源配置了但还是拉取超时配置了多个镜像源但拉取还是超时这个情况我遇到过。排查后发现有些镜像源只支持拉取特定命名空间的镜像或者对某些大型镜像做了限制导致回源失败。解决方法有两个第一个调整镜像源顺序把最稳定的公有云加速器放在第一位。Docker 拉镜像时是按顺序尝试的第一个源成功就不会再请求后面的源所以把优质源放前面能减少无效尝试。第二个不是特别多但确实有人遇到过本地 DNS 解析把镜像源域名解析到了错误的 IP导致请求被丢到黑洞路由。遇到这种问题可以手动指定 hosts 解析或者换一个公共 DNS 服务试试。5.3 配置生效后拉取某些镜像还是慢这个问题的原因通常与镜像本身有关。一些冷门镜像、非 Docker Hub 仓库的镜像比如ghcr.io、quay.io托管的镜像国内镜像源不一定缓存过第一次请求时它需要回源到原始仓库拉取这个过程还是慢。这种情况下镜像源只能起到“间接加速”的作用。如果你频繁使用某些冷门仓库的镜像可以考虑自己搭一个轻量级的镜像缓存服务或者在服务器本地的 Docker Registry 里提前拉好镜像后续从本地仓库直接拉取。5.4 常见问题速查表现象可能原因解决方法docker info 不显示镜像源daemon.json 格式错误或路径不对用 dockerd --validate 校验检查 rootless 模式路径拉取镜像一直超时镜像源失效或该源不支持目标镜像换源、调整源顺序配置后 Docker 无法启动JSON 语法错误恢复 .bak 备份重新编辑某些镜像仍然很慢镜像源没有缓存需要回源提前预热镜像或自建缓存仓库改了配置但拉取没变化没有重启 Docker 服务执行 systemctl restart docker6. 实操总结与个人建议到这里镜像源配置的核心内容基本讲完了。最后分享几点我实际操作下来的体会。镜像源列表是动态的不是一劳永逸的。我最早配置镜像源的时候随便在网上找了一个列表就全填进去了结果过了一个月一半的源都失效了拉镜像又开始卡。后来我学聪明了每次配置前都先批量测试宁可多花两分钟验证也不愿事后反复排查问题。公有云加速器永远是主力社区镜像站只当备胎。社区镜像站虽然免注册方便但稳定性真的看运气。如果你的服务器上跑着重要业务建议优先申请一个阿里云之类的云厂商加速器作为主力源社区源作为备用。我自己的服务器就是这么配的主力源一稳备胎基本用不上但真到了主力源出问题的时候备胎能顶上去不至于完全断供。把验证方法刻在脑子里。学会了curl测试镜像源连通性、用docker info检查配置生效、用docker pull验证实际速度这套方法比任何现成的镜像源列表都重要。因为镜像源列表总有一天会过时但这套验证逻辑可以让你在任何时候找出当前可用的源。如果你正在被 Docker 拉镜像慢的问题困扰花一二十分钟按照上面这套流程配置一遍大概率能把问题解决掉。做完之后你会发现之前那些动不动就卡半天的docker pull现在基本都是几秒内完成整个开发体验会舒服非常多。
