前一阵把主力开发机迁移到新系统Docker 装好后第一件事就是拉mysql:8.0。结果老收藏夹里那几个“国内镜像源地址”接连败下阵来——不是 TLS handshake timeout就是直接 403。去论坛翻了十几个“最新可用 Docker 国内镜像源”的帖子一大半还是好几年前复制粘贴的老清单照着配完照样拉不动。于是这轮赶在 9 月 11 日更新前我把市面上能叫得上名的 Docker 国内镜像源逐个拉了一遍整理出这份 2026 年实测仍可用的加速列表同时把 Linux、Windows、macOS 三种环境下的配置办法、验证命令以及常见的 pull 失败排查链路一并写清楚。如果你是刚装好 Docker 想快速跑起来 mysql / redis / gitlab或者被 Docker Desktop 启动问题折腾得头大这篇应该正好用得着。1. 2026年9月实测仍可用的镜像加速源清单1.1 先泼盆冷水那些“老牌源”为什么一个个倒下在列可用清单之前我建议你先调整一个预期镜像加速源不是一个“申请一次就能用十年”的东西。很多老教程里反复出现的几个地址现在要么连接超时要么返回 403/404。原因无非这么几种服务商停止该公共项目域名进入维护状态原地址迁移到新域名旧地址保留但不再更新源站增加了鉴权策略匿名请求被拒绝外部依赖环境调整公共缓存服务被限制或下线。所以判断一个镜像源还能不能用最有效的办法不是看帖子发布日期而是自己动手探测 实测拉取。这也是我坚持把“验证方法”放在清单前面的原因。1.2 用一条命令先给候选源“体检”在没有配 Docker 之前你可以先对候选镜像源执行连通性探测。Docker registry 的 v2 接口会返回一个固定响应头只要 URL 能通就代表服务基本在线curl -I https://docker.m.daocloud.io/v2/正常响应会带HTTP/1.1 401 Unauthorized或HTTP/2 401。看到 401 别慌registry 要求请求带 token 属于正常机制关键是连接没有被拒绝也不是 TLS 握手超时。再用time观察 DNS 解析和连接耗时time curl -I https://docker.m.daocloud.io/v2/如果real时间动辄超过 5 秒说明该源当前网络链路不乐观基本不具备拉大镜像的能力。1.3 2026年9月实测可用的地址汇总下面这份表格是我这轮逐个验证过的。分为“公共源”和“个人专属源”后者要先登录服务商控制台获取专属地址但稳定性通常更好镜像源性质2026-09 实测状态使用建议https://docker.m.daocloud.ioDaoCloud 公共源可拉取速度中上不想注册账号时的首选公共源https://mirror.ccs.tencentyun.com腾讯云公共源可拉取速度稳定服务器在腾讯云内网时延迟极低https://docker.mirrors.tencent.com腾讯云公共源备用地址可拉取适用于非腾讯云环境的备选https://你的ID.mirror.aliyuncs.com阿里云个人专属源可拉取速度快需要登录容器镜像服务控制台获取专属地址https://docker.mirrors.ustc.edu.cn中科大源状态不稳定不建议作为唯一源可放末尾兜底提示公共源地址随时可能调整使用前最好先按上面 curl 命令自测。表格状态只能代表 2026 年 9 月中旬我这个网络环境的结论不同地区、不同运营商访问同一源体验差异可能很大。个人专属地址的获取方式很简单登录阿里云控制台找到“容器镜像服务”下的“镜像加速器”页面页面会直接给出形如https://一串ID.mirror.aliyuncs.com的地址复制出来填进 daemon.json 即可。2. 镜像加速源的内在逻辑从一条 docker pull 命令说起2.1 docker pull 究竟干了什么很多人配置镜像源只是照着抄出了问题就不知道怎么排查。想搞清楚得先看docker pull ubuntu:latest到底做了几步Docker Engine 解析ubuntu:latest对应的 manifestmanifest 中包含镜像每一层 layer 的 digestEngine 按 digest 逐个下载 layer 数据全部下载完成后做校验、解压、合并生成本地镜像。配置registry-mirrors后Engine 会优先向 mirror 请求这些数据。mirror 里如果没有对应 layer就由 mirror 服务端返回或 Engine 回源 Docker Hub 拉取。不过要注意不同版本 Docker 对 mirror 缺失内容的处理行为并不完全一致有些版本会回源拉有些版本会直接报错manifest unknown。这也是为什么你明明配了镜像源有时还是会在日志里看到它去请求 Docker Hub 的原因之一。用一个生活化的类比镜像加速源像是你家楼下的快递代收点。平时包裹先送到代收点你再走几步去取代收点没有某个包裹快递员要么改派到别处要么直接告诉你这个件签收不了。关键是代收点有的包裹最终内容和官方站点送来的应当完全一致——Docker 每一层都有 digest 校验哪怕从加速源拉取也绕不过这层完整性验证。2.2 多个镜像源的优先级和失败切换registry-mirrors在 daemon.json 里是一个数组Docker Engine 会按照数组顺序依次尝试。第一优先级不可用就会自动尝试下一个。这个设计让“配两个源”变得很有必要一个源挂了另一个还能兜底。但多源也不是灵丹妙药。两个镜像源缓存的内容并不完全一致某一层在 A 源有缓存在 B 源可能没有如果 A 源已经进入半死状态TCP 能连接但传输极慢Engine 不会聪明地立刻切换到 B而是会在超时之后再试。实际感受就是“明明配了三个源pull 还是卡很久”。所以我个人建议主力源放一个备用源放一个到两个最多不超过三个。堆太多没有意义反而会让第一个超时拖垮整体体验。2.3 镜像加速器的边界管不到 ghcr / gcr / quay这是一个高频误区很多人以为配了 Docker 国内源所有仓库都变快。其实registry-mirrors只对 Docker Hub 的镜像生效ghcr.io、gcr.io、quay.io、registry.k8s.io这些外部 Registry 的镜像拉取并不走这个配置。如果你的项目要从这些仓库拉镜像通常做法是提前把所需镜像通过docker pull拉到本地再用docker save导出 tar部署时docker load导入或者使用支持跨地域同步的容器镜像仓库服务把海外仓库的镜像同步到国内仓库后再修改 tag 拉取。这块就不是 registry mirror 能压平的问题了。这也能解释为什么很多教程教你在 daemon.json 里加了镜像源后拉某个特定镜像还是超时——先确认你要拉的那个镜像到底在哪个 Registry别把锅全扣在镜像源头上。3. Linux、Docker Desktop 三种环境下的镜像源配置实操3.1 Linux 上通过 daemon.json 配置Linux 下配置镜像源是最直接的因为 Docker daemon 的配置入口就是/etc/docker/daemon.json。完整步骤如下确认 Docker 在运行docker version创建或编辑/etc/docker/daemon.json写入registry-mirrors数组重启 Dockersystemctl daemon-reload systemctl restart docker验证配置docker info输出中的Registry Mirrors字段。一份直接可用的示例配置{ registry-mirrors: [ https://docker.m.daocloud.io, https://mirror.ccs.tencentyun.com, https://docker.mirrors.tencent.com ] }这里有几个非常关键的坑都是我踩过的daemon.json必须是合法 JSON末尾逗号、注释都不能有。之前见过同事在文件里加了// 注释Docker 直接起不来。改完不重启不会生效docker info不会显示新源。如果 Docker 服务起不来先看日志journalctl -u docker -n 100多半是 JSON 解析错误。3.2 Windows / macOS 上 Docker Desktop 的配置差异Docker Desktop 的图形界面提供了配置入口Settings - Docker Engine。这个界面本质上就是在编辑 Desktop 内置引擎的daemon.json保存后 Desktop 会自动重启引擎。但有一个非常典型的坑如果你在 Windows 上通过 WSL2 里自己安装了 docker-ce比如 Ubuntu 子系统里apt install docker.io那么你改 Docker Desktop 的 Settings 并不会影响 WSL2 里的 docker daemon。WSL2 内的是独立进程要改就改 WSL 内的/etc/docker/daemon.json。判断自己在用哪个 Dockerdocker context ls docker version看看 Client 和 Server 的路径是否指向同一个环境。很多时候拉不到镜像不是源配置错了而是你改的 daemon 和实际用的 daemon 不是同一个。另外相关搜索里经常出现Docker Desktop failed to start because virtualisation support wasnt detected这种报错。这个报错跟镜像源毫无关系根因是 Windows 虚拟化支持没开BIOS 里的 VT-x/AMD-V、Windows 功能里的“虚拟机平台”和 WSL2 都要开启。如果卡在这条优先检查systeminfo | findstr Hyper-V输出里有“已检测到虚拟机监控程序”或类似提示才算正常。这个检查顺序也建议刻进肌肉记忆先确认 Docker Desktop 启动正常再谈镜像源配置。3.3 docker-compose 场景需要额外配置吗不需要。Compose 只是把多个容器的启动参数声明成 YAML拉镜像的操作最终仍然交给 docker daemon 执行daemon 的registry-mirrors配置会被自动复用。也就是说你只要把 daemon 配好docker compose up -d时拉取mysql:8.0、redis:7.2这些镜像自然走加速。不要再单独去给 Compose 找什么“镜像源配置”那是没有的东西。4. docker pull 失败的排查链路从超时到 4034.1 先分清问题类型镜像源配置完成后拉镜像依然可能失败。别急着换源先看报错。我把常见现象整理成一张表你可以按图索骥报错现象大概率原因tls: handshake timeout网络链路到镜像源不通或源已停止服务403 Forbidden/denied源要求鉴权或匿名拉取被拒绝manifest unknown镜像名/tag 错误或镜像源没有缓存该内容且不会回源dial tcp i/o timeout本机到镜像源超时多为防火墙/安全组拦截repository does not exist镜像名拼写错误或该镜像确实在远端不存在卡在Waiting不报错网络二层问题TCP 连接建立后传输极慢4.2 完整的五步排查链路第一步确认 daemon 配置生效。docker info 21 | grep -A 5 Registry Mirrors如果输出为空说明配置根本没加载直接回到第 3 节的步骤重新检查 JSON 和重启操作。第二步测试镜像源连通性。curl -I https://docker.m.daocloud.io/v2/连接超时就是网络层问题401 反而说明服务在线。第三步检查 DNS 解析耗时。time getent hosts docker.m.daocloud.io如果解析耗时超过 1 秒考虑换 DNS 服务商或者直接改用 IP 直连的源。第四步开启 Docker daemon 调试日志观察实际访问的域名和 IP。修改/etc/docker/daemon.json加一行{ debug: true, registry-mirrors: [ https://docker.m.daocloud.io ] }然后重启 Docker用journalctl -u docker -f观察。如果引擎启动后长时间没有请求日志说明问题出在客户端或网络层。第五步用一个小镜像做对照测试。docker pull hello-world docker pull alpine:3.19如果小镜像秒拉完说明源本身没问题换成大镜像卡住往往是网络带宽或源服务端限速而不是配置故障。4.3 一个真实的排查案例有次朋友反馈docker pull mysql:8.0报 403查下来发现他配置的 daemon.json 里第一个镜像源是个人专属地址但地址里的 ID 是从网上抄来的别人的当然 403。换成自己控制台里获取的专属地址后问题解决。这说明一个很容易被忽略的点个人专属地址和公共源的鉴权策略不同不能混用。网上抄来的专属地址里带着别人的 ID拉取时源站识别不了你的身份自然拒绝请求。凡是看到mirror.aliyuncs.com前面跟着一串莫名 ID 的配置都要警惕。5. 镜像源只是起点几个高频业务镜像的落地细节与相关误区5.1 mysql:8.0 与 redis 主从加速只解决第一步镜像源配好后最直观的收益是docker pull mysql:8.0从原来的十几分钟变成几十秒。但要注意镜像拉下来只是起点。举个例子快速跑一个 MySQL 8.0docker run -d \ --name mysql8 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -p 3306:3306 \ -v /data/mysql:/var/lib/mysql \ mysql:8.0镜像源解决的是“镜像能不能快速下载”的问题容器启动后的端口映射、时区、数据持久化、字符集这些配置该踩的坑一个都不会少。再比如 Redis 主从用 compose 声明最方便services: redis-master: image: redis:7.2 container_name: redis-master command: [redis-server, --appendonly, yes] ports: - 6379:6379 redis-slave: image: redis:7.2 container_name: redis-slave command: [redis-server, --slaveof, redis-master, 6379] depends_on: - redis-master这里镜像源帮忙把两个 redis:7.2 镜像快速拉下来但主从是否连通、网络模式是否合适还是要靠容器日志和实际读写去验证。5.2 gitlab 这种“大块头”镜像如何最大化利用加速gitlab/gitlab-ce 镜像动辄几个 GB用公共源和直连 Docker Hub 拉取的时间差距会非常明显。但有几个细节需要特别注意建议先docker pull gitlab/gitlab-ce:latest确认镜像源没有问题再跑容器不要第一次就docker run让它在启动时现拉镜像出问题不好区分是网络还是配置。GitLab 容器本身对内存要求较高至少 4GB 以上否则启动后各种 500。external_url、SSH 端口映射、GITLAB_ROOT_PASSWORD这些核心配置镜像源帮不上任何忙。换句话说镜像源加速解决的是“拿到镜像”这个环节镜像起来之后的运维复杂度是另一回事。5.3 别把“ollama 国内镜像源”和 Docker 镜像源混为一谈相关搜索里“ollama 国内镜像源”热度一直很高这里一定要说清楚Ollama 本身不是通过 Docker Hub 分发模型下载ollama pull llama3下载的模型文件来自模型托管服务。所以即便你的 Docker 镜像源配置满血也不会让ollama pull变快。如果你在 Docker 容器里跑 Ollama镜像源加速只会影响ollama/ollama这个镜像本身的拉取不涉及后续模型文件的下载。同理pip、npm、conda 的加速分别是 pip 镜像、npm 镜像和 conda 镜像跟 Docker registry mirror 也不是一回事。清华、阿里、腾讯都有各自的镜像站需要哪个就去配哪个不要把几套完全不同的加速机制搅在一口锅里。最后说点我个人这些年用下来的体会。镜像源列表这种东西更新得越快、写得越长越容易给人“齐全”的错觉但实际上你只需要挑 1 个主力源 1 个备用源然后固定一个检查节奏每两个月 curl 一遍就够。我现在主力用的是 DaoCloud 公共源腾讯云那个作为备用服务器部署到腾讯云内网时才会换成mirror.ccs.tencentyun.com的内网地址。平时尽量不要往 daemon.json 里堆七八个第三方来源不明的源头镜像缓存是会被供应链攻击盯上的地方配置的源头越少、越可控越安全。如果你按这篇文章配置完还是碰到拉取超时或启动异常最管用的不是到处复制别人的 daemon.json而是先跑一遍docker info和curl -I确认配置真的加载、源真的可达。把这两个动作搞成肌肉记忆大部分问题都能在一分钟内定位。