每隔两三个月就会有人拿着网上流传的 Docker 国内镜像源列表来问我“怎么按着配了还是拉不动”说实话不怪他们这类列表的更新速度永远追不上失效速度。9 月 13 日我把平时收集的加速地址重新过了一遍逐个做了连通性测试顺手整理成这份 2026 年可用版本。文章覆盖 Linux 服务器、Docker DesktopWindows/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 authoritySSL 证书有问题。可能是地址拼错了也可能是源证书过期。直接弃用。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 RestartDocker Desktop 会自动重启后端引擎并让配置生效。注意Docker Desktop 管理的是它自己内部虚拟机的 daemon。有些教程说可以手动改%USERPROFILE%\.docker\daemon.json但实际上这个路径的配置不一定完全生效而且升级 Docker Desktop 后容易被覆盖。最稳妥的方式就是用界面编辑器。4.2 启动失败的三种高频报错在配置镜像源之前很多新手卡在了 Docker Desktop 根本启动不了这一步。结合我遇到的反馈最常见的是下面几个报错第一个是virtualization support not detected或者failed to start because virtualisation support wasnt detected。这是最典型的虚拟化未开启。Docker Desktop 在 Windows 上依赖 WSL2 或 Hyper-V你需要在 BIOS/UEFI 里开启 Intel VT-xIntel或 AMD SVMAMD然后在 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 这些生态的国内镜像源排查底层逻辑其实一模一样。按这个思路来哪怕下半年地址再变一轮你也不会被卡住。