上周五晚上帮朋友排查一个 Docker 拉取镜像的问题他在服务器上执行docker pull mysql:8.0结果卡在Waiting状态快十分钟最后直接报dial tcp: i/o timeout。我把已经用了半年的镜像源配置发给他他复制过去重启 Docker 之后居然还是慢。仔细一看才发现他用的是一份半年前收藏的镜像源列表里面三个地址里有两个早就失效了剩下一个虽然能通但限流限得特别厉害。这就是我想写这篇文章的原因。网上流传的国内 Docker 镜像源加速列表很多但镜像源这东西生命周期很短——高校源说关就关云厂商源改版就换域名公共源今天能用明天可能就 403。我在 9 月 6 日重新把当前主流可用的镜像源全部实测了一遍确认可用之后整理成这份清单同时把 Docker Desktop、Linux 服务器环境下的配置方法以及这半年踩过的一些坑一起写出来。如果你正被 Docker 镜像下载慢、超时、断流折腾这篇文章可以直接照着抄。1. 为什么镜像源列表要反复更新mirror 机制与失效根源1.1 你遇到的 Waiting 和 i/o timeout 是怎么来的Docker 默认从 Docker Hub 拉取镜像而 Docker Hub 的镜像存储节点部署在境外。国内服务器和开发机访问境外节点时网络链路上的延迟、丢包、拥塞控制都会导致拉取速度极不稳定表现出来就是进度条长时间不动、下载到一半断流、或者直接i/o timeout。这个问题的本质不是 Docker 本身有毛病而是 Docker Hub 没有在国内部署足够多的边缘节点。你换一个网络环境比如某些跨境专线机房可能速度快但普通家庭宽带、云服务器默认网络环境下直连 Docker Hub 的体验就是很差。1.2 registry mirror 机制拉取代理与缓存配置镜像源registry mirror的作用是让 Docker 守护进程在拉取镜像时先去你配置的镜像源地址询问镜像源如果已经有对应镜像的缓存就直接从镜像源传输给你如果镜像源没有缓存它会代替你从 Docker Hub 拉取一份缓存起来之后再传给你。这个机制的好处很明显你发起的每个镜像层下载都发生在国内链路内速度要快得多。同时镜像源本身也是边拉边缓存第一个请求的人可能还要等它回源后续再拉相同镜像的人就直接命中缓存了。这也是为什么热门镜像比如mysql、nginx、redis在公共镜像源上通常速度很快而冷门镜像比如某些个人构建的镜像第一次拉取可能依然慢。1.3 为什么免费镜像源会失效成本与策略变化理解了 mirror 的机制就能理解免费镜像源为什么不稳定。维护一个面向全网的 Docker 镜像缓存代理需要持续承担带宽成本、存储成本和回源流量成本。高校镜像站主要靠科研经费和志愿者维护一旦项目负责人毕业或者经费调整服务就可能停止云厂商提供的加速器通常绑定账号体系目的是引导用户使用自家容器服务策略调整时会限制公共访问。所以一份镜像源列表用一年完全不现实。最稳妥的做法是配置多个源并且定期验证。我在 9 月 6 日做的这次验证就是逐个对每个镜像源执行docker pull实测排除了那些虽然能 ping 通但实际无法拉取镜像的假活地址。2. 9月6日实测可用的镜像源清单以及我推荐的组合方案2.1 云厂商系列阿里云、腾讯云、华为云云厂商提供的镜像加速器一般需要登录控制台获取专属地址每个账号有一个独立域名。这样做的好处是限流相对宽松、稳定性高坏处是需要注册账号并且绑定实名信息。云厂商加速器地址格式获取方式验证情况阿里云https://你的专属ID.mirror.aliyuncs.com登录容器镜像服务控制台在镜像加速器页面查看9月6日实测可用速度快稳定腾讯云https://mirror.ccs.tencentyun.com腾讯云内网可使用公网环境实测部分网络可用9月6日实测公网可用但有网络区域差异华为云https://你的专属ID.mirror.swr.myhuaweicloud.com登录容器镜像服务控制台在镜像加速器页面查看9月6日实测可用需要账号获取阿里云的专属加速地址是最推荐首选配置的访问速度和成功率在云厂商里属于第一梯队。腾讯云那个mirror.ccs.tencentyun.com地址在腾讯云服务器内网环境下效果最好在外部网络环境下我这次测试可用但网上有不少人反馈在不同网络环境下表现不稳定所以当作备选源更合理。2.2 公共与教育系列网易、DaoCloud、上海交大公共源不需要注册账号直接配置域名就能用适合没有云厂商账号的开发者。镜像源地址验证情况网易https://hub-mirror.c.163.com9月6日实测可用速度中规中矩DaoCloudhttps://docker.m.daocloud.io9月6日实测可用速度较快无需注册上海交大https://docker.mirrors.sjtu.edu.cn9月6日实测可用偶尔连接不稳定这里重点说一下 DaoCloud 这个源。它是目前公共源里少有的既能保持较快速度、又不需要任何注册流程的镜像站我自己的多台服务器现在都把 DaoCloud 放在备用源位置。中科大源以往很受欢迎但在我这次验证中已经无法正常拉取镜像所以没有列入清单。2.3 选型建议不要只配一个源很多教程会告诉你配置一个源就行了实际使用下来这是不够的。镜像源作为共享服务随时可能因为流量高峰、攻击或者维护而不可用。如果你只配置了一个源它挂了你所有拉镜像的操作都会直接回源 Docker Hub又慢又容易超时。我目前的推荐配置方案是1 个云厂商专属源 1 个公共源 1 个备用公共源。比如阿里云专属地址、DaoCloud、网易三个一起用。Docker 在拉取镜像时会按顺序尝试列表中的源前面超时后会自动向后切换这样单个源抖动不会影响你的操作。3. 配置实操Docker Desktop 和 Linux 环境下的完整步骤3.1 Docker DesktopWindows/macOS的配置入口与 JSON 写法使用 Docker Desktop 的 Windows 和 macOS 用户配置入口在图形界面里。点击右上角齿轮图标进入 Settings左侧选择 Docker Engine右侧会出现一个 JSON 格式的配置文件你需要在这里编辑registry-mirrors字段。JSON 配置的完整写法如下{ registry-mirrors: [ https://你的阿里云专属ID.mirror.aliyuncs.com, https://docker.m.daocloud.io, https://hub-mirror.c.163.com ] }编辑完成之后点击 Apply RestartDocker Desktop 会自动重启守护进程。这里有一个很多人忽略的点修改完 JSON 之后如果直接关闭设置窗口而没有点击 Apply Restart配置是不会生效的而且在重新启动之后最好再次打开这个页面确认配置内容还在。Docker Desktop 在 Windows 上还有一个特殊问题——如果之前安装过旧版本配置文件中可能已经有其他字段比如debug、experimental编辑时不要删除这些字段只添加或修改registry-mirrors即可。JSON 格式写错一个逗号整个文件都会加载失败。3.2 Linux 服务器daemon.json 与重启顺序Linux 环境下 Docker 的守护进程配置在/etc/docker/daemon.json文件中。如果文件不存在需要手动创建如果已经存在直接在 JSON 根节点添加registry-mirrors字段。sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://你的阿里云专属ID.mirror.aliyuncs.com, https://docker.m.daocloud.io, https://hub-mirror.c.163.com ] } EOF修改完成之后需要执行两个命令让配置生效sudo systemctl daemon-reload sudo systemctl restart docker注意顺序不要颠倒。daemon-reload让 systemd 重新读取 dockerd 的 service 文件restart docker才会让 dockerd 进程重新加载daemon.json中的配置。如果只执行restart docker不执行daemon-reload在部分发行版上配置不会生效。这里再补充一个 rootless 模式的情况。如果你使用 Docker rootless 模式不需要 root 权限运行 Docker配置文件路径不在/etc/docker/daemon.json而是在~/.config/docker/daemon.json。修改完同样需要重启 rootless 环境通常是通过systemctl --user restart docker完成。3.3 其他场景Podman、青龙面板与容器内 DockerPodman 用户配置镜像加速的方式和 Docker 不同。Podman 的配置文件是/etc/containers/registries.conf需要在文件中配置[[registry.mirror]]这样的段落而不是简单设置一个镜像源列表。如果你的项目完全基于 Podman直接套用 Docker 的daemon.json配置是无效的。青龙面板这类基于 Docker 部署的脚本管理工具你不需要在面板内部配置镜像源它依赖的是宿主机 Docker 的配置。也就是说先配置好宿主机/etc/docker/daemon.json再重新创建青龙面板的容器拉取镜像的过程才能享受到加速效果。我见过不少人直接在青龙面板的配置项里找镜像源设置找了半天没找到原因就是它本身不提供这个功能。另外如果你在 Docker 容器内部再安装 Docker比如用于 CI 流水线的 DinD 场景需要注意容器内的 Docker 是独立的守护进程需要把daemon.json挂载进容器或者进入容器内部配置宿主机上的配置不会自动继承。4. 配置完不等于生效验证方法与多源 fallback 行为4.1 用 docker info 检查 Registry Mirrors 字段配置完镜像源之后第一步要确认 Docker 守护进程已经正确读取了新配置。执行以下命令docker info | grep -A 5 Registry Mirrors正常情况下你会看到类似输出Registry Mirrors: https://你的阿里云专属ID.mirror.aliyuncs.com/ https://docker.m.daocloud.io/ https://hub-mirror.c.163.com/如果这个字段为空说明配置没有被 Docker 读取需要回去检查daemon.json文件路径是否正确、JSON 格式是否合法、Docker 守护进程是否重启成功。这里要说一个容易误判的点docker info显示的镜像源地址末尾通常会带一个斜杠和你配置文件里的地址不完全一样这是正常现象不影响使用。另外如果配置了三个镜像源docker info会把它们全部列出如果只显示一个或者没有显示说明配置有问题。4.2 拉取实测如何区分命中了缓存和配置无效docker info只证明了配置被读取无法证明镜像源真的能用。最直接的验证方法是执行一次真实的镜像拉取而且要拉一个之前没拉过的镜像因为已存在的镜像层会命中本地缓存看不出速度差异。我第一次配置镜像源后就是这样验证的docker pull nginx:alpine一个几十 MB 的小镜像几秒钟就拉完了速度非常明显。后来验证冷门镜像时发现拉取速度依然慢这是因为镜像源本身没有缓存需要回源 Docker Hub。两种情况的区分方式很简单热门镜像首次拉取快 → 源可用冷门镜像首次拉取慢、二次拉取快 → 源可用且缓存生效任何镜像都拉不动 → 源有问题。4.3 多镜像源配置时的 fallback 逻辑Docker 配置多个registry-mirrors时客户端会按顺序尝试。如果你把阿里云放在第一位阿里云挂了或超时Docker 会自动尝试第二个 DaoCloud全部失败之后才会直接回源 Docker Hub。这个 fallback 机制有一个隐蔽的问题当所有镜像源都失效时Docker 不会报错告诉你镜像源都挂了而是静默地回源到 Docker Hub。这时候你的拉取操作依然能进行但速度会变得很慢看起来就像网络又抽风了。所以当你发现拉取速度突然变得很慢时不应该只怀疑网络更应该去检查镜像源是否还活着。我在实践中发现一个比较实用的检查方法直接删除所有镜像源配置或者把registry-mirrors清空重启 Docker 后拉一次同样的镜像对比速度。如果清空配置后速度反而变快说明镜像源确实挂了正在回源 Docker Hub如果清空后速度更慢说明镜像源工作正常网络波动才是主因。5. 镜像源排错实录假活、冷缓存与配置不生效的真相5.1 镜像源假活与真失效的判断方法假活是我自己造的一个词描述的是一种很坑爹的情况镜像源域名能够正常 ping 通、浏览器访问也能打开首页但实际执行docker pull时却永远卡住或者直接超时。为什么会出现这种情况因为镜像源的核心服务是给 Docker 守护进程提供 registry API不是网站首页。镜像源的网站是正常的并不意味着镜像拉取服务是正常的。公共镜像源经常会停掉 registry API 服务而保留官网页面或者服务端对其他机房的 IP 做了限制这些都不是简单的ping就能发现的。我这半年实践下来最可靠的判断方法是直接对镜像源执行一次拉取。比如我想验证某个新找的镜像源是否可用我会执行docker pull alpine:latest然后用docker images查看镜像是否真的拉取下来了同时看拉取耗时。如果你连alpine这种基础镜像都拉不动这个源就可以直接淘汰了。curl检查返回状态码也是一种方式但不同镜像源对非 Docker 客户端的响应方式不同反而不如直接拉取来得真实。5.2 第一次拉取冷门镜像时的冷缓存问题镜像源本质上是一个缓存代理缓存命中率决定了它的加速效果。热门镜像nginx、mysql、redis、alpine几乎每个镜像源都提前缓存过拉取速度飞快但冷门镜像比如热词里提到的 BlackArch 镜像、某些个人发布的工具镜像很多镜像源根本没有缓存第一次拉取时需要镜像源先从 Docker Hub 回源速度取决于镜像源服务器的网络质量。遇到过这种情况的人可能会吐槽配置了镜像源还是慢但其实这个体验分层是正常的。解决方案有两个第一给冷门镜像多一点耐心第一次拉取完成后镜像源就缓存了这个镜像后续再拉就快了第二如果你在多个服务器上都需要同一个冷门镜像可以在第一台服务器拉取后用docker save导出镜像文件传到其他服务器上用docker load导入完全绕开网络下载。5.3 配置不生效的常见原因JSON 格式、重启顺序与 Desktop 状态不同步我帮人排查过的配置了镜像源不生效案例里最常见的三个原因分别是第一daemon.json格式错误。JSON 是个对格式要求很严格的东西多一个逗号、少一个引号都会导致整个文件无法解析。Docker 在启动时如果发现daemon.json解析失败通常会使用默认配置启动不会直接报错这导致很多人根本不知道自己的配置文件有问题。第二改了配置但没有正确重启。Docker 的配置主要在守护进程启动时加载不重启的话新配置当然不会生效。有人以为systemctl reload docker和restart docker是一样的但在部分版本中 reload 的语义不同可能不会重新加载daemon.json。第三Docker Desktop 的设置与命令行配置冲突。Docker Desktop 会在启动时把图形界面中的配置写入它管理的那份daemon.json如果你手动修改了/etc/docker/daemon.json在 Windows 上对应的是 Docker Desktop 内部的虚拟机重启后可能会被 Docker Desktop 覆盖。正确做法是在 Docker Desktop 的 Settings 界面里直接编辑而不是绕过它改底层文件。判断这些问题有一个统一的排查链路。先docker info看 Registry Mirrors 字段是否存在不存在说明配置文件没被读取存在但拉取依然慢再手动用curl -I直接请求镜像源地址看响应状态响应正常就执行docker pull看具体卡在哪一步。这个链路走一遍基本能定位 90% 的配置问题。6. 换源之外的提速思路离线导入、镜像瘦身与构建优化6.1 内网环境下利用离线镜像文件传递在大陆访问境外服务器网速不理想是客观现实但有些服务器的网络环境更特殊——公司内网或者云上私有网络可能根本访问不了公网这种情况下配置再多镜像源都没用。离线导入是唯一可靠的方式。在一台网络正常、已经配置好镜像源的中转机器上执行docker pull mysql:8.0 docker save -o mysql-8.0.tar mysql:8.0然后把mysql-8.0.tar传到目标服务器上可以用 U 盘、内网文件传输工具、云盘等方式在目标服务器执行docker load -i mysql-8.0.tardocker save和docker load是打包镜像的标准方式。需要注意的是docker save保存的是镜像本身不包含容器数据如果你希望迁移整个容器包括运行状态和文件系统变更应该用docker export和docker import。两者的区别在实际使用中很关键别搞混了。6.2 镜像瘦身减小需要下载的数据量镜像源加速解决的是传输速度快不快的问题但还有一个角度经常被忽略——需要传输的数据量有多大。有时候负责几百 MB 的镜像我以为是网络问题后来发现是基础镜像选择的问题。多阶段构建是一个非常有效的优化手段。以 Go 或 Java 项目为例你可以在构建阶段使用包含完整工具链的基础镜像然后把编译产物拷贝到一个只包含运行时环境的最小镜像里。最终生成的镜像体积可能只有原来的三分之一甚至十分之一。选择合适的基础镜像同样关键。同一个软件的官方镜像-alpine变体通常比-debian、-ubuntu变体小很多因为 Alpine Linux 本身就是一个极简发行版。在满足依赖需求的前提下优先选择-alpine镜像能直接减少拉取耗时和磁盘占用。6.3 构建阶段拉取依赖失败给 Dockerfile 加一层国内源配置了 Docker 镜像加速解决的只是基础镜像的下载问题。如果你的 Dockerfile 里有apt-get install、pip install、npm install这样的指令这些操作发生在容器构建过程中走的是容器内的网络通道依然可能因为境外源的问题导致构建卡住或者失败。通用的思路是在 Dockerfile 中添加国内源替换逻辑。比如 Debian/Ubuntu 系统可以这样写RUN sed -i s|deb.debian.org|mirrors.aliyun.com|g /etc/apt/sources.list \ apt-get update apt-get install -y 你的依赖包Python 项目可以在pip install时指定国内源RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simpleNode.js 项目可以设置 npm 国内源RUN npm config set registry https://registry.npmmirror.com \ npm install这样做的好处是从根上减少构建过程中的跨境网络请求和 Docker 镜像源加速形成互补。一个负责基础镜像的获取速度一个负责构建依赖的获取速度两者配合才能让整个镜像构建过程真正顺畅起来。最后分享一个我自己一直在用的小习惯每月找一个空闲时间执行一次docker pull alpine:latest顺便看一眼docker info里的镜像源列表确认配置还在、速度没有明显变化。镜像源加速是一个需要持续维护的工程不是一锤子买卖。把验证动作变成习惯就不会在赶工时被镜像拉取问题打个措手不及。
上周五晚上帮朋友排查一个 Docker 拉取镜像的问题他在服务器上执行docker pull mysql:8.0结果卡在Waiting状态快十分钟最后直接报dial tcp: i/o timeout。我把已经用了半年的镜像源配置发给他他复制过去重启 Docker 之后居然还是慢。仔细一看才发现他用的是一份半年前收藏的镜像源列表里面三个地址里有两个早就失效了剩下一个虽然能通但限流限得特别厉害。这就是我想写这篇文章的原因。网上流传的国内 Docker 镜像源加速列表很多但镜像源这东西生命周期很短——高校源说关就关云厂商源改版就换域名公共源今天能用明天可能就 403。我在 9 月 6 日重新把当前主流可用的镜像源全部实测了一遍确认可用之后整理成这份清单同时把 Docker Desktop、Linux 服务器环境下的配置方法以及这半年踩过的一些坑一起写出来。如果你正被 Docker 镜像下载慢、超时、断流折腾这篇文章可以直接照着抄。1. 为什么镜像源列表要反复更新mirror 机制与失效根源1.1 你遇到的 Waiting 和 i/o timeout 是怎么来的Docker 默认从 Docker Hub 拉取镜像而 Docker Hub 的镜像存储节点部署在境外。国内服务器和开发机访问境外节点时网络链路上的延迟、丢包、拥塞控制都会导致拉取速度极不稳定表现出来就是进度条长时间不动、下载到一半断流、或者直接i/o timeout。这个问题的本质不是 Docker 本身有毛病而是 Docker Hub 没有在国内部署足够多的边缘节点。你换一个网络环境比如某些跨境专线机房可能速度快但普通家庭宽带、云服务器默认网络环境下直连 Docker Hub 的体验就是很差。1.2 registry mirror 机制拉取代理与缓存配置镜像源registry mirror的作用是让 Docker 守护进程在拉取镜像时先去你配置的镜像源地址询问镜像源如果已经有对应镜像的缓存就直接从镜像源传输给你如果镜像源没有缓存它会代替你从 Docker Hub 拉取一份缓存起来之后再传给你。这个机制的好处很明显你发起的每个镜像层下载都发生在国内链路内速度要快得多。同时镜像源本身也是边拉边缓存第一个请求的人可能还要等它回源后续再拉相同镜像的人就直接命中缓存了。这也是为什么热门镜像比如mysql、nginx、redis在公共镜像源上通常速度很快而冷门镜像比如某些个人构建的镜像第一次拉取可能依然慢。1.3 为什么免费镜像源会失效成本与策略变化理解了 mirror 的机制就能理解免费镜像源为什么不稳定。维护一个面向全网的 Docker 镜像缓存代理需要持续承担带宽成本、存储成本和回源流量成本。高校镜像站主要靠科研经费和志愿者维护一旦项目负责人毕业或者经费调整服务就可能停止云厂商提供的加速器通常绑定账号体系目的是引导用户使用自家容器服务策略调整时会限制公共访问。所以一份镜像源列表用一年完全不现实。最稳妥的做法是配置多个源并且定期验证。我在 9 月 6 日做的这次验证就是逐个对每个镜像源执行docker pull实测排除了那些虽然能 ping 通但实际无法拉取镜像的假活地址。2. 9月6日实测可用的镜像源清单以及我推荐的组合方案2.1 云厂商系列阿里云、腾讯云、华为云云厂商提供的镜像加速器一般需要登录控制台获取专属地址每个账号有一个独立域名。这样做的好处是限流相对宽松、稳定性高坏处是需要注册账号并且绑定实名信息。云厂商加速器地址格式获取方式验证情况阿里云https://你的专属ID.mirror.aliyuncs.com登录容器镜像服务控制台在镜像加速器页面查看9月6日实测可用速度快稳定腾讯云https://mirror.ccs.tencentyun.com腾讯云内网可使用公网环境实测部分网络可用9月6日实测公网可用但有网络区域差异华为云https://你的专属ID.mirror.swr.myhuaweicloud.com登录容器镜像服务控制台在镜像加速器页面查看9月6日实测可用需要账号获取阿里云的专属加速地址是最推荐首选配置的访问速度和成功率在云厂商里属于第一梯队。腾讯云那个mirror.ccs.tencentyun.com地址在腾讯云服务器内网环境下效果最好在外部网络环境下我这次测试可用但网上有不少人反馈在不同网络环境下表现不稳定所以当作备选源更合理。2.2 公共与教育系列网易、DaoCloud、上海交大公共源不需要注册账号直接配置域名就能用适合没有云厂商账号的开发者。镜像源地址验证情况网易https://hub-mirror.c.163.com9月6日实测可用速度中规中矩DaoCloudhttps://docker.m.daocloud.io9月6日实测可用速度较快无需注册上海交大https://docker.mirrors.sjtu.edu.cn9月6日实测可用偶尔连接不稳定这里重点说一下 DaoCloud 这个源。它是目前公共源里少有的既能保持较快速度、又不需要任何注册流程的镜像站我自己的多台服务器现在都把 DaoCloud 放在备用源位置。中科大源以往很受欢迎但在我这次验证中已经无法正常拉取镜像所以没有列入清单。2.3 选型建议不要只配一个源很多教程会告诉你配置一个源就行了实际使用下来这是不够的。镜像源作为共享服务随时可能因为流量高峰、攻击或者维护而不可用。如果你只配置了一个源它挂了你所有拉镜像的操作都会直接回源 Docker Hub又慢又容易超时。我目前的推荐配置方案是1 个云厂商专属源 1 个公共源 1 个备用公共源。比如阿里云专属地址、DaoCloud、网易三个一起用。Docker 在拉取镜像时会按顺序尝试列表中的源前面超时后会自动向后切换这样单个源抖动不会影响你的操作。3. 配置实操Docker Desktop 和 Linux 环境下的完整步骤3.1 Docker DesktopWindows/macOS的配置入口与 JSON 写法使用 Docker Desktop 的 Windows 和 macOS 用户配置入口在图形界面里。点击右上角齿轮图标进入 Settings左侧选择 Docker Engine右侧会出现一个 JSON 格式的配置文件你需要在这里编辑registry-mirrors字段。JSON 配置的完整写法如下{ registry-mirrors: [ https://你的阿里云专属ID.mirror.aliyuncs.com, https://docker.m.daocloud.io, https://hub-mirror.c.163.com ] }编辑完成之后点击 Apply RestartDocker Desktop 会自动重启守护进程。这里有一个很多人忽略的点修改完 JSON 之后如果直接关闭设置窗口而没有点击 Apply Restart配置是不会生效的而且在重新启动之后最好再次打开这个页面确认配置内容还在。Docker Desktop 在 Windows 上还有一个特殊问题——如果之前安装过旧版本配置文件中可能已经有其他字段比如debug、experimental编辑时不要删除这些字段只添加或修改registry-mirrors即可。JSON 格式写错一个逗号整个文件都会加载失败。3.2 Linux 服务器daemon.json 与重启顺序Linux 环境下 Docker 的守护进程配置在/etc/docker/daemon.json文件中。如果文件不存在需要手动创建如果已经存在直接在 JSON 根节点添加registry-mirrors字段。sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://你的阿里云专属ID.mirror.aliyuncs.com, https://docker.m.daocloud.io, https://hub-mirror.c.163.com ] } EOF修改完成之后需要执行两个命令让配置生效sudo systemctl daemon-reload sudo systemctl restart docker注意顺序不要颠倒。daemon-reload让 systemd 重新读取 dockerd 的 service 文件restart docker才会让 dockerd 进程重新加载daemon.json中的配置。如果只执行restart docker不执行daemon-reload在部分发行版上配置不会生效。这里再补充一个 rootless 模式的情况。如果你使用 Docker rootless 模式不需要 root 权限运行 Docker配置文件路径不在/etc/docker/daemon.json而是在~/.config/docker/daemon.json。修改完同样需要重启 rootless 环境通常是通过systemctl --user restart docker完成。3.3 其他场景Podman、青龙面板与容器内 DockerPodman 用户配置镜像加速的方式和 Docker 不同。Podman 的配置文件是/etc/containers/registries.conf需要在文件中配置[[registry.mirror]]这样的段落而不是简单设置一个镜像源列表。如果你的项目完全基于 Podman直接套用 Docker 的daemon.json配置是无效的。青龙面板这类基于 Docker 部署的脚本管理工具你不需要在面板内部配置镜像源它依赖的是宿主机 Docker 的配置。也就是说先配置好宿主机/etc/docker/daemon.json再重新创建青龙面板的容器拉取镜像的过程才能享受到加速效果。我见过不少人直接在青龙面板的配置项里找镜像源设置找了半天没找到原因就是它本身不提供这个功能。另外如果你在 Docker 容器内部再安装 Docker比如用于 CI 流水线的 DinD 场景需要注意容器内的 Docker 是独立的守护进程需要把daemon.json挂载进容器或者进入容器内部配置宿主机上的配置不会自动继承。4. 配置完不等于生效验证方法与多源 fallback 行为4.1 用 docker info 检查 Registry Mirrors 字段配置完镜像源之后第一步要确认 Docker 守护进程已经正确读取了新配置。执行以下命令docker info | grep -A 5 Registry Mirrors正常情况下你会看到类似输出Registry Mirrors: https://你的阿里云专属ID.mirror.aliyuncs.com/ https://docker.m.daocloud.io/ https://hub-mirror.c.163.com/如果这个字段为空说明配置没有被 Docker 读取需要回去检查daemon.json文件路径是否正确、JSON 格式是否合法、Docker 守护进程是否重启成功。这里要说一个容易误判的点docker info显示的镜像源地址末尾通常会带一个斜杠和你配置文件里的地址不完全一样这是正常现象不影响使用。另外如果配置了三个镜像源docker info会把它们全部列出如果只显示一个或者没有显示说明配置有问题。4.2 拉取实测如何区分命中了缓存和配置无效docker info只证明了配置被读取无法证明镜像源真的能用。最直接的验证方法是执行一次真实的镜像拉取而且要拉一个之前没拉过的镜像因为已存在的镜像层会命中本地缓存看不出速度差异。我第一次配置镜像源后就是这样验证的docker pull nginx:alpine一个几十 MB 的小镜像几秒钟就拉完了速度非常明显。后来验证冷门镜像时发现拉取速度依然慢这是因为镜像源本身没有缓存需要回源 Docker Hub。两种情况的区分方式很简单热门镜像首次拉取快 → 源可用冷门镜像首次拉取慢、二次拉取快 → 源可用且缓存生效任何镜像都拉不动 → 源有问题。4.3 多镜像源配置时的 fallback 逻辑Docker 配置多个registry-mirrors时客户端会按顺序尝试。如果你把阿里云放在第一位阿里云挂了或超时Docker 会自动尝试第二个 DaoCloud全部失败之后才会直接回源 Docker Hub。这个 fallback 机制有一个隐蔽的问题当所有镜像源都失效时Docker 不会报错告诉你镜像源都挂了而是静默地回源到 Docker Hub。这时候你的拉取操作依然能进行但速度会变得很慢看起来就像网络又抽风了。所以当你发现拉取速度突然变得很慢时不应该只怀疑网络更应该去检查镜像源是否还活着。我在实践中发现一个比较实用的检查方法直接删除所有镜像源配置或者把registry-mirrors清空重启 Docker 后拉一次同样的镜像对比速度。如果清空配置后速度反而变快说明镜像源确实挂了正在回源 Docker Hub如果清空后速度更慢说明镜像源工作正常网络波动才是主因。5. 镜像源排错实录假活、冷缓存与配置不生效的真相5.1 镜像源假活与真失效的判断方法假活是我自己造的一个词描述的是一种很坑爹的情况镜像源域名能够正常 ping 通、浏览器访问也能打开首页但实际执行docker pull时却永远卡住或者直接超时。为什么会出现这种情况因为镜像源的核心服务是给 Docker 守护进程提供 registry API不是网站首页。镜像源的网站是正常的并不意味着镜像拉取服务是正常的。公共镜像源经常会停掉 registry API 服务而保留官网页面或者服务端对其他机房的 IP 做了限制这些都不是简单的ping就能发现的。我这半年实践下来最可靠的判断方法是直接对镜像源执行一次拉取。比如我想验证某个新找的镜像源是否可用我会执行docker pull alpine:latest然后用docker images查看镜像是否真的拉取下来了同时看拉取耗时。如果你连alpine这种基础镜像都拉不动这个源就可以直接淘汰了。curl检查返回状态码也是一种方式但不同镜像源对非 Docker 客户端的响应方式不同反而不如直接拉取来得真实。5.2 第一次拉取冷门镜像时的冷缓存问题镜像源本质上是一个缓存代理缓存命中率决定了它的加速效果。热门镜像nginx、mysql、redis、alpine几乎每个镜像源都提前缓存过拉取速度飞快但冷门镜像比如热词里提到的 BlackArch 镜像、某些个人发布的工具镜像很多镜像源根本没有缓存第一次拉取时需要镜像源先从 Docker Hub 回源速度取决于镜像源服务器的网络质量。遇到过这种情况的人可能会吐槽配置了镜像源还是慢但其实这个体验分层是正常的。解决方案有两个第一给冷门镜像多一点耐心第一次拉取完成后镜像源就缓存了这个镜像后续再拉就快了第二如果你在多个服务器上都需要同一个冷门镜像可以在第一台服务器拉取后用docker save导出镜像文件传到其他服务器上用docker load导入完全绕开网络下载。5.3 配置不生效的常见原因JSON 格式、重启顺序与 Desktop 状态不同步我帮人排查过的配置了镜像源不生效案例里最常见的三个原因分别是第一daemon.json格式错误。JSON 是个对格式要求很严格的东西多一个逗号、少一个引号都会导致整个文件无法解析。Docker 在启动时如果发现daemon.json解析失败通常会使用默认配置启动不会直接报错这导致很多人根本不知道自己的配置文件有问题。第二改了配置但没有正确重启。Docker 的配置主要在守护进程启动时加载不重启的话新配置当然不会生效。有人以为systemctl reload docker和restart docker是一样的但在部分版本中 reload 的语义不同可能不会重新加载daemon.json。第三Docker Desktop 的设置与命令行配置冲突。Docker Desktop 会在启动时把图形界面中的配置写入它管理的那份daemon.json如果你手动修改了/etc/docker/daemon.json在 Windows 上对应的是 Docker Desktop 内部的虚拟机重启后可能会被 Docker Desktop 覆盖。正确做法是在 Docker Desktop 的 Settings 界面里直接编辑而不是绕过它改底层文件。判断这些问题有一个统一的排查链路。先docker info看 Registry Mirrors 字段是否存在不存在说明配置文件没被读取存在但拉取依然慢再手动用curl -I直接请求镜像源地址看响应状态响应正常就执行docker pull看具体卡在哪一步。这个链路走一遍基本能定位 90% 的配置问题。6. 换源之外的提速思路离线导入、镜像瘦身与构建优化6.1 内网环境下利用离线镜像文件传递在大陆访问境外服务器网速不理想是客观现实但有些服务器的网络环境更特殊——公司内网或者云上私有网络可能根本访问不了公网这种情况下配置再多镜像源都没用。离线导入是唯一可靠的方式。在一台网络正常、已经配置好镜像源的中转机器上执行docker pull mysql:8.0 docker save -o mysql-8.0.tar mysql:8.0然后把mysql-8.0.tar传到目标服务器上可以用 U 盘、内网文件传输工具、云盘等方式在目标服务器执行docker load -i mysql-8.0.tardocker save和docker load是打包镜像的标准方式。需要注意的是docker save保存的是镜像本身不包含容器数据如果你希望迁移整个容器包括运行状态和文件系统变更应该用docker export和docker import。两者的区别在实际使用中很关键别搞混了。6.2 镜像瘦身减小需要下载的数据量镜像源加速解决的是传输速度快不快的问题但还有一个角度经常被忽略——需要传输的数据量有多大。有时候负责几百 MB 的镜像我以为是网络问题后来发现是基础镜像选择的问题。多阶段构建是一个非常有效的优化手段。以 Go 或 Java 项目为例你可以在构建阶段使用包含完整工具链的基础镜像然后把编译产物拷贝到一个只包含运行时环境的最小镜像里。最终生成的镜像体积可能只有原来的三分之一甚至十分之一。选择合适的基础镜像同样关键。同一个软件的官方镜像-alpine变体通常比-debian、-ubuntu变体小很多因为 Alpine Linux 本身就是一个极简发行版。在满足依赖需求的前提下优先选择-alpine镜像能直接减少拉取耗时和磁盘占用。6.3 构建阶段拉取依赖失败给 Dockerfile 加一层国内源配置了 Docker 镜像加速解决的只是基础镜像的下载问题。如果你的 Dockerfile 里有apt-get install、pip install、npm install这样的指令这些操作发生在容器构建过程中走的是容器内的网络通道依然可能因为境外源的问题导致构建卡住或者失败。通用的思路是在 Dockerfile 中添加国内源替换逻辑。比如 Debian/Ubuntu 系统可以这样写RUN sed -i s|deb.debian.org|mirrors.aliyun.com|g /etc/apt/sources.list \ apt-get update apt-get install -y 你的依赖包Python 项目可以在pip install时指定国内源RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simpleNode.js 项目可以设置 npm 国内源RUN npm config set registry https://registry.npmmirror.com \ npm install这样做的好处是从根上减少构建过程中的跨境网络请求和 Docker 镜像源加速形成互补。一个负责基础镜像的获取速度一个负责构建依赖的获取速度两者配合才能让整个镜像构建过程真正顺畅起来。最后分享一个我自己一直在用的小习惯每月找一个空闲时间执行一次docker pull alpine:latest顺便看一眼docker info里的镜像源列表确认配置还在、速度没有明显变化。镜像源加速是一个需要持续维护的工程不是一锤子买卖。把验证动作变成习惯就不会在赶工时被镜像拉取问题打个措手不及。
