镜像拉取慢、超时或中途断开，是本地开发和 CI 流水线里很常见的问题。一个几百 MB 的镜像卡上十几分钟，构建进度也跟着停住。阿里云 Docker 加速器是处理这类问题的常用办法。本文先说明它为什么有效，再用一个实际案例讲配置、验证，以及配完仍然失败时怎么排查。
默认拉取为什么慢
Docker 默认从 Docker Hub 拉取镜像。跨境链路、运营商路由和节点负载都会影响访问速度。访问境外仓库时，延迟高、丢包多，镜像分层多或单层较大时，问题更容易暴露。
加速器的做法是在国内放置镜像缓存节点。本地 Docker 客户端先请求就近节点。节点有缓存就直接返回，没有就回源拉取，并保存下来供下次使用。使用者只需修改 Docker 守护进程的配置，docker pull 命令通常不用改。
阿里云容器镜像服务（ACR）会给每个账号分配一个专属加速地址，格式一般是 https://<专属ID>.mirror.aliyuncs.com。这个地址和账号绑定。文档里的示例值只用来理解格式，实际配置请以控制台显示的地址为准。
获取专属加速地址
登录阿里云控制台，进入容器镜像服务（ACR）。在左侧菜单中找到镜像工具或镜像加速器相关页面，复制页面给出的专属地址。页面通常还会让你选择操作系统和 Docker 版本。选错的话，后面的配置说明可能对不上，需要按自己的环境重新选。
如果账号还没有开通容器镜像服务，先完成开通。个人版通常足够学习和小规模测试。企业场景的计费和配额请以官方价格页为准。
配置步骤
以 Linux 服务器为例。开始前先备份已有的 /etc/docker/daemon.json。如果文件不存在，就新建一个。
- 写入 registry-mirrors 字段。 把刚才复制的专属地址填进去。如果文件里已有日志或存储驱动等其他配置，保留原内容，只在 JSON 对象里增加这一项。
- 重新加载配置。 执行 systemctl daemon-reload。
- 重启 Docker。 执行 systemctl restart docker。重启 Docker 服务时，运行中的容器可能受影响，建议在维护窗口操作。
- 检查是否生效。 执行 docker info，看 Registry Mirrors 段是否显示刚才配置的地址。
一份最小配置如下，ID 替换为自己的专属值：
{ “registry-mirrors”: [“https://<专属ID>.mirror.aliyuncs.com”] }
JSON 对格式要求很严。多一个逗号、少一个引号或中括号没闭合，Docker 服务就无法启动。修改后先执行 python -m json.tool /etc/docker/daemon.json 校验，确认没有报错再重启服务。这一步能省掉不少排错时间。
案例：CI 流水线的拉取耗时
某团队的 CI 流水线每次构建都要拉取 node:18、nginx 和一个内部基础镜像。流水线跑在华东地域的一台云主机上。没有配置加速器时，仅镜像拉取阶段就要 6 到 9 分钟。偶尔因超时，整条流水线失败，需要人工重跑。
团队的处理分四步：
- 在同地域创建 ACR 实例，获取该账号的专属加速地址。
- 通过配置管理工具，把统一的 daemon.json 下发到所有构建节点。
- 把高频使用的基础镜像同步到私有仓库，让加速器和私有仓库一起分担拉取压力。
- 在流水线里加一行拉取耗时日志，方便前后对比。
调整后，拉取阶段的耗时缩短了，超时失败基本没有再出现。这个结论是定性的，团队没有做严格的基准测试。具体收益取决于网络环境、镜像大小和缓存命中情况。如果需要具体数字，可以在自己的环境里用同一份镜像列表多跑几次，记录每次的耗时。
验证与排错
配置完成后，可以用三种方法确认加速器是否生效：
- 执行 docker info，确认 Registry Mirrors 里有专属地址。这说明配置已被读取，但不能证明拉取一定走了加速。
- 选一个体积较大的镜像，用 time docker pull 记录耗时，和未配置前的数据对比。同一镜像第二次拉取会因本地已有分层而很快，所以测试前要先删除本地镜像。在测试机上操作，并确认没有容器依赖它。
- 查看 journalctl -u docker 日志，排查服务启动失败或拉取报错的原因。报错信息通常会直接写出失败的地址和原因。
常见问题大致分三类。
第一类是服务无法启动，多半是 daemon.json 格式有误，按前面的方法校验即可。第二类是 docker info 里看不到加速地址，通常是忘了执行 daemon-reload，或者没有重启服务。第三类是拉取仍然很慢或超时。原因可能是所选地域不合适、本地网络出口受限，或目标镜像不在缓存中。如果服务器通过代理上网，还要检查 Docker 服务的代理环境变量是否指向了不可用的地址。这时需要用网络测试工具分段检查，确认延迟和丢包出现在哪一段。
使用注意事项
加速器只改变拉取路径，不改变镜像本身的可信度。生产环境中仍需注意以下几点：
- 优先使用带版本号的镜像标签。依赖 latest 时，同一条构建命令在不同时间可能拉到不同内容。
- 关键镜像拉取后，可以核对 digest，确认内容与预期一致。
- 专属加速地址与账号绑定，不要把完整地址写进公开文章、代码仓库或截图里。
- 同时使用私有仓库时，先定下镜像命名规则。否则不同来源的同名镜像容易互相覆盖。
小结
配置本身很简单，只需三步：获取专属地址，修改 daemon.json，重启服务。拉取速度和稳定性更多取决于对网络环境的判断、镜像版本的管理，以及流水线里是否形成固定的拉取习惯。建议先在测试机上完成配置并记录基线数据，确认效果后再推广到生产环境。
