Docker国内镜像源：2026年9月实测成活名单与配置全记录

如果你手里的Docker一到 docker pull 就进入“静止”状态，进度条以字节为进度，卡在 “Pulling fs layer” 半小时不动，先别急着甩锅给运营商。八成是镜像源没配，或者配置文件里写了一个早就凉透的地址。这篇文章没有任何虚的，就是我在2026年9月中旬用三台不同位置的机器逐一测出来的国内镜像源成活名单、三种主流环境下的配置写法，以及配完镜像源之后依然会遇到的那些坑。

适合谁看？刚装好 Docker 但拉镜像慢到怀疑人生的新手，被各种“你抄我的我抄他的”镜像源教程坑过的老手，还有要在内网多台机器上批量配置镜像源、又怕配置出问题的运维同学。读完你至少能搞清楚三件事：哪些镜像源现在还能用、正确配置姿势是什么、以及配好之后如果还慢该往哪个方向查。

1. 镜像源到底在解决什么问题：先把拉镜像的链路拆开看

很多人以为 Docker 拉镜像慢是带宽不够，其实国内大部分场景根本不是带宽问题，而是Docker默认的镜像仓库 Docker Hub 的服务器在海外，国内直连的链路质量极不稳定。你可以把 Docker Hub 想象成一个建在国外的巨型货仓，你的机器每次运行 docker pull 都要跑到这个货仓去取货。路径上任何一个环节抖动，取货就变慢甚至直接超时。

镜像源（registry mirror）干的事情，通俗讲就是在国内放了一个同款货仓的分仓。你配置好镜像源之后，Docker 拉镜像时不会先跑海外，而是先去你指定的国内分仓找。分仓里有缓存就直接给你，没有缓存它再去海外货仓取回来给你。这个过程对你完全透明，命令还是 docker pull，但实际数据路径从“跨洋”变成了“就近”。

这套机制的关键点在于：镜像源本质上是 Docker Registry 的缓存加速器，Docker 的本机守护进程会在拉取 docker.io 官方镜像 时，依次尝试你配置的 registry-mirrors 列表。注意“依次尝试”这四个字，后面排查问题时会专门展开。

还有个容易被忽略的边界：镜像源只对 docker.io 官方仓库下的镜像生效。如果你拉的是阿里云镜像仓库、腾讯云容器镜像服务、GitHub Container Registry 或者公司私有仓库的镜像，那是另一条链路，和镜像源没有半毛钱关系。很多新手把 docker pull mysql:8.0 加速成功后，再去拉一个 docker pull ghcr.io/xxx/yyy 失败，就以为镜像源失效了，其实是理解错了生效范围。

搞清楚这个原理，你就能明白另一件重要的事：不同时间段、不同地区、不同网络运营商，测出来的镜像源可用性差异可能非常大。 因为每个镜像源服务商自己的出口带宽、机房位置、缓存命中率都不一样，南方的机子用着快的源，放到北方的机房可能就慢得离谱。这也是为什么市面上那些“长期有效镜像源大全”基本都活不过半年，因为镜像源的状态是动态的，不是一劳永逸的。

2. 2026年9月实测：我自己逐台机器跑出来的镜像源成活名单

先说清楚我的测试环境，免得结论被无脑套用。我这边两台国内云主机（一个华北地域、一个华东地域，均为CentOS系），一台家里宽带下的 Windows 机器跑 Docker Desktop。测试方法是写了一个脚本，每个源连续拉取 hello-world、alpine:3.20、nginx:1.28、mysql:8.0 四个镜像，每个镜像重复三次，记录总耗时、失败次数、报错信息。测试时间是2026年9月中旬。

2.1 表现稳定、优先推荐的源

阿里云容器镜像服务个人加速器是我这次实测下来最稳的，没有之一。三台机器上所有测试镜像全部拉取成功，耗时稳定在一到三秒之间（自动缓存了前面跑过的层）。但它不是公开的通用地址，需要你在阿里云容器镜像服务控制台开通之后，拿到一个属于你自己账号的专属加速地址。网上流传的那些“阿里云公共加速地址”基本都已经失效了，因为阿里云很早就把加速器跟个人账号绑定，每人的地址后段是一串随机字符。配置时一定去控制台复制自己的地址，不要抄别人的。

网易数帆加速器（hub-mirror.c.163.com）这次表现也不错。三台机器上拉取 alpine:3.20 和 nginx:1.28 都成功，速度比不配置时快了一个数量级。拉大镜像 mysql:8.0 时华东机器偶发一次中断，重试之后就好了，属于可以接受的范围。网易这个源不需要注册，配置成本低，适合作为第二个备用源。

腾讯云镜像源（mirror.ccs.tencentyun.com）在我华北机器的腾讯云内网环境下表现极好，基本秒拉。但在我家里那台 Windows 的