2026年Docker国内镜像源加速配置实测：可用列表与避坑指南

9月13日早上，我从 Docker Hub 拉一个几十 MB 的工具镜像，画面上“Waiting”转了两分钟之后，直接 connection timeout。这种事遇多了，人也就淡了：Docker 国内镜像源加速配置，在这边就是日常必须做的事，跟装完系统顺手装输入法一个级别。但麻烦的是，网上各种“最新可用 Docker 国内镜像源加速列表”经常互相对不上号，有些地址上个月还能用，这个月就彻底失联。所以我干脆在 9 月 13 日这天把主流的几个源重新测了一遍，淘汰掉失效项，整理出这篇 2026 年时间节点仍然能用的清单，同时把配置步骤、验证方法和容易踩的坑一起讲清楚。不管你是刚装好 Docker 还在纠结拉不动镜像的新手，还是已经被 Docker Desktop 各种报错磨掉耐心的老手，都建议照着手动过一遍。

1. 2026 年了，为什么这个列表还得“更新”

镜像加速这个话题看起来门槛不高，但恰恰因为门槛低，网上信息反而最乱。先把底层逻辑讲透，你后面排查问题会轻松很多。

1.1 加速器到底在做什么：一个“本地代购点”模型

你执行docker pull mysql:8.0时，Docker 客户端会去默认仓库 Docker Hub 拉取镜像。Docker Hub 本身服务没有完全消失，但它的 CDN 对国内网络基本谈不上优化，经常出现连接超时、传输中断、几 MB 的层要下半小时这些情况。镜像加速器的本质，是第三方机构提前把 Docker Hub 的镜像缓存到自己的服务器上，你配置的 registry-mirrors 就是告诉 Docker：别直接去 Docker Hub，先去这些缓存节点取。取不到的时候，节点会替你去 Docker Hub 回源，再返回给你。用生活里的说法就是：Docker Hub 是原厂超市，但离你家太远物流还差，加速器就是在你家楼下开了个便利店，商品从原厂进货后摆在店里给你拿。这个便利店不是每次拉取都重新进货，而是有本地缓存，所以同一台机器第二次拉相同镜像时，速度会非常快。

1.2 为什么每年的“可用列表”都在变

那为什么镜像源列表总在变？核心原因是运营成本。做公共镜像加速是有持续开销的，服务器带宽、存储、维护人力，哪一样都要钱。早期不少高校和公益组织乐于提供公共镜像服务，但流量一旦上来，成本压力极大，加上部分机构的资源调整，一批又一批镜像站开始停止对外开放或转为仅内网使用。Docker 官方也曾提供中国区加速器，但很早就停止服务了。云厂商这边，阿里云、腾讯云都提供容器镜像加速器，但阿里云模式已经变成“登录控制台拿专属地址”，腾讯云的加速器也更适合在自家云内网环境里使用。一句话，纯公共且长期免费的加速服务在这个领域越来越稀缺，所以任何一份“永久可用”的镜像源列表都不现实，你收藏的时候就应该意识到：它是有保质期的。

1.3 两行命令自己测源，比收藏列表更靠谱

与其到处找列表，不如花两分钟自己测。我判断一个加速源能不能用，分两步。第一步看连通性：直接请求它的/v2/接口，Docker Registry API 的入口就是这个路径。用 curl 快速试，返回 200 或 401 都算活着，401 说明它要求身份认证但服务本身在线；超时和连接失败直接淘汰。第二步看实际拉取：docker pull hello-world，这个镜像只有几百 KB，适合做连通性验证，拉通之后再看要不要继续试大镜像。我给你写了个小循环脚本，把候选源填进去，几秒钟就能出结果，批量判定这些列表的成色。

sources=( "https://docker.m.daocloud.io" "http://hub-mirror.c.163.com" "https://yourid.mirror.aliyuncs.com" ) for s in "${sources[@]}"; do code=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 --max-time 10 "$s/v2/") echo "$s -> $code" done

这个脚本里的yourid.mirror.aliyuncs.com需要替换成你自己的专属地址，后面 2.1 节会讲怎么拿。输出结果里 200 和 401 都不用紧张，都是“服务在”的信号；000 就意味着连接失败了。

2. 9月13日实测后仍在服役的镜像源

9 月 13 日我分别在家宽网络和一台国内云服务器上做了测试，测试源包括下面表格里的这些。需要提前说明：本文列的只是截至 9 月 13 日我的实测结果，不是对永久可用性的承诺；你配置前最好自己也 curl 一趟，用上面那个脚本就行。

2.1 个人专属型加速器：稳定，但要去控制台拿地址

个人专属型加速器里最典型的就是阿里云。打开阿里云容器镜像服务控制台，找到镜像加速器页面，就能看到一个专属于你账号的加速地址，格式一般是https://一串ID.mirror.aliyuncs.com。这个地址的好处是：没有公共源那么高的并发压力，稳定性在同类里属于第一梯队。坏处是只有你自己的账号能用，换一台机器就得重新配。腾讯云也有类似的加速器，但如果你不是腾讯云服务器用户，直接在公网用它收益不大，它在腾讯云内网环境下速度才会拉满。所以我的建议是：腾讯云用户用内网加速器，其他用户优先考虑阿里云专属地址或下面的公共源。

2.2 公共加速器：不用账号，开箱即用

公共加速器里，我目前实测比较稳定的是 DaoCloud 的公共加速服务，地址是https://docker.m.daocloud.io，不用注册，直接写进 registry-mirrors 就能用。我用 hello-world 和 mysql:8.0 各测了一次，拉 mysql:8.0 成功，速度可以达到日常可接受的范围。这个源在社区里更新也比较勤，属于“无名但有量”的类型。网易的http://hub-mirror.c.163.com是很多年前就在的老牌源了，至今偶尔还能用，但它是 http 协议，在部分新版 Docker 上可能会出现配置后不生效的兼容问题，这个我放到坑的部分细说。另外百度智能云也提供过一个https://mirror.baidubce.com，我在部分网络下测试通过，但效果不如前两个稳定。整理成一张表方便对照：

阿里云那个地址里的“一串ID”每个人不一样，表里只是格式示意，你需要自己登录控制台拿。

2.3 这些“看起来很全”的源，我建议你慎重

现在网上只要搜“Docker 国内镜像源”，结果一抓一大把。有正经整理的，也有纯粹为了流量从别处复制粘贴的。我见过某些小众加速站在某一天开始，里面所有镜像都变成了来路不明的构建物；也见过声称“永久免费”的源，用了两周就彻底消失。你要区分其实不难：优先选自 2020 年之前就存在、有公开团队或公司背景、有使用文档和反馈入口的源；个人开发者维护的源不是完全不能用，但尽量不要在生产环境依赖它。生产环境如果确实需要稳定加速，更推荐用云厂商提供的专属地址，而不是赌某个公共源的人品。

3. 分平台配置实操：daemon.json、Docker Desktop 与 WSL2

知道哪些源可用，下一步就是把它正确配进 Docker。这部分我按 Linux、Docker Desktop、WSL2 三种常见环境分别讲，每种环境改配置的入口和注意点都不太一样。

3.1 Linux：改一个 JSON，重启 docker 守护进程

Linux 上配置镜像加速的本质是修改 Docker 守护进程的配置文件/etc/docker/daemon.json，加入registry-mirrors字段。路径和字段名不要记错，一个是 daemon 不是 client。没有这个文件就新建，有的话是在原有 JSON 基础上加字段。一个典型配置长这样：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://yourid.mirror.aliyuncs.com" ] }

改完后执行systemctl daemon-reload和systemctl restart docker，随后立即验证docker info。有一点很多人会踩：daemon.json 必须是合法 JSON，多一个逗号、少一对引号，整个 Docker 守护进程都会起不来。如果文件里本来就有>jq '.registry-mirrors = ["https://docker.m.daocloud.io", "https://yourid.mirror.aliyuncs.com"]' /etc/docker/daemon.json > /tmp/daemon.json && mv /tmp/daemon.json /etc/docker/daemon.json

这个命令会把原来的配置原样保留，只替换或新增 registry-mirrors 字段，比手动编辑安全得多。

3.2 Docker Desktop（Windows / macOS）：界面改，别碰底层配置文件

Docker Desktop 在 Windows 和 macOS 上配置思路相同。打开 Docker Desktop，进入 Settings，在 Docker Engine 那个标签页里，你会看到一段可编辑的 JSON。把 registry-mirrors 加进去，保存，点 Apply & Restart。这里要特别提醒：不要自己去改 Docker Desktop 底层文件里的 daemon.json，那是 Docker Desktop 管理的，手动改很容易被应用启动流程覆盖或直接导致启动失败。在设置界面改，Docker Desktop 会在重启守护进程前先校验 JSON，格式有错会直接提示你，不会让环境彻底崩掉。这个设计比 Linux 命令行友好得多。改完照样用docker info验证。另外，如果你在公司环境且配置了系统级网络限制，Docker Desktop 的拉取速度仍然慢，那是网络策略问题，和镜像加速配置无关，不要混淆。

3.3 WSL2 里的独立 Docker：配置在发行版里，不在 Windows 上

很多 Windows 用户用的是 WSL2 里的 Docker，不是 Docker Desktop 内置的。如果在 WSL2 的发行版里通过包管理器直接安装了 Docker Engine，你需要修改的是发行版内的/etc/docker/daemon.json，而不是 Windows 上的文件。常见错误是：在 Windows 资源管理器里找了半天 Docker Desktop 的配置，结果命令行里 docker 指向的其实是 WSL2 里的守护进程，两边根本不是同一个。判断当前 docker 和哪个守护进程通信，用docker context ls和docker context show。搞清了这一点，再按 Linux 的步骤去改才不白费功夫。

4. 配置完别急着拉镜像，先搞懂验证与生效边界

配置完成只是第一步。我见过太多人配完源就以为自己“加速”了，实际上 docker info 里根本没有加载镜像源，或者拉的是非 Docker Hub 的镜像，加速器根本管不到。这一章讲清楚怎么验证、怎么理解生效边界。

4.1 看 docker info 里的 Registry Mirrors 输出

配置完成后，先别急着拉生产环境的大镜像。第一步应该看 registry-mirrors 是否真的被 daemon 加载了。执行：

docker info | grep -A 1 "Registry Mirrors"

如果配置正确，你会看到一列镜像源地址。我在实际运维中见过不少人配置完不验证，隔了半个月发现 docker info 里根本没有 mirror，原因要么是改错了文件，要么是改了文件没重启。这一步 30 秒就能确认，建议每次都做。如果看到的是空列表，先回头检查 daemon.json 的路径、JSON 格式和 Docker 是否真的重启成功。

4.2 别被“第一次拉取慢”误导：回源与缓存

新配置好的源，第一次拉大镜像时速度依然可能一般，尤其是冷门镜像或新发版的镜像，缓存节点还没同步过。此时加速器需要回源去 Docker Hub 拉，本质上是把慢的部分转移到了中转节点。只要本地缓存热起来，第二次再拉同一个 tag 就会快很多。这个特性会让人误判“配置没生效”，不要急，先 docker pull 同一个镜像跑两遍。另外 Docker 的镜像层有本地缓存，你在 A 机器上拉下来的层，换到 B 机器还是得重新走加速器。如果你想测试真实速度，最好用一个从没在这台机器上拉过的 tag。

4.3 registry-mirrors 只对 Docker Hub 生效

这里必须把边界讲透：registry-mirrors 只对 Docker Hub 仓库生效。你配置了加速列表，拉 mysql、redis、nginx 这些来自 Docker Hub 的镜像没问题，但如果你拉的是ghcr.io/org/app、quay.io/org/app这类其他镜像仓库的镜像，Docker 会直接访问对应仓库，镜像加速列表一点忙都帮不上。很多用户问为什么配了加速，拉某个镜像还是失败，十有八九就是镜像源本身不在 Docker Hub。处理办法通常是：看这个项目官方文档有没有提供镜像搬运地址或备用仓库，或者把相应依赖改成从 Docker Hub 发布的基础版本构建。单纯加 registry-mirrors 是解决不了的。

4.4 多个镜像源的顺序怎么排更合理

一个 registry-mirrors 数组里可以写多个地址，Docker 在拉取时会按照配置顺序依次尝试，直到某一次成功。所以排序有讲究：把延迟最低、实测最稳的源放最前面，公共源放在后边作为兜底。比如前三名可以是阿里云专属地址、DaoCloud 公共加速、网易镜像。但注意，如果你只填了一个源，而这个源因为某些原因出现 404 或拒绝连接，Docker 并不会保证立刻切到 Docker Hub 官方，可能直接报错。所以至少配两个源，多一重保险。同一个源在不同网络环境下表现也可能差异很大，家宽里好用的源，上到某云服务器不一定好用，跨网络测试结论要谨慎迁移。

5. 把加速器用进真实场景：常用镜像与编排工具

配置和验证都通了，接下来看它在真实场景里怎么发挥价值。这一章我用几个高频场景演示，尤其贴合开发者和运维者的日常。

5.1 一条龙拉取 MySQL 8.0、Redis、GitLab

镜像加速生效后，最直观的收益就是拉常用镜像不再煎熬。比如 mysql:8.0、redis:7.2、gitlab/gitlab-ce 这些大镜像，在加速源的帮助下，命中缓存时往往能几分钟内完成。命令层面没有任何变化：依然是docker pull mysql:8.0。这里补充一个组合用法：拉取带版本 tag 的镜像时，先用docker manifest inspect mysql:8.0看看镜像对应的架构和体积，确认服务器架构是否匹配，尤其是国内有不少龙芯、ARM 服务器，不要拉完才发现架构不符，白费流量和时间。GitLab 这种几个 GB 的镜像，拉取时盯着进度条很容易焦虑，建议在服务器低峰期操作，配合加速器可以明显降低中途断连的概率。

5.2 Docker Compose 自动继承镜像加速配置

Docker Compose 在拉取镜像时同样走 daemon 的 registry-mirrors 配置，不需要单独设置。比如你写一个 mysql+redis 的最小 compose 文件，docker compose up -d会自动通过加速器拉镜像。下面这个例子我实际用来起过开发环境：

services: mysql: image: mysql:8.0 restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: rootpass volumes: - ./mysql/data:/var/lib/mysql ports: - "3306:3306" redis: image: redis:7.2 restart: unless-stopped command: ["redis-server", "--appendonly", "yes"] ports: - "6379:6379"

这个文件里，mysql 用 8.0 版本，redis 用 7.2，数据目录分别持久化到本地，restart 策略设为 unless-stopped，避免机器重启后容器不自动恢复。建议把 image 字段的 tag 固定明确，不要用 latest，否则镜像更新后重新 pull 到的可能是大版本变更，数据文件格式不兼容的情况很常见。镜像加速配置不会因为你用了 Compose 就失效，它会自动透传到 daemon 层。

5.3 Ollama、ComfyUI 这类体积惊人的 AI 镜像怎么处理

AI 工具镜像这两年特别热，ollama、comfyui 相关镜像体积动不动就是几个 GB 甚至十几个 GB，这类镜像对镜像加速的需求比传统应用更强烈。Ollama 官方镜像都在 Docker Hub 的ollama/ollama下，加速器可以直接帮上忙。ComfyUI 生态很多镜像也在 Docker Hub 或 ghcr.io，这里就分两种情况：Docker Hub 上的可以通过 registry-mirrors 加速，ghcr.io 上的则要走 4.3 节说的那套思路。拉之前我习惯先docker manifest inspect看一眼体积和架构，确认是 CPU 版还是 GPU 版，再决定用哪个 tag。镜像越大，越能体现加速源的价值，但也要有心理准备：某些公共源带宽有限，大体积镜像第一次拉取仍可能需要耐心等待，别盯着进度条焦虑。

6. 配置镜像加速后最容易踩的 5 个坑

最后这部分是我最想让你认真看的。配置镜像加速本身不难，难的是出现问题后能快速定位。以下 5 个坑基本覆盖了我会员群里高频出现的问题。

6.1 抄了文章里的地址，结果 Docker 起不来

这个坑最经典，没有之一。我见过太多人从一篇标题写着“最新”的文章里复制地址，配完一重启 Docker 直接起不来，或者起来后拉镜像还是原速。原因无他，文章本身过时或地址本来就是错的。所以任何地址都要先通过 1.3 节的 curl 脚本验证，再写进 daemon.json。如果 Docker 已经起不来了，先不要慌，按后面 6.5 的方法恢复到能用的状态，再逐个源测试。

6.2 混淆“镜像加速”和“换个仓库前缀”

很多教程把docker pull docker.m.daocloud.io/library/mysql:8.0这种“给 image 加前缀”的方法也归入镜像加速，但它和配置 registry-mirrors 是两回事。前者相当于你换了一个镜像仓库去拉，image 字段不再指向 Docker Hub 原始地址；后者则是不改 image 字段，只复制拉取流量。对 Docker Compose 和现有脚本来说，registry-mirrors 方案侵入更小、迁移成本更低。如果你在 Dockerfile 里写FROM mysql:8.0，也不希望构建时每个基础镜像都改成带仓库前缀的写法。所以正常情况优先用 daemon 级别的加速配置，而不是去改镜像名。

6.3 Docker context 指错了守护进程，改配置改了个寂寞

Windows 用户尤其容易中招。装了 Docker Desktop 之后，如果你又在 WSL2 发行版里装了一套 Docker Engine，或者用包管理器装了 docker CLI，命令行里的 docker 命令可能连的是 WSL2 里那个 daemon，而不是 Docker Desktop 的 daemon。你打开 Docker Desktop 界面把镜像加速填得再漂亮，命令行 pull 的时候走的是另一套配置，当然没效果。排查方式很简单：docker context show看当前上下文；docker info里也可以看到 Server 的版本和路径。明确当前在跟哪个 daemon 对话，再去改对应的配置文件。

6.4 http 加速源被 Docker 静默忽略

http 协议的加速源在部分 Docker 版本里会被当作不安全连接处理，表现就是你在 registry-mirrors 里写了http://hub-mirror.c.163.com，但docker info里不显示，或者拉取时报证书错误。处理方法有两种：一是换 https 源，这也是我最建议的，少折腾；二是如果就是要用 http 源，可以在 daemon.json 里同时加insecure-registries字段，把域名放进去，但这样等于告诉 daemon 信任这个没有加密的仓库地址，中间链路的网络环境你没法控制，安全性上要自己权衡。个人场景图省事可以理解，生产环境一律不建议用 http 源。

6.5 daemon.json 故障时的二分法排查

如果 daemon.json 改坏了，症状通常很明确：systemctl restart docker之后，服务一直处于 activating 或 failed 状态。排查链路是：先看journalctl -u docker -n 50，里面会直接告诉你 JSON 解析失败或者哪一行格式有问题；如果日志信息不够，把 daemon.json 用python -m json.tool跑一遍，看语法错误位置。最省事的恢复方法是把 daemon.json 临时改名移走，确认 Docker 能正常起来，再把配置一条条加回去，每加一条重启一次。这个二分法在排查任何 Docker 启动故障时都通用，别嫌麻烦，比猜来猜去快得多。

镜像加速这件事，我的心态已经放平了，它和证书过期、依赖淘汰一样，属于需要定期维护的日常操作。现在我自己的习惯是：每季度找个周末，把常用的两三个源用 curl 脚本过一遍，更新完之后在配置文件附近标注测试日期；新机器装好 Docker 的第一件事，也是先把 registry-mirrors 填好，再开始拉任何镜像。这份列表你 9 月 13 日从这儿拿去就能用，但我更希望你带走的是那套自己检测、自己判断的方法，毕竟网上的“最新可用地址”不会停更，真正能让你不踩坑的，还是对原理和验证手段的掌握。祝拉镜像顺利。