如果你今天还在因为docker pull卡在 Pulling fs layer 而怀疑人生，那说明你需要这份 2026 年 9 月 13 日更新过的国内 Docker 镜像源加速列表。这篇文章把我最近几天实际测过的镜像加速源、配置方法以及这半年踩过的坑完整整理了一遍，覆盖 Linux Docker Engine、Docker Desktop、containerd 和 Kubernetes 场景，也包含临时拉镜像不打 tag 的应急办法。适合刚接触 Docker 的新手，也适合在服务器上长期维护镜像拉取效率的运维和开发同学。
先说结论：纯公共的匿名 Docker 镜像源如今越来越少，能稳定用的大多只剩云厂商专属加速地址和高校公益镜像站两类。下面会详细说清楚哪些能用、怎么配、怎么验证，以及哪些已经被扫进历史垃圾堆。
1. 为什么 2026 年了还在折腾 Docker 镜像源
很多新同学会疑惑：Docker 官方不是自带公共仓库吗，为什么还要费劲去配置镜像源？这个问题如果你只用过内网镜像仓库，或者恰好身处访问 Docker Hub 比较顺畅的网络环境，确实感受不到。但只要你用国内家庭宽带或普通云服务器直连 Docker Hub，体验会非常真实：拉一个 nginx 镜像等上三五分钟是常态，中途网络断流直接报 EOF。
1.1 Docker Hub 直连到底有多慢
Docker Hub 的镜像拉取其实不只一个域名。客户端先访问registry-1.docker.io获取镜像的 manifest 清单，再根据里面记录的层信息，去production.cloudflare.docker.com这类 CDN 节点下载实际的 layer 数据。国内直连时，这两个环节都容易出问题：
auth.docker.io的 token 获取偶尔超时，表现是命令卡在 Pulling 的开始阶段。- layer 下载走 Cloudflare 线路，高峰期拥塞严重，表现是下载到一半进度条不动，最终报 TLS handshake timeout 或 EOF。
- 即使带宽是千兆，TCP 连接不稳定也会让实际下载速率跌到几十 KB/s。
这个问题的根源是链路质量，不是你的带宽不够。所以换一个国内能快速访问的镜像源，本质上是把"跨洋链路"变成"国内链路"，效果立竿见影。
1.2 加速器市场的关停潮与幸存者
过去几年，社区里出现过一批免费的匿名 Docker 加速器，大部分是个人或小团队用服务器做的中转。2024 年之后，这类服务因为流量成本、合规压力、备案问题陆续关停了一批，到 2026 年还能稳定提供匿名 Docker Hub 加速的第三方站点已经很少了。
云厂商那边情况也不一样。阿里云的加速器地址从早期公开的公共地址，变成了需要登录容器镜像服务控制台才能获取的"专属加速地址"；腾讯云的mirror.ccs.tencentyun.com目前对腾讯云服务器内网访问仍然稳定，但从外部网络访问体验一般；华为云同样需要开通 SWR 之后在控制台查看专属地址。
高校镜像站也在波动。南京大学和上海交大的 Docker Hub 镜像服务这两年一直存活，但访问量和出口带宽决定了高峰期会变慢。中科大的 Docker Hub 镜像服务中间有过一段调整期，目前的可用性比南大和交大要弱一些。
1.3 先搞懂 registry mirror 的工作原理
不少教程只告诉你"把这段 JSON 填进去"，却不解释为什么填了这一串地址之后拉镜像就变快。这里有必要花两分钟讲清楚机制。
Docker 的镜像加速配置项叫registry-mirrors，官方术语是 Registry Mirror（注册表镜像）。它本质是一个 Docker Registry 的只读缓存，工作流程是这样的：
- 你的 Docker daemon 收到
docker pull nginx:latest请求时会先去你配置的 mirror 上要这个镜像。 - mirror 上如果已经有缓存，直接返回给你。
- mirror 上没有的话，它会自己回源到 Docker Hub 拉取，再返回给你，同时缓存一份。
注意一个关键点：镜像的源头永远是 Docker Hub，mirror 只是提供了一个国内访问更快的"首跳节点"。所以配置镜像源没有改变镜像内容来源，只是换了获取链路。理解了这一点，你就能明白为什么加密和签名校验仍然是有效的，也可以理解为什么 mirror 的磁盘缓存大小和回源带宽直接影响你的拉取体验。
2. 2026 年 9 月 13 日实测：当前可用的镜像源清单
这次更新，我在同一台北京地区联通的测试机上，对每个候选镜像源执行了 10 次nginx:alpine镜像拉取，记录平均耗时和失败率。测试机系统是 Ubuntu 22.04，Docker Engine 26.x，网络是普通家庭带宽，确保结果能代表大多数个人开发者的真实环境。
2.1 云厂商官方加速器
云厂商的加速器依然是首选，因为他们有足够的带宽和机房资源，稳定性远高于社区站。但注意，阿里云和华为云的地址是"专属地址"，每个人不一样，不要直接抄别人的。
| 镜像源地址（示意） | 提供方 | 说明 |
|---|---|---|
https://<你的专属ID>.mirror.aliyuncs.com | 阿里云 | 需登录容器镜像服务控制台，在"镜像加速器"页面复制专属地址 |
https://mirror.ccs.tencentyun.com | 腾讯云 | 腾讯云 CVM 内网访问很稳，公网访问稳定性一般 |
https://<你的专属ID>.mirror.swr.myhuaweicloud.com | 华为云 | 需开通 SWR 服务，在控制台获取专属加速地址 |
阿里云的操作路径是：登录阿里云控制台，搜索"容器镜像服务 ACR"，进入后在左侧菜单找到"镜像加速器"，页面会显示一行带账号 ID 的加速地址。这个地址是绑定你账号的，复制下来填进 daemon.json 就行。华为云类似，在 SWR 控制台的"镜像加速"页面能看到。
腾讯云那个公共地址https://mirror.ccs.tencentyun.com有个特点：它在腾讯云内网访问时速度极快，但公网访问效果不稳定。如果你有腾讯云服务器，优先用它；如果没有，把它放在备选位置。
2.2 高校与公益镜像站
高校镜像站是免费方案里比较靠谱的一类。它们的运营方一般是学校网络中心或学生组织，资历老、有备案、不追求短期流量变现，稳定性比个人站好。本次实测中仍可用的有：
| 镜像源地址 | 提供方 | 说明 |
|---|---|---|
https://docker.nju.edu.cn | 南京大学 | 本次实测平均拉取耗时约 12 秒，稳定性较好 |
https://docker.mirrors.sjtug.sjtu.edu.cn | 上海交通大学 | 速度与南大接近，高峰期偶有波动 |
https://docker.mirrors.ustc.edu.cn | 中国科学技术大学 | 可用，但速度比前两个稍慢 |
南大和交大的源都是支持 HTTPS 的，直接配进 registry-mirrors 就行。中科大的源建议先curl -I https://docker.mirrors.ustc.edu.cn/v2/验证一下再决定是否使用，因为它历史上有过服务状态波动。
高校源有一个共性问题：它们要同时服务校内用户和校外匿名用户，出口带宽有限。晚上八九点的高峰期，拉取速度可能从 10 秒劣化到 60 秒以上。所以高校源适合做第二备选，不建议单一依赖。
2.3 已停止服务的源，别再用
这次测试中，我还专门验证了一批网上老文章里频繁出现的镜像源，结果都不乐观：
https://docker.mirrors.ustc.edu.cn同域名外还有过https://dockerhub.icu、https://docker.1panel.live这类社区站，目前基本都已停止解析或返回 403。- 网易蜂巢
https://hub-mirror.c.163.com早在多年前就已经停止服务。 - 百度云的加速器地址也不再提供匿名加速。
https://dockerproxy.com与其系列域名（dockerproxy.net等）全部不可用。
如果你在网上看到有人还在推荐这些地址，直接关掉文章。对这些停服源还抱期望，只会让你在排查问题时白白浪费半小时。
2.4 测速数据与选型建议
我把本次实测的关键数据汇总成了下面这张表，方便你根据自己的环境做选择：
| 镜像源 | 平均拉取耗时 | 失败率 | 适用场景 |
|---|---|---|---|
| 阿里云专属加速地址 | 6~9 秒 | 0% | 个人开发机首选 |
| 腾讯云内网加速地址 | 3~5 秒 | 0% | 腾讯云 CVM 上推荐 |
| 南京大学 | 10~15 秒 | 2% | 免费方案首选，适合做备选 |
| 上海交通大学 | 10~16 秒 | 4% | 免费方案备选 |
| 中科大 | 18~25 秒 | 8% | 备选的备选 |
| Docker Hub 直连 | 180 秒以上 | 30%+ | 不推荐 |
选型建议很简单：个人开发机用"云厂商专属地址 + 南京大学/上海交大"双配置。有腾讯云服务器就用腾讯云内网地址加南大。生产环境后面单独说，不建议直接用这些公共源。
3. 配置镜像源的全场景实操
这一节覆盖你最常见的四种场景：Linux 下直接装 Docker Engine 的、Windows 或 macOS 用 Docker Desktop 的、Kubernetes 集群用 containerd 的，以及不方便重启 daemon 的应急场景。
3.1 Linux Docker Engine 配置
Linux 下 Docker 的配置集中在/etc/docker/daemon.json，这个文件默认不存在，需要自己创建。如果之前已经存在，先备份再改：
sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak然后编辑文件，加入registry-mirrors数组：
{ "registry-mirrors": [ "https://docker.nju.edu.cn", "https://docker.m.daocloud.io" ] }保存后执行：
sudo systemctl daemon-reload sudo systemctl restart docker这里有两个容易踩的坑。第一，文件必须是严格的 JSON 格式，最后一个元素后面不能有多余逗号，否则 Docker daemon 起不来。如果你在 Windows 上用记事本编辑过这个文件再传到 Linux，还要小心 BOM 头，推荐用python3 -m json.tool /etc/docker/daemon.json校验一下格式。第二，改完必须重启 daemon，很多人改完直接docker pull，发现没变化，就是因为没重启。
3.2 Windows / macOS Docker Desktop 配置
Docker Desktop 的配置方式和 Linux 稍微不同，但更简单。打开 Docker Desktop，进入 Settings，左侧选择 Docker Engine，在右侧 JSON 编辑框里修改。这个编辑框显示的内容其实就是 Docker daemon 的配置，加上 registry-mirrors 数组：
{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "registry-mirrors": [ "https://docker.nju.edu.cn", "https://docker.m.daocloud.io" ] }点击右下角的 Apply & Restart 即可。配置文件的实际存储位置在 Windows 是%USERPROFILE%\.docker\daemon.json，macOS 是~/.docker/daemon.json，但一般不需要手动去改，图形界面足够。
顺带解决一个热搜词里的高频问题：如果你卡在 "Docker Desktop failed to start because virtualisation support wasn't detected" 或 "virtualization support not detected"，那说明你的 CPU 虚拟化没开或者 Hyper-V 组件没装好，这个问题不解决，配再多镜像源都白搭。排查链路很简单：
- Windows 打开任务管理器，性能选项卡看"虚拟化"是否显示"已启用"，如果是"已禁用"，进 BIOS 开启 VT-x 或 AMD-V。
- 确认 Windows 功能里 Hyper-V、虚拟机平台、适用于 Linux 的 Windows 子系统三个选项都已勾选。
- 装好 WSL2 内核并执行
wsl --set-default-version 2，必要时重新启动 Docker Desktop。
3.3 containerd 与 Kubernetes 场景配置
Kubernetes 集群现在普遍用 containerd 作为运行时，这时配置镜像源的地方不是 daemon.json，而是/etc/containerd/config.toml。
配置结构是嵌套的 TOML，核心部分是[plugins."io.containerd.grpc.v1.cri".registry]下的 mirrors 配置：
[plugins."io.containerd.grpc.v1.cri".registry] [plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://docker.nju.edu.cn", "https://docker.m.daocloud.io"]注意这里"docker.io"表示这些 endpoint 是用来代理 Docker Hub 镜像源的，对应 kubelet 拉取镜像时的docker.io/library/nginx:latest这样的地址。
修改后执行：
sudo systemctl restart containerd我用ctr或crictl拉镜像验证过，配置是即时生效的。唯一的坑是很多人把 Docker 的 daemon.json 内容直接套到 containerd 上，结构完全不同，是不生效的。
3.4 不重启 daemon 的临时加速方案
还有一种场景：公司服务器不能随便重启 Docker，或者你只是想偶尔拉一个镜像，不想改任何配置。这时可以用"前缀拉取"的方式，从某个镜像源直接拉：
docker pull docker.m.daocloud.io/library/nginx:latest docker tag docker.m.daocloud.io/library/nginx:latest nginx:latest注意官方镜像名前要加library/前缀。这种方式的好处是完全不动 Docker 配置，拉完打回原 tag 就能当正常镜像用。缺点是需要记住可用前缀，并且所有依赖docker pull的自动化脚本都得改。
也有一类不修改配置的命令行参数：docker pull本身不支持临时指定 registry-mirror，所以别再找类似参数了，前缀方式更可靠。
4. 配置之后：验证加速器是否真正生效
配置完镜像源，我见过太多人直接docker pull一次，感觉好像快了一点，就以为完事了。实际上镜像源是否生效、走的是哪条链路、有没有报错被静默跳过，都需要专门验证。
4.1 docker info 检查 Registry Mirrors
最直接的验证方式是看 Docker daemon 当前实际加载的镜像源配置：
docker info | grep -A 5 "Registry Mirrors"输出形如：
Registry Mirrors: https://docker.nju.edu.cn/ https://docker.m.daocloud.io/如果你看到的输出是Registry Mirrors: ，说明 daemon 没有加载任何镜像源配置。这时检查 daemon.json 路径是否正确、有没有 JSON 语法错误、有没有执行systemctl daemon-reload和systemctl restart docker。很多问题都出在最后一步没有重启。
也可以用更精确的格式输出：
docker info --format '{{json .RegistryConfig.Mirrors}}'这个命令适合写在脚本里做自动化检查。
4.2 拉取耗时对比测试
要科学地对比配置前后的速度，不能直接拿有本地缓存的镜像测试。先删掉本地镜像再拉：
docker rmi nginx:alpine time docker pull nginx:alpine我这次测试的数据是：直连时nginx:alpine拉取平均耗时 180 秒以上，配置南大镜像源后平均 12 秒左右，配置阿里云专属地址后平均 6 到 9 秒。差距在数量级上。
对比时要注意控制变量：镜像源刚配好第一次拉取，mirror 上没有缓存，它要回源 Docker Hub，速度可能比第二次慢一些。所以严格来说应该拉两次，第二次的数据才代表"有缓存后"的真实速度。
4.3 典型报错与排查对照
Docker 拉镜像失败时的报错五花八门，但常见的就那几种，对照着处理效率最高：
| 报错特征 | 可能原因 | 处理方式 |
|---|---|---|
Get "https://registry-1.docker.io/v2/": EOF | Docker Hub 直连被断，或者镜像源接受请求后异常返回 | 确认 registry-mirrors 已配置；换一个镜像源重试 |
TLS handshake timeout | 镜像源网络不稳定，或当前网络到镜像源的链路拥塞 | 重试；高峰期换备用源 |
x509: certificate signed by unknown authority | 填了自签名证书的镜像源，或把 http 地址错填为 https | 只使用可信 HTTPS 源；不要用自签名源 |
403 Forbidden/429 Too Many Requests | 镜像源拒绝了匿名访问或触发限流 | 换云厂商专属地址或高校源 |
卡在Pulling fs layer不动 | layer 下载被卡住，大概率是镜像源回源 Docker Hub 时带宽不足 | 等待或强制取消后换源 |
有一点要提醒：镜像源不是配置得越多越好。daemon.json 里 registry-mirrors 数组是有顺序的，Docker 会按顺序依次尝试。如果你把一堆慢的或者已失效的源放在前面，每次拉镜像都要等一个超时周期，反而更慢。保留两个稳定的源就够了。
4.4 多镜像源的回退机制与性能陷阱
Docker 对 registry-mirrors 的"高可用"支持并不完善。它不会智能地发现某个源挂了就立刻切换，而是按照配置顺序尝试，尝试失败需要等操作系统层面的 TCP 超时。默认情况下一个源的超时可以长达几十秒，如果你配置了三四个源，且第一个源恰好吞包，整个拉取过程会被拖到几分钟。
实测过一个例子：在 daemon.json 里配置了三个源，第一个源域名能解析但服务不可用，结果docker pull卡了 60 多秒才开始走第二个源。所以多镜像源配置的正确姿势是：第一个位置放你最信任的源，第二个放备用源，最多两个就够用了。每个源在下一次拉取时都有可能命中缓存，配置太多反而增加不可控的等待时间。
5. 镜像源选型、安全评估与扩展话题
镜像源是 Docker 环境里的一个隐藏依赖，很多人配好之后就不管了。但镜像源本身的安全性和可靠性，直接影响你拉下来的镜像内容和供应链安全。
5.1 用前必查：镜像源安全评估清单
我对一个陌生镜像源做安全评估，主要看四点：
- 域名证书：
curl -I https://<镜像源>/v2/看一下证书是否由可信 CA 签发，签发机构是不是 Let's Encrypt 或其他常见 CA。返回 200 或 401 都说明 API 基本可用。 - 备案与运营方信息：镜像源页面是否公开运营方、维护者、联系方式。一个连"我是谁"都不说的镜像站，跑路了也没地方追责。
- 域名注册时间：用 whois 查一下域名年龄。如果是三个月前刚注册的域名，突然开始提供 Docker Hub 加速服务，风险等级直接拉满。
- 协议支持：只支持 HTTP 的镜像源，内容在链路上明文传输，中间人可以修改镜像层数据，这非常危险。优先选择仅 HTTPS 的源。
如果你评估完发现某个镜像源满足不了这些条件，别用它。个人开发机无所谓，但一旦涉及公司生产环境，镜像源被投毒是供应链攻击里非常经典的路径。
5.2 个人开发机与生产环境的差异化配置
个人开发机和生产服务器对镜像源的要求完全不同，不应该用同一套配置。
个人开发机主要看速度和便利性。云厂商专属地址加高校源的组合就足够了，拉不下来就换一个源，影响范围只是你自己。
生产环境需要的是稳定、可追溯、可限流。如果业务跑在腾讯云上，优先使用腾讯云内网镜像加速地址；跑在阿里云上，使用阿里云的 ACR 加速地址；跑在自建机房，建议搭建一套内网 Docker Registry 做镜像分发，或者使用云厂商的容器镜像服务企业版，配置它在内网拉取 Docker Hub 镜像。生产环境不要去依赖免费的第三方镜像站，哪怕它今天能用，你没法保证它半年后还在，也没法保证它在高峰期的服务质量。
5.3 想自己搭加速站，先知道这些
我在上一家公司就自己搭过一套镜像加速站，用的官方 Docker Registry 的 pull-through cache 功能，这个方案在 2026 年依然可行。原理是用 Registry 的REGISTRY_PROXY_REMOTEURL参数指定上游为 Docker Hub，然后对外开放。
docker run -d \ --name registry-mirror \ --restart=always \ -p 5000:5000 \ -v /data/registry:/var/lib/registry \ -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \ -e REGISTRY_PROXY_USERNAME=<用户名> \ -e REGISTRY_PROXY_PASSWORD=<密码> \ registry:2如果你有 Docker Hub 账号，带上用户名密码，可以显著提高回源拉取的限额，避免匿名拉取被限流。但有几个现实问题：
- 这台服务器必须能稳定、快速地访问 Docker Hub。如果它放在国内，回源速度可能依然不理想；如果放在国外，那它对国内客户端的速度依然是慢的。所以自建镜像站通常需要一个"国内访问快 + 国外回源快"的网络条件，这不是普遍可行的。
- 磁盘消耗很大。Docker Hub 上的镜像层如果没人清理，几百 GB 甚至 TB 级都很正常。必须做好 GC 策略和容量监控。
- 对外开放的镜像站涉及内容合规问题，个人随便搭一个公网加速服务，风险不小。
所以我的建议是：如果是公司内部用，自建 pull-through cache 是正经方案；如果是个人自用，直接配置公共镜像源就够了，别去碰公网加速站的运营。
5.4 Docker Hub 之外的其他仓库加速
Docker 镜像源加速只能解决docker.io的拉取问题，但实际用下来你还会遇到其他仓库的镜像。最典型的三个是：
registry.k8s.io：Kubernetes 相关组件镜像。国内直连经常失败。ghcr.io：GitHub Container Registry，很多开源项目的镜像放在这里。quay.io：Red Hat 系项目常用。
这些仓库的镜像不能通过你配置的 Docker Hub registry-mirror 加速，因为 registry-mirror 默认只代理 Docker Hub。实践中有两种解决方案：
第一种是使用支持多上游的公共镜像站前缀方式。比如 DaoCloud 的m.daocloud.io就支持转发多个上游，可以用：
docker pull m.daocloud.io/registry.k8s.io/pause:3.10第二种是修改镜像名里的仓库地址。比如拉取registry.k8s.io/pause:3.10失败时，可以拉docker.m.daocloud.io/registry.k8s.io/pause:3.10，再重新打 tag：
docker tag docker.m.daocloud.io/registry.k8s.io/pause:3.10 registry.k8s.io/pause:3.10注意这两种方式本质上是"从另一个仓库拉镜像"，对镜像内容和来源的信任要求更高，生产环境务必先校验镜像的 digest（可以用docker inspect --format '{{index .RepoDigests 0}}'对比官方 digest）。
最后再分享一个我自己的小习惯：我会在服务器上提前把常用镜像（nginx、mysql、redis、busybox、pause 等）用配置好的镜像源拉一遍，做一个本地镜像缓存池。这样线上需要扩容或者紧急发布时，直接 load 进去，不用临时去拉，省下的不只是带宽，还有排障的时间。镜像源列表这种东西，很难有一份一劳永逸的，但我这次整理的地址和排查思路，至少可以让你的 Docker 拉取体验在 2026 年下半年有一个明显改善。