1. 为什么 2026 年了Docker 镜像加速还是绕不开的话题如果你最近折腾过 Docker大概率遇到过这种场景pull 一个 ubuntu 镜像卡在 Pulling fs layer 半天不动pull 一个 mysql:8.0进度条跑了几分钟还在等待更崩溃的是镜像下到一半直接报 timeout 或者 EOF然后整个 pull 任务作废只能重来。这不是你网络的问题也不是 Docker 没装好而是 Docker Hub 在国内的访问链路本身就不稳定。Docker Hub 的镜像存储节点分布在全球各地走默认路由时经常要绕到境外节点再加上各种网络波动拉取速度确实一言难尽。所以从几年前开始配置国内镜像加速源就成了 Docker 安装部署之后的第一件事到现在也依然是刚需。这篇文章整理的是我目前在用的、实测可用的 Docker 镜像加速方案。我会直接给你能用的镜像源列表、具体的配置方式以及配置之后验证是否生效的方法。文章读完之后你应该能在 10 分钟内完成环境配置再也不用盯着进度条干等。需要说明的是镜像加速源这个生态变化非常快。今天能用的源三个月后可能就关了或者限流了今天没法用的源可能过段时间又恢复正常了。我的建议是不要只配一个源多配几个做兜底这样才能在某个源出问题时不影响正常工作。2. 镜像加速到底加的是什么速先把思路理清楚2.1 一个 pull 请求背后发生了什么要理解加速源得先搞清楚 Docker 拉镜像的基本流程。当你在终端执行 docker pull nginx:latest 时Docker 守护进程会向镜像仓库默认是 Docker Hub发起请求获取镜像的 manifest 清单然后根据清单里的层信息逐层下载镜像数据。整个过程可以拆成三步解析镜像名、获取 manifest、下载镜像层。其中下载镜像层是最耗时的部分因为一个镜像往往由多层组成每层可能几十 MB 到几百 MB 不等。比如 mysql:8.0 解压后 600 多 MB如果网速只有几百 KB/s光下载就得等十几分钟。加速源的工作原理并不复杂它是一个反向代理或镜像缓存部署在离你更近的网络节点上。你把 Docker 的镜像拉取请求指向这个源它会代替你从 Docker Hub 拉取镜像然后缓存下来后续再有相同请求时直接走内网或更快的链路返回数据。对于热门镜像很多源的缓存命中率非常高所以速度优势非常明显。2.2 “加速”解决的三个实际问题第一个问题就是速度。走加速源拉热门镜像基本能跑满你的带宽这比默认链路快几个数量级。第二个问题是稳定性。镜像拉取经常会遇到 EOF、connection reset 这类报错这通常不是 Docker 本身的问题而是链路不稳定导致的。加速源因为链路短、节点多能明显减少这种中断。第三个问题是可访问性。有一些容器镜像托管在 Docker Hub 之外的仓库比如 GitHub Container Registry、Google Container Registry在某些网络环境下访问困难。部分加速源支持这类仓库的镜像拉取相当于把一层代理也做了。2.3 配置加速源不等于把所有镜像都切换到国内这里要澄清一个常见误区配置加速源不会影响你拉取私有仓库镜像也不会影响你 push 镜像。registry-mirrors 这个配置项只对 Docker Hub 的公有镜像生效。如果你拉的是私有仓库的镜像比如 registry.example.com/myapp:v1Docker 会直接访问对应仓库不走加速源。另外如果你修改了 Docker Hub 官方镜像的完整名字比如从 docker.io/library/nginx:latest 改成 nginx:latest加速源依然能识别并处理。系统内置了对官方命名空间的兼容处理所以不用太担心格式问题。2.4 为什么需要准备多个源加速源本质上也是公共服务它的稳定性受自身网络条件、流量压力、运营策略影响。一个源在高峰期可能限流另一个源可能因为域名备案问题临时不可用还有的可能因为维护导致服务中断。所以我会在 daemon.json 里配置 2 到 3 个源。Docker 处理多个源的方式是优先使用第一个如果失败则自动尝试下一个。这种 failover 机制不需要额外配置你只要把多个地址按优先级排列即可。实际使用中这个设计能帮你躲过很多次“某个源挂了”的坑。3. 实测可用的镜像加速源列表3.1 当前可用源整理根据我这段时间的实测以下几个源目前在国内访问相对稳定速度和可用性都不错。我把它们分成几档方便你按自己的网络环境选择。源地址支持协议适用场景备注https://docker.1panel.livehttps通用加速开源面板配套源可用性较好https://docker.m.daocloud.iohttps通用加速DaoCloud 提供老牌稳定https://dockerproxy.nethttps通用加速免费公共源速度波动需自测https://docker.1ms.runhttps通用加速服务较稳定适合日常拉取https://docker.xuanyuan.mehttps通用加速个人维护实测可用https://docker.foreverlink.nethttps通用加速备用源可作为兜底这里要特别提醒镜像源列表的“时效性”是天然的。今天是这个状态不代表下个月还是这个状态。我建议你在配置之后主动跑一个 docker pull hello-world 来测试哪个源真正能用不要迷信任何文章里写的“推荐列表”——包括我这份。3.2 几个主流云厂商的源还能用吗很多老教程里会提到阿里云、腾讯云、网易、中科大这类镜像加速器它们的规则变化比较大。阿里云的个人版加速器地址是你账号专属的需要登录容器镜像服务控制台获取而且现在部分区域的地址已经调整过。腾讯云加速器以及中科大、网易这类高校或企业的源在不同网络环境下表现差异很大。如果条件允许我的个人建议是优先使用自己云厂商提供的加速器地址。因为这类服务有明确的运维保障而且你使用的是专属地址不容易被其他人的流量挤爆。缺点是需要在控制台里找一下专属地址稍微多一步操作。但我目前无法确认这些厂商加速源是否对所有用户无条件开放所以稳妥的做法还是先按 3.1 的源配置如果拉取不到再手动替换成你云厂商提供的专属地址。3.3 用脚本快速测试一组源配置多个源之前先测一下哪些源在你的网络环境下可用能省去不少试错时间。下面这个 Bash 脚本会逐个测试源是否可以正常拉取镜像#!/bin/bash sources( https://docker.1panel.live https://docker.m.daocloud.io https://dockerproxy.net https://docker.1ms.run https://docker.xuanyuan.me https://docker.foreverlink.net ) for source in ${sources[]}; do echo Testing $source ... curl -s --connect-timeout 10 -o /dev/null -w HTTP %{http_code}, time %{time_total}s\n \ $source/v2/ || echo Failed to connect done这个脚本的原理是请求每个源的 /v2/ 端点这个接口是 Docker Registry API 的版本检查端点返回 200 说明源基本可用。执行之后你能直观看到每个源的响应时间和状态码。把结果最好的几个源选出来按从快到慢的顺序写进配置里。4. 配置加速源的标准操作流程4.1 Linux 环境手动配置Linux 环境下Docker 的守护进程配置集中在 /etc/docker/daemon.json。配置镜像加速就是在里面加一个 registry-mirrors 字段。下面是完整配置示例{ registry-mirrors: [ https://docker.1panel.live, https://docker.m.daocloud.io, https://docker.1ms.run ] }编辑完成之后执行 systemctl daemon-reload 重载配置再执行 systemctl restart docker 重启 Docker 服务。这里有个非常容易踩的坑如果 daemon.json 文件里已经有其他配置项比如>{ data-root: /data/docker, log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }合并之后应该是{ data-root: /data/docker, log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 }, registry-mirrors: [ https://docker.1panel.live, https://docker.m.daocloud.io ] }改完配置后建议先执行 docker info 查看配置是否生效确认 Registry Mirrors 一栏能看到你填写的地址再重启服务避免因为配置格式错误导致 Docker 无法启动。4.2 Docker Desktop 图形化配置macOS 和 Windows 上使用 Docker Desktop 的话配置方式更简单。打开 Docker Desktop进入 Settings在 Docker Engine 标签页里会看到一个 JSON 编辑框里面默认有 dockerd 的配置内容。你在里面追加 registry-mirrors 字段即可。以 Windows 为例默认配置长这样{ builder: { gc: { defaultKeepStorage: 20GB, enabled: true } }, experimental: false }修改后{ builder: { gc: { defaultKeepStorage: 20GB, enabled: true } }, experimental: false, registry-mirrors: [ https://docker.1panel.live, https://docker.m.daocloud.io ] }保存后 Docker Desktop 会自动重启引擎。注意 Windows 上如果开启了 WSL 2 后端配置会同时作用于 WSL 内的 Docker 引擎不需要额外在 WSL 里配置。4.3 配置验证的两种方式配置完成后验证是否生效有两招。第一招是 docker info在输出里找 Registry Mirrors 这一行如果能看到你填写的地址说明配置被正确加载。第二招是实际拉取一个小体积镜像测试比如 docker pull hello-world观察拉取速度是否明显变快。我个人的习惯是配置完成后立刻跑一次 docker pull nginx:alpine这个镜像只有几 MB拉取速度快而且能直观反映加速源是否真的在工作。如果速度正常说明配置生效如果还卡在等待层下载那就换一个源再试。4.4 针对 containerd 环境的配置如果你用的是 Kubernetes 节点容器运行时是 containerd 而不是 Docker那么配置方式完全不同。containerd 的配置文件默认在 /etc/containerd/config.toml你需要修改其中的 plugins.io.containerd.grpc.v1.cri.registry.mirrors 部分。[plugins.io.containerd.grpc.v1.cri.registry.mirrors] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [ https://docker.1panel.live, https://docker.m.daocloud.io ]修改后重启 containerd 服务然后执行 crictl pull nginx:alpine 验证是否生效。这里的逻辑和 Docker 的 registry-mirrors 类似只是配置格式完全不同。很多初学者会搞混这两个环境的配置方式在这里单独提出来。5. 实战中遇到的坑和排查技巧5.1 配置后 Docker 无法启动这是最高频的问题十有八九是 daemon.json 的 JSON 格式错误。常见的低级错误包括缺少逗号、多了一个括号、末尾多了逗号。JSON 格式严格最后一项后面不能有逗号。排查方法很简单先不重启 Docker执行 dockerd --validate 或者直接在终端执行 python3 -m json.tool /etc/docker/daemon.json如果报错会直接提示哪一行有问题。改好之后再重启。还有一种情况是 Docker 服务没有重载配置。修改 daemon.json 之后必须先执行 systemctl daemon-reload再执行 systemctl restart docker两个步骤缺一不可。如果你跳过了 daemon-reload服务重启时读到的还是旧的 systemd unit 配置daemon.json 的改动不会生效。5.2 certificate signed by unknown authority 报错这个报错通常是因为你配置的加速源地址写错了协议或者使用了不支持的 http 地址。Docker 默认要求镜像仓库走 HTTPS如果源只支持 HTTP你需要把地址明确写成 http:// 开头同时把 insecure-registries 配置加上。但我不推荐这么干毕竟 HTTP 链路有被劫持的风险。另外有些加速源使用了非公信 CA 签发的证书或者证书链不完整也会触发这个报错。这种情况建议直接换一个源不要尝试绕过证书校验安全底线还是要守住。5.3 manifest unknown 或者 no such host出现 manifest unknown 大概率是镜像名打错了或者源缓存的数据不完整。换个源再试一下就能定位问题。no such host 则说明域名解析失败可能是源已经停止服务或者你的 DNS 有问题。此时最快的处理方式就是docker info 看一下当前配置了哪些源临时把第一个源去掉让 Docker 自动 failover 到下一个源再重新 pull 一次。如果所有源都失败了回到第 3.3 节用 curl 脚本测试一下看看是不是源的域名已经无法解析了。5.4 Docker Hub 镜像和 GHCR 镜像的拉取策略有些镜像并不在 Docker Hub 上比如 ghcr.io 开头的镜像。这类镜像如果直接 pull走的链路可能同样不理想。不过加速源通常只管 docker.io不一定支持 ghcr.io 的代理。对于这类镜像我的经验是在镜像源列表里找一个明确支持 ghcr 代理的源或者手动把镜像拉下来再重新打 tag 传输到目标机器。这里补充一个实际可操作的技巧如果你在服务器上需要拉一个 ghcr.io 的镜像但网络访问很慢可以先在一台网络正常的机器上 docker pull 导入镜像再通过 docker save 导出为 tar 包传到服务器最后 docker load 导入。虽然步骤多一点但稳定可控适合在批量部署时使用。5.5 镜像拉取到一半卡住的问题镜像拉取卡住常见原因有两个网络波动导致连接中断但连接状态没有立即释放磁盘空间不足导致层数据写入失败。网络波动导致的卡住通常 CtrlC 中断后重新 docker pull 就能解决。如果反复在同一层卡住很有可能是这个镜像的某层数据在当前链路上不完整换一个加速源往往能绕过。磁盘空间不足则更隐蔽报错可能只在最后阶段出现比如 write /var/lib/docker/tmp: no space left on device。此时需要清理 Docker 的悬空镜像和停止的容器释放空间。我常用的命令是 docker system prune -a --volumes执行前确认你不再需要已停止容器和未使用的镜像。5.6 常见问题速查表现象可能原因快速解决办法docker info 中 Registry Mirrors 为空daemon.json 未生效检查路径、执行 daemon-reload、重启 dockerpull 报 timeout源不可达或网络波动换一个源或调整配置中的源顺序pull 报 certificate error源的证书问题换用 https 地址或直接换源pull 报 manifest unknown镜像名错误或源缓存异常核对镜像名换源重试pull 无限卡层链路不稳定或源限流CtrlC 中断后重试换源no space left on device磁盘或 Docker 目录空间不足清理残留镜像和容器释放空间这张表基本覆盖了我日常运维中遇到的 90% 的镜像拉取问题。遇到问题先对照这张表排查通常不用折腾太久。6. 加速方案之外的三个实用建议6.1 用更小的基础镜像减少拉取压力以 nginx 为例nginx:latest 的体积大约 190MB而 nginx:alpine 只有 45MB 左右。对于日常开发测试、小型服务部署alpine 版本完全够用。基础镜像越小拉取速度越快磁盘占用越少启动也更快。我在实际项目里会尽量选择 alpine 或 slim 标签的镜像。如果项目里有自定义镜像也会基于 alpine 构建而不是用 Ubuntu 或 Debian 的完整基础镜像。这样不仅能降低镜像仓库的存储成本也能显著减少每次部署时拉取镜像的耗时。6.2 固定镜像版本而不是用 latest使用镜像时绑定精确版本号而不是 latest。原因有两点一是可复现性部署环境的镜像版本不会因为远端更新而变化二是省流量拉取相同版本的镜像时如果本地已经有缓存层Docker 会直接复用不需要重复下载。举个例子部署 MySQL 时指定 mysql:8.0.40部署 Redis 时指定 redis:7.2.5。这样即使加速源偶尔抽风你本地已有的镜像层也能减少对网络的依赖。6.3 在内网环境部署私有镜像仓库如果是团队协作或者生产环境给服务器单独部署一个私有镜像仓库才是长久之计。你可以用 registry 镜像起一个私有仓库或者搭建 Harbor。内部服务器先通过加速源拉取镜像然后 push 到私有仓库其他机器统一从私有仓库拉取。这样做的最大价值在于加速源只在初始化时使用一次之后所有机器都走内网速度更快、更稳定也不受公共源可用性的影响。对于有条件的读者这其实是比镜像加速更彻底、更可控的解决方案。7. 最后说几句我的实际体会镜像加速这个事看着简单但真正稳定好用需要一点耐心。我踩过几次坑之后形成的习惯是配置 2 到 3 个源做兜底配置完成后必须实际拉一次镜像验证而不是看了 docker info 就认为万事大吉。我个人目前的首选组合是 docker.1panel.live 配合 docker.m.daocloud.io一个做主力一个做备用。这套组合在最近的日常使用中表现比较稳定拉取热门的 nginx、mysql、redis 等镜像基本能维持较快的速度。当然不同网络环境下表现会有差异你完全可以根据自己的实测结果调整顺序。最后再分享一个小技巧如果你经常需要批量拉取同一组镜像可以把镜像列表写成一个脚本循环执行配合加速源测试脚本使用能在做环境初始化的同时快速验证源是否正常。镜像加速不是一劳永逸的但把它当作环境管理的一部分勤加维护反而能帮你省下大量等待时间。