每隔两三个月，就会有人拿着网上流传的 Docker 国内镜像源列表来问我：“怎么按着配了还是拉不动？”说实话不怪他们，这类列表的更新速度永远追不上失效速度。9 月 13 日我把平时收集的加速地址重新过了一遍，逐个做了连通性测试，顺手整理成这份 2026 年可用版本。文章覆盖 Linux 服务器、Docker Desktop（Windows/macOS）两种最常见的使用方式，也把配置后如何验证、遇到典型报错怎么判断这类问题一并写了。刚装好 Docker 的新手可以照抄配置，运维老手也能拿这篇当一份自查清单用。
1. 先弄明白失效逻辑：镜像加速器是什么，怎么快速判断它死没死
1.1 镜像加速器的基本原理
很多人配好了镜像源，但不知道它在 Docker 里到底怎么工作的。简单说，Docker daemon 支持一个叫 registry mirror 的机制：你在/etc/docker/daemon.json里配置了registry-mirrors之后，执行docker pull时 daemon 会优先访问你配置的镜像加速地址，如果这个节点上已经有对应镜像的缓存，就直接返回给你；如果没有，它再回源到 Docker Hub 拉取并缓存下来。
所以镜像加速器的本质是一个缓存节点，它解决的是“拉取路径远、下载速度慢”的问题，而不是“镜像不存在”的问题。你配置多个镜像源也不会让单个镜像块下载得更快，它只是给了 daemon 多个备选缓存服务器。理解了这一点，你就明白为什么镜像源列表总在变——缓存服务是有成本的，运营方一旦调整服务策略、切换域名、限制访问范围，地址就失效了。
1.2 为什么镜像源列表总在失效
我整理失效原因，不是为了分析行业，而是为了让你以后少踩坑。
- 运营方调整策略：有些公共服务原本免费开放，后来因为流量成本太高，开始限流、要求注册，甚至直接关停。
- 域名频繁变更：一些社区维护的第三方节点为了规避滥用，隔几个月就换一次域名。
- 高校源限制访问范围：很多高校镜像站目前只允许教育网或校内用户访问，公网用户能看到页面，实际拉取却失败。
- 限流和封禁滥用：大量用户并发拉取时，节点会返回 403 或 429，这种情况不代表节点死了，只代表它暂时忙不过来。
结论是：镜像源没有“永久可用”这一说。与其到处找“最新列表”，不如掌握一套探活方法，自己动手确认一个源是不是真的能用。
1.3 探活：一条 curl 命令判断源是否存活
Docker Registry 服务有一个诊断端点，访问它的/v2/路径，返回 401 或 200 就说明 HTTP 服务本身是活的。401 表示“需要认证”，这恰好说明服务在工作；200 表示公开可访问。如果返回 403、404 或者连接超时，这个源大概率已经有问题了。
我自己最常用的探活命令是这样的：
for m in docker.m.daocloud.io hub-mirror.c.163.com docker.mirrors.ustc.edu.cn; do code=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 --max-time 8 "https://$m/v2/") echo "$m -> $code" done输出里docker.m.daocloud.io -> 401说明源活着；hub-mirror.c.163.com -> 000说明连不上或者超时。
但探活不等于完全验证。有些镜像源虽然/v2/能访问，实际拉取镜像时因为缓存策略或限流规则依然会失败。所以探活之后，你还需要真正执行一次docker pull拉取一个小镜像（比如alpine:latest）做最终确认。
1.4 拉取报错里的几个关键代码
docker pull失败时报错信息五花八门，但大部分可以归成这几类：
dial tcp ... i/o timeout：网络层不通，源不可达或者被限速。换源，别死磕。connection refused：源服务没有在监听，大概率已经停止服务。x509: certificate signed by unknown authority：SSL 证书有问题。可能是地址拼错了，也可能是源证书过期。直接弃用。403 Forbidden或429 Too Many Requests：访问被拒绝，通常是限流或访问策略调整。错峰再试，或者换源。no matching manifest for linux/xxx in the manifest list entries：镜像源里没有对应 CPU 架构的镜像。这个不是源的网络问题，而是架构匹配问题，后面讲龙芯平台时会细说。
2. 9月13日核对过的镜像源清单：按可靠程度分四档
2.1 第一档：云厂商个人专属加速器
云厂商提供的容器镜像加速器，是我见过生命周期最长、最值得长期持有的源。它不会轻易消失，因为背后是企业级基础设施。
- 阿里云加速器：登录阿里云控制台，搜索“容器镜像服务”，在左侧“镜像加速器”页面可以看到你的专属加速地址，格式是
https://<你的专属ID>.mirror.aliyuncs.com。需要注册账号，有个人免费额度。 - 腾讯云加速器：地址是
https://mirror.ccs.tencentyun.com。腾讯云服务器内网环境通常直连很快，外网机器不一定快，需要实测。 - 其他云厂商：华为云、百度云等都有类似服务，逻辑一样，去控制台里找“容器镜像服务”或“镜像加速器”即可。
注意一点：这类地址里的 ID 是你自己账号专属的。网上有人贴出“阿里云公共加速地址”，那是别人的 ID，你用不了也不该用。
2.2 第二档：免注册公共加速源
如果不方便注册云厂商账号，或者只是想在开发机上临时用一下，DaoCloud 提供的公共加速地址是首选：https://docker.m.daocloud.io。
这个服务存活时间很长，免注册、免配置，直接填进registry-mirrors就能用。我自己的开发机一直保留这个源作为兜底。
但这类公共服务有一个共同缺点：用户量一旦暴涨，限流会很严重。所以它适合做备源，不适合做唯一源。
2.3 第三档：高校源和社区节点
高校镜像站里，中科大的 Docker 源（https://docker.mirrors.ustc.edu.cn）是知名度最高的，但它的可用性跟你的网络环境强相关。教育网环境下表现很好，公网环境时好时坏。另外像网易的https://hub-mirror.c.163.com，历史上用过的人很多，现在可用性波动较大，需要实测。
社区维护的第三方节点，包括一些 Docker 管理面板项目提供的公共加速地址，特点是域名经常变，能用的时候速度不错，但随时可能失效。用这些节点前一定要先探活，并且不建议在生产环境里把它们当成唯一依赖。
安全提醒：不要配置来历不明的 HTTP 地址。正规加速服务都会提供 HTTPS，配置 HTTP 地址会让 Docker 拒绝，或者触发证书警告。
2.4 怎么组合：我实际使用的几种源搭配方案
| 使用场景 | 推荐组合 | 说明 |
|---|---|---|
| 个人开发机 | DaoCloud 公共源 + 阿里云专属源 | 免注册兜底 + 稳定主力 |
| 生产服务器 | 云厂商同区域加速器 + DaoCloud 备源 | 线路就近优先，备源防故障 |
| 临时救急 | 任意一个探活通过的源 | 先保证能拉镜像 |
实际踩坑经验：不要配置一大堆源在系统里。Docker 虽然会按顺序尝试，但如果第一个源超时失败，它会在当前源上重试很长时间，而不是立刻切换下一个。所以配置 2 到 3 个高质量源就够了，定期清理掉死源比堆数量更重要。
3. Linux 服务器配置实录：daemon.json 的修改、重启与验证
3.1 改配置前的备份和 JSON 格式要求
Linux 下 Docker 的 daemon 配置统一放在/etc/docker/daemon.json。不管你是用官方脚本安装的 Docker，还是用 apt、yum 装的 docker-ce，这个路径都一样。
修改前一定要备份：
sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak.$(date +%Y%m%d%H%M%S)daemon.json是严格 JSON 格式，有两点最容易出错：
- JSON 里不允许有注释。有人习惯在配置后面加
# 这是注释，这会导致整个配置文件解析失败。 - 最后一个数组元素后面不能有逗号。写
"https://xxx",和"https://xxx"],这类尾逗号也是经典报错源。
另外注意引号必须用英文半角，不要用中文全角引号。我帮人排查过几次，问题都出在全角引号上。
3.2 daemon.json 完整配置与重启生效
一个完整的配置示例长这样：
{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://<你的专属ID>.mirror.aliyuncs.com" ] }保存之后，执行：
sudo systemctl daemon-reload sudo systemctl restart docker为什么必须先daemon-reload再restart docker？因为 systemd 需要重新加载 Docker 服务的 unit 文件。虽然大多数情况下直接restart docker也能生效，但如果你改过 systemd 环境变量或者 Docker 版本较老，顺序不对会有概率导致重启后配置未生效。
3.3 生效验证和拉取测速
重启之后，先确认配置真的进去了：
docker info --format '{{json .RegistryMirrors}}'或者用更传统的方式：
docker info | grep -A 5 "Registry Mirrors"如果列表为空，说明配置没生效，回头检查 JSON 格式和文件路径。
然后真正拉一个小镜像测速：
time docker pull alpine:latest第一次拉取会稍慢，因为 daemon 需要建立与镜像源的连接并缓存元数据。第二次拉取如果镜像已经在本地，就不会走网络了，所以测速要看“第一次拉取”的结果。
如果你配置了多个镜像源，拉取日志里出现类似trying next mirror的关键词，说明第一个源失败了，daemon 正在尝试下一个。这个关键词出现得越频繁，说明你配置列表里的“死源”越多。
3.4 配置后仍然报错的排查顺序
我收到过最多的求助是“我配了源，为什么还是失败”。按下面顺序排查，90% 能找到问题：
- 报错
permission denied while trying to connect to the Docker daemon socket：这不是镜像源问题，是当前用户没有 Docker 权限。执行sudo usermod -aG docker $USER后重新登录一次。 - 报错
i/o timeout：换源。你已经配的源在当前网络下不可达，换一个探活通过的源就好。 - 报错
no matching manifest for linux/xxx：架构不匹配。如果你用的是 ARM 设备或国产 CPU 设备，而镜像源只缓存了 x86 架构的镜像，就会出现这种情况。尝试把源切换成官方 Docker Hub，或者确认镜像本身支持你的架构。 - 大镜像拉取到一半失败：先看磁盘空间。执行
docker system df看看 Disk Usage 是不是满了。空间不足时 Docker 拉取到一半就会中断，而且报错往往显示为网络超时。清理悬空镜像用docker image prune -f。
3.5 龙芯等国产平台和 Docker 升级场景补充
最近几年国产 CPU 机器用 Docker 的越来越多，尤其是龙芯平台的 LoongArch 架构。daemon.json 的配置方式跟 x86 平台完全一样，但有一个坑：很多公共镜像加速源里缓存的镜像是 x86_64 或 arm64 的，没有 loong64 架构的 manifest。这时候拉取会报no matching manifest，跟镜像源地址本身是不是“通”没有关系。
遇到这种情况，先确认镜像官方是否支持龙芯架构，再考虑从源码构建，或者直接走官方源拉取。不要浪费时间换几个加速源反复试，问题不在源上。
CentOS 7 升级 Docker 的场景也补充一句：从旧版 Docker 升级到 docker-ce 后，daemon.json 路径不变，配置一般也不会丢，但旧配置里的某些字段（比如过时的 storage-driver 配置）可能不兼容新版本。如果升级后 Docker 起不来，先检查/etc/docker/下有没有残留的旧配置文件，再看看 systemd 服务状态和错误日志，别急着重装系统。
4. Docker Desktop：图形化配置和启动报错的自查顺序
4.1 Docker Engine 面板里的 JSON 编辑入口
Windows 和 macOS 上的 Docker Desktop 用户，不需要手动去改/etc/docker/daemon.json。图形界面上直接有入口：打开 Docker Desktop，进入 Settings，左侧选择 Docker Engine，右侧就是一个 JSON 编辑器。
在这里填入：
{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://<你的专属ID>.mirror.aliyuncs.com" ] }点击 Apply & Restart，Docker Desktop 会自动重启后端引擎并让配置生效。
注意：Docker Desktop 管理的是它自己内部虚拟机的 daemon。有些教程说可以手动改%USERPROFILE%\.docker\daemon.json，但实际上这个路径的配置不一定完全生效，而且升级 Docker Desktop 后容易被覆盖。最稳妥的方式就是用界面编辑器。
4.2 启动失败的三种高频报错
在配置镜像源之前，很多新手卡在了 Docker Desktop 根本启动不了这一步。结合我遇到的反馈，最常见的是下面几个报错：
第一个是virtualization support not detected或者failed to start because virtualisation support wasn't detected。这是最典型的虚拟化未开启。Docker Desktop 在 Windows 上依赖 WSL2 或 Hyper-V，你需要在 BIOS/UEFI 里开启 Intel VT-x（Intel）或 AMD SVM（AMD），然后在 Windows 功能里启用“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。开启后需要重启电脑。PowerShell 里执行systeminfo，拉到靠近底部的位置，可以看到虚拟化状态。
第二个是failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxengine这类连接错误。这个报错说明 Docker Desktop 的后端引擎没有成功启动。常见原因包括 WSL2 内核版本过旧、Docker Desktop 与安全软件冲突、磁盘空间不足。处理顺序建议是从轻到重：先重启 Docker Desktop；不行就执行wsl --update更新 WSL，再wsl --shutdown后重新打开 Docker Desktop；再不行重启电脑；最后才考虑重装 Docker Desktop。
第三个是启动成功，但docker info里看不到Registry Mirrors配置。这种情况通常是 Apply & Restart 没走完，或者 JSON 保存失败。重新打开 Settings 里的 Docker Engine 面板确认保存状态。
4.3 配置生效后依然拉得慢的排查方向
如果你确定镜像源配置已经生效，但拉取依然慢，问题就不在配置本身了。
- Docker Desktop 底层运行在一个轻量虚拟机上，DNS 解析在虚拟机内部进行。如果你遇到反复超时，先把镜像源地址确认无误，再检查 Windows 系统网络是否正常。
- 安全软件（杀毒软件、防火墙）有时会拦截 Docker Desktop 虚拟网卡的流量，导致拉取连接时断时续。临时关闭安全软件测试一下，能快速定位是不是它的锅。
- 电脑休眠或者频繁切换网络后，Docker Desktop 后端网络的连接状态可能没有恢复。这种情况重启 Docker Desktop 通常能解决。
5. 镜像源解决不了的事：三类联动问题与批量探活
5.1 内网镜像分发：自建 registry 或 docker save/load
镜像源只解决“从公网拉取慢”的问题。如果你有几台服务器都在同一内网，更高效的方案是内网镜像分发。
最简单的方式，用官方registry:2镜像起一个私有仓库：
docker run -d -p 5000:5000 --name registry registry:2然后在一台能正常访问外网的机器上，把镜像拉下来再推送到内网仓库：
docker pull mysql:8.0 docker tag mysql:8.0 内网IP:5000/mysql:8.0 docker push 内网IP:5000/mysql:8.0其他机器拉取时直接指定内网地址：docker pull 内网IP:5000/mysql:8.0。这样不依赖公网镜像源，也不依赖加速器。
离线环境下的docker save和docker load同理，适合一次性搬运镜像到无外网机器。注意docker save导出的是压缩归档包，使用docker load导入后镜像标签会保留。
5.2 Compose 和全家桶项目的分步拉取
docker compose pull走的也是 daemon 的镜像源配置，所以你配好registry-mirrors之后，Compose 项目不需要单独配置镜像源。
但全家桶类项目（比如 Dify、青龙面板这种多容器项目）镜像数量多、体积大，经常出现“拉了一半失败”的情况。我的习惯是：只要有一个镜像失败，就先单独补拉这一个：
docker compose pull <service名>比整个项目重新up -d更省时间。
这里有个很多人踩过的坑：Dify 部署文档里写着，在dify-main的 docker 目录下执行cp .env.example .env，但 Windows 的 CMD 里没有cp命令。Windows 用户如果报“cp 不是内部或外部命令”，直接打开资源管理器，把.env.example复制一份改成.env，效果一样。
另外，青龙面板这类项目如果容器能正常拉取、但容器内部依赖装不上，问题往往不在 Docker 镜像源，而在容器内使用的 apk、npm、pip 源。很多人把这两件事混在一起排查，浪费了大量时间。先确认镜像本身能拉下来，再进容器看依赖源。
5.3 批量探活脚本：两周一跑，源挂不慌
最后分享一个我一直在用的批量探活脚本。把你想验证的源地址放在一个文件里，跑一遍循环，每个源的状态一目了然。
#!/bin/bash sources=( "https://docker.m.daocloud.io" "https://<你的专属ID>.mirror.aliyuncs.com" "https://hub-mirror.c.163.com" "https://docker.mirrors.ustc.edu.cn" ) for s in "${sources[@]}"; do code=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 --max-time 8 "$s/v2/") echo "$s -> $code" done把脚本保存为check-mirrors.sh，执行bash check-mirrors.sh。返回 401 或 200 的源基本健康；返回 000 或 403 的源，可以考虑从配置里摘掉了。
镜像源这东西，最大的坑不是配置难，而是列表过时了你不知道。我自己每隔一两周就跑一遍探活脚本，哪个源掉了直接摘掉，绝不恋战。同时把云厂商控制台里的专属加速器当作压舱石，公共服务做备用，社区节点只当临时手段。这套思路不止适用于 Docker，像 npm、Anaconda、Hugging Face 这些生态的国内镜像源排查，底层逻辑其实一模一样。按这个思路来，哪怕下半年地址再变一轮，你也不会被卡住。
