国内Docker镜像加速配置指南：原理、实践与失效排查

Docker镜像加速registry-mirrorscontainerd配置

于 2026-10-01 04:54:26 修改

·本内容遵循CC 4.0 BY-SA版权协议

1. 为什么国内拉取Docker镜像这件事值得单独写一篇

先把结论摆在前面：国内环境里用Docker，最影响日常效率的环节往往不是写Dockerfile，也不是compose编排，而是镜像拉取。一个几百MB的基础镜像，网络顺畅时几十秒搞定，网络抖动时能卡上十几分钟甚至直接超时失败。尤其是最近两年，很多公开的加速地址陆续失效，网上搜到的“最新可用列表”点进去一半是404，另一半是限速到几十KB每秒，非常折磨人。

这篇内容面向的是所有在国内网络环境下使用Docker的开发者，不管你是刚在Windows上装完Docker Desktop的新手，还是已经在服务器上跑了几年容器的老手，都能从里面找到能直接抄的配置。我会把镜像加速的原理、配置方式、验证手段、失效排查、以及containerd和Docker Desktop这两条不同链路的差异全部讲清楚，而不是甩给你一个列表就完事。因为列表会过期，但排查和配置的方法不会。

需要提前说明的是，镜像加速地址的可用性变化非常快，任何一份“列表”都只能作为某个时间点的参考。所以这篇的重点是方法论加当前可参考的候选源，你照着配完，再按我给的验证步骤跑一遍，基本就能判断哪个源在你所在的网络环境下是真正能用的。

2. 镜像加速到底加速了什么：先把原理讲透

2.1 Docker拉取镜像的完整链路

很多人以为docker pull就是“从Docker官网下载”，其实这条链路比想象中长。当你执行docker pull nginx:latest时，大致经历这么几步：

Docker客户端解析镜像名，补全成完整地址，默认是docker.io/library/nginx:latest。
客户端向registry发起请求，先拿manifest（清单），里面记录了这个镜像有哪些层、每层的摘要值。
根据manifest里的层信息，逐层下载blob数据。
下载完成后在本地解压、组装成可运行的镜像。

问题就出在第2步和第3步。默认情况下，这些请求都指向海外的registry端点，国内访问时延迟高、丢包多，manifest请求可能就要等好几秒，层下载更是容易中断。镜像加速的本质，就是把这部分请求重定向到一个国内的缓存节点，由这个节点替你回源拉取并缓存，你从就近的节点拿数据，速度自然快。

2.2 registry-mirrors和containerd是两套配置

这是最容易踩坑的地方。很多人改了/etc/docker/daemon.json里的registry-mirrors，重启Docker后发现还是慢，原因往往是他们的容器运行时根本不是dockerd，而是containerd。

dockerd链路：配置写在daemon.json的registry-mirrors字段，改完systemctl restart docker生效。
containerd链路：配置写在/etc/containerd/config.toml里，通过plugins."io.containerd.grpc.v1.cri".registry.mirrors配置，改完systemctl restart containerd生效。

Kubernetes从1.24开始默认用containerd作为运行时，所以如果你是在K8s节点上拉镜像慢，改daemon.json是没用的，得改containerd的配置。这一点后面我会给出两套完整配置。

2.3 加速源为什么经常失效

镜像加速节点本质上是公益或半公益的缓存服务，运营方要承担带宽和存储成本。一旦流量过大，要么限速，要么直接关停。所以你会看到很多曾经好用的地址突然就不行了。这也是为什么我不建议你把某一份列表当成长期方案，而是要学会自己验证。

提示：任何镜像加速地址都只是“临时可用”，配置多个源做冗余，比死磕一个源要靠谱得多。

3. 当前可参考的镜像加速源与选择思路

3.1 挑选加速源的三个判断标准

在给出候选列表之前，先说清楚我判断一个源值不值得用的标准，这样即使列表全过期了，你也能自己筛：

响应速度：manifest请求能否在1秒内返回。这个直接决定docker pull的启动快慢。
层下载速度：实际拉一个几百MB的镜像，看平均速度能不能稳定在几MB/s以上。
稳定性：连续拉几个不同镜像，是否会出现某个镜像拉一半失败的情况。

只满足第一条的源，往往是大厂做的限速缓存，manifest快但层下载慢；三条都满足的源，才是真正好用的。

3.2 常见候选源类型说明

目前市面上能见到的加速源大致分几类，我不在这里写死具体域名（因为变化太快），而是告诉你去哪里找当前可用的，以及怎么快速验证：

云厂商提供的公共加速地址：部分云服务商为自家用户提供镜像加速，通常需要在控制台开通后获得专属地址，这类地址稳定性相对较好。
高校和开源社区维护的镜像站：这类站点通常同时提供多种开源资源的镜像，Docker镜像加速是其中一项，可用性波动较大但偶尔速度很好。
企业自建或半公开的缓存节点：这类地址传播范围小，反而可能更稳定，但需要你自己去社区里留意。

我个人的做法是：同时配置3到4个源，Docker会按顺序尝试，第一个不通就自动切下一个。这样即使某个源挂了，也不影响使用。

3.3 配置多个源的写法

在daemon.json里，registry-mirrors是一个数组，可以写多个：

JSON

{

"registry-mirrors": [

"https://源地址1",

"https://源地址2",

"https://源地址3"

]

}

Docker会按数组顺序尝试，遇到不可用的会自动跳过。注意这里不要写重复的源，也不要把明显已经关停的地址留在里面，否则每次拉取都要先等它超时，反而更慢。

4. Linux环境下Docker镜像加速完整配置

4.1 修改daemon.json并重启

这是最标准的dockerd配置流程。先确认你的Docker用的是dockerd：

BASH

docker info | grep -i "runtime"

如果输出里有runc且没有明显的containerd字样，基本就是dockerd链路。然后编辑配置文件：

BASH

sudo mkdir -p /etc/docker

sudo vim /etc/docker/daemon.json

写入内容（把源地址替换成你验证过的）：

JSON

{

"registry-mirrors": [

"https://你的源1",

"https://你的源2"

"max-concurrent-downloads": 10,

"log-driver": "json-file",

"log-opts": {

"max-size": "100m",

"max-file": "3"

}

这里我额外加了max-concurrent-downloads，默认是3，调到10可以明显加快多层镜像的下载。日志配置是为了防止容器日志把磁盘写满，属于顺手做的优化。

保存后重载并重启：

BASH

sudo systemctl daemon-reload

sudo systemctl restart docker

4.2 验证配置是否生效

重启后一定要验证，别配完就不管了：

BASH

docker info

在输出里找到Registry Mirrors这一段，确认你配置的地址都列出来了。如果没列出来，说明配置文件格式有问题，或者Docker根本没读到这个文件。

然后实测拉一个镜像：

BASH

docker pull nginx:alpine

alpine版本体积小，适合快速验证。如果几秒内就拉完了，说明源是通的。如果卡住不动，换下一个源再试。

4.3 参数背后的取舍

max-concurrent-downloads这个值不是越大越好。调到10对大多数场景是合适的，但如果你的带宽本身很小，或者加速源对并发有限制，调太高反而会触发限流。我实测下来，10是一个比较稳的平衡点，再往上收益不明显。

另外registry-mirrors里的地址必须带https://前缀，这是很多人配错的地方。少了前缀Docker会直接忽略这一项，而且不会报错，非常隐蔽。

5. containerd链路的镜像加速配置

5.1 判断你是否需要改containerd

先跑这条命令：

BASH

sudo ctr version

如果能正常输出版本信息，说明系统里装了containerd。再看K8s节点：

BASH

kubectl get nodes -o wide

输出里的CONTAINER-RUNTIME如果是containerd://x.x.x，那你要改的就是containerd配置，改daemon.json完全无效。

5.2 修改config.toml

containerd的配置文件在/etc/containerd/config.toml。如果这个文件不存在，可以先生成一份默认配置：

BASH

containerd config default | sudo tee /etc/containerd/config.toml

然后找到plugins."io.containerd.grpc.v1.cri".registry这一段，配置mirrors：

TOML

[plugins."io.containerd.grpc.v1.cri".registry.mirrors]

[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]

endpoint = ["https://你的源1", "https://你的源2"]

注意这里的docker.io是逻辑registry名，不是真实域名。containerd会把所有指向docker.io的请求转发到你配置的endpoint。

5.3 重启并验证

BASH

sudo systemctl restart containerd

sudo systemctl status containerd

验证时用ctr命令拉镜像：

BASH

sudo ctr images pull docker.io/library/nginx:alpine

如果速度明显提升，说明配置生效。这里有个坑：ctr默认不走K8s的namespace，如果你是在K8s节点上验证，要加上-n k8s.io参数：

BASH

sudo ctr -n k8s.io images pull docker.io/library/nginx:alpine

6. Docker Desktop在Windows和macOS上的配置

6.1 图形界面配置方式

Docker Desktop的配置比Linux简单，直接在设置里改：

打开Docker Desktop，点右上角齿轮图标进入Settings。
左侧选Docker Engine。
在右侧的JSON编辑框里，找到或添加registry-mirrors字段。
点Apply & Restart。

配置内容和Linux的daemon.json完全一致，因为Docker Desktop底层也是dockerd。

6.2 常见启动失败排查

热词里频繁出现virtualisation support wasn't detected这类报错，这跟镜像源没关系，是虚拟化支持没开。Windows上需要在BIOS里开启虚拟化（Intel VT-x或AMD-V），并且确保没有和Hyper-V、WSL2冲突。macOS上一般是系统版本太旧或者安全设置拦截。

还有一种情况是Docker Desktop启动后拉镜像依然慢，这时候检查一下是不是代理设置干扰了。Settings里的Resources→Proxies如果配了代理，可能会让镜像请求绕远路。国内环境下如果加速源本身可用，通常不需要额外配代理。

6.3 WSL2下的注意事项

如果你在Windows上用WSL2跑Docker，配置改的是Docker Desktop那一层，不是WSL2里的Linux发行版。WSL2里如果单独装了Docker，那要按Linux的方式改/etc/docker/daemon.json。两套配置互不影响，别搞混了。

7. 拉取慢、拉取失败的排查流程

7.1 分层排查思路

遇到拉取问题，按这个顺序排查，基本能定位到原因：

现象	可能原因	排查方法
manifest请求就超时	加速源不可用	换源，或直接`curl`测试源地址
层下载到一半失败	源限速或网络抖动	重试，或换源
所有源都慢	本地网络问题	检查DNS、带宽占用
配置改了没效果	改错了链路	确认是dockerd还是containerd
报TLS错误	源地址协议不对	确认用`https://`

7.2 用curl快速测试源可用性

不用每次都拉镜像来测，直接用curl测manifest接口更快：

BASH

curl -I --max-time 5 https://你的源/v2/

返回200或401都说明源是活的（401是正常的鉴权响应）。如果超时或返回5xx，这个源基本可以放弃了。

7.3 清理无效配置

如果配置里留了失效的源，每次拉取都会先等它超时。定期清理：

BASH

docker info | grep -A 10 "Registry Mirrors"

把明显不响应的地址从daemon.json里删掉，重启Docker。

注意：不要盲目往配置里堆十几个源，源越多，逐个尝试的超时累积起来反而更慢。3到4个足够。

8. 几个容易被忽略的实操细节

8.1 镜像名要写全

配了加速源之后，拉镜像时不要省略registry前缀。比如docker pull nginx和docker pull docker.io/library/nginx在加速逻辑上是有区别的。写全名能确保请求正确命中你配置的mirror。

8.2 私有仓库和加速源不冲突

如果你同时用私有registry，加速源只影响docker.io的请求，私有仓库的地址不受影响。但要注意daemon.json里如果配了insecure-registries，和registry-mirrors是两个独立字段，别写混。

8.3 定期更新源列表

我自己的习惯是每个月花五分钟重新验证一遍当前用的源。方法就是上面说的curl测试加实际拉取。发现某个源连续两次测试都不行，就换掉。这样能保证配置长期有效。

8.4 大镜像优先考虑离线导入

对于几个GB的大镜像，比如某些AI模型镜像，与其反复拉取，不如在有网的环境拉好后docker save成tar包，再docker load导入。这在网络条件差的场景下比任何加速源都靠谱。

BASH

docker save -o model.tar 镜像名:tag

docker load -i model.tar

9. 我踩过的几个坑和最终建议

说几个真实踩过的坑。第一个是改完配置忘了重启，改daemon.json后不systemctl restart docker，配置根本不生效，白白折腾半天。第二个是在K8s节点上改错了链路，明明节点用的是containerd，我却在改daemon.json，改完一点效果没有，后来才反应过来。第三个是源地址少写了https://，Docker静默忽略，不报错，特别难发现。

最终我的建议很简单：配置3个经过验证的源，dockerd和containerd两条链路都搞清楚自己用的是哪条，每月验证一次，大镜像走离线导入。做到这几点，国内环境下用Docker的体验会顺畅很多。镜像源列表会一直变，但只要你掌握了验证和配置的方法，就永远不怕它失效。