直接拉 Docker Hub 拉不动拉下来也慢得像是用拨号上网——这大概是国内开发者共同的痛。我平时维护着一份内部镜像源清单每到月底都会把列表重新过一遍把失效的删掉、把新发现的补上。9 月 13 日下午我又花了一个多小时把目前网上流传较广的十几个 Docker 国内镜像源挨个实测了一遍最后把能用的、速度靠谱的整理成了这篇文章。这篇文章适合所有被docker pull卡到怀疑人生的开发者不管你是刚装完 Docker Desktop 的新手还是在 Linux 服务器上维护生产环境的运维照着配置就能省下大量等待时间。除了最新的镜像源列表我还会把配置方法、验证手段以及“配完之后依然拉不动”的排查链路完整讲一遍。很多网上的教程只给地址不给思路结果镜像源一换就全抓瞎这恰恰是写这篇的主要原因。1. 镜像加速源的生命周期理解它为什么容易失效1.1 一条 docker pull 指令背后发生了什么要弄懂镜像源为什么这么难维护得先搞清楚 Docker 拉镜像的完整路径。当你执行docker pull nginx:1.27时Docker 客户端并不会直接连 Docker Hub而是先把请求交给本机 Docker daemondaemon 再去访问 Docker Hub 的 registry 服务把镜像的 manifest元数据和每一层 layer文件系统快照拉下来最后组装成本地镜像。这里和你直连慢的根源在于 Docker Hub 的服务节点大部分部署在海外跨境链路的延迟和丢包率都很高。更麻烦的是Docker Hub 对来自特定地区的访问存在限速大镜像经常拉到一半就断掉。镜像加速源做的事情简单说就是在中间加了一个“代购点”你请求加速源加速源去 Docker Hub 把镜像拉回来再转交给你。很多镜像源还会做一层缓存热门镜像第一次拉取后后续请求直接从缓存返回速度自然快得多。用生活化的例子类比自己直接去 Docker Hub 下载镜像就像跑很远的路去批发市场买菜这条路堵车严重一趟下来又慢又累镜像加速源相当于社区门口的便利店它替你去批发市场进货而且热门商品货架上有存货你出门就能买到。1.2 公共镜像站生存成本远比你想象的高既然加速源这么好用为什么市面上的公共镜像源总是隔一段时间就失效一批很多人以为镜像源只是搭个反向代理其实完全不是。一个能稳定运行的公共镜像源需要持续承担三块成本带宽成本、存储成本、人力巡检成本。带宽成本最现实。镜像站跑的是流量每天有大量开发者通过同一个镜像站拉取镜像一个月下来流量费用相当可观个人维护者很难长期自掏腰包。存储成本则是缓存机制带来的镜像源为了提供加速效果一般会缓存热门镜像的层数据缓存越来越多磁盘和 CDN 费用就跟着涨。还有人力成本镜像源挂了要有人修复上游协议变更了要有人跟进域名被针对了要有人换方案。这三块成本叠加导致大量“用爱发电”的公共镜像站活不过一年。于是你会看到一种很常见的现象某个镜像源今天还能用明天突然连接超时或者今天还能拉 latest 标签明天直接返回manifest unknown。这不是你的 Docker 配置有问题而是镜像源已经停止维护或者为了节省成本关掉了热门镜像之外的同步。1.3 为什么不能照搬网上任何一张“永久可用”列表现在网上的镜像源列表很多但几乎没有哪份能长期保持准确。原因很简单镜像源的可用性是动态的今天验证通过的地址明晚可能就关了。任何声称“永久可用”的列表本质上都是不负责任的。所以在 9 月 13 日更新这篇清单的同时我更想传递一个方法论不要依赖某一张特定列表而是掌握验证镜像源是否可用、如何快速切换的方法。下面给的地址是我当天实测有效的你可以直接抄但更重要的是学会自己验证一旦失效可以立刻从备选池里找回。这也是我长期维护镜像源清单的核心思路始终维护一个优先级明确的候选池而不是只押注某一个地址。2. 2026 年 9 月 13 日实测后的可用镜像池2.1 先看兜底的云厂商个人版加速器公共镜像站再稳定也不如云厂商提供的个人版加速器可靠。云厂商有完整的商业团队在维护镜像源的稳定性和可持续性都有保障。它们的原理是在你自己的云账号下生成一个专属加速器地址Docker daemon 通过这个地址拉取 Docker Hub 上的公共镜像。以阿里云为例登录容器镜像服务控制台在“镜像工具”下的“镜像加速器”页面你会看到一串域名形如https://xxxx.mirror.aliyuncs.com。把它配置进 Docker就能享受阿里云全国节点的加速能力。腾讯云的配置路径类似镜像加速器地址一般是https://mirror.ccs.tencentyun.com这个地址在腾讯云服务器上特别快普通网络环境也能用。华为云也有对应的 SWR 服务提供加速地址。云厂商加速器的优先级我放在公共镜像站之前主要理由是它和你账号绑定不太会出现“全公司突然一起断供”的情况。缺点是个人版通常有流量或并发限制但对于个人开发、中小团队的日常拉取完全够用。如果连这个都觉得慢那就得考虑在公司内网搭私有 registry 镜像了。2.2 社区公共镜像站按我实测的优先级排列公共镜像站适合作为云厂商加速器的补充尤其是当你在多个网络环境之间横跳时多准备几个备选地址能有效避免单点故障。下面是我 9 月 13 日实测后保留的几个镜像站按照我的个人体验按序排列顺序镜像站地址特点备注1https://docker.1ms.run速度较快成功率高当前主力备选适合绝大多数场景2https://docker.m.daocloud.ioDaoCloud 维护品牌老牌历史稳定性不错偶尔需要重试3https://docker.1panel.live1Panel 社区维护对 Docker Compose 用户较友好4https://hub.rat.dev社区维护作为最后备用不建议优先需要注意的是以上地址都有失效可能我这里标注的是 9 月 13 日实测的结果。配置时可以同时把多个地址都写进 daemon.json 的registry-mirrors数组里Docker 在拉取时会按顺序尝试第一个不行就换下一个。把优先级最高的放最前面可以显著降低单点故障的影响。另外很多镜像站还支持直接拉取的形式比如docker pull docker.1ms.run/library/alpine:3.20。这在排查问题时很有用你可以跳过 daemon 配置直接验证某个镜像站是否活着。不过日常使用不建议在镜像名里强行拼接这些地址否则将来切换镜像源时项目中所有镜像引用都要重写。2.3 不要照搬验证脚本与判断标准镜像源列表再全也挡不住它说挂就挂。所以我想了很久决定把验证方法放在跟列表同等重要的位置。你拿到任何一个镜像站地址先花三十秒验证一下再决定要不要配置进去。最简单的连通性检查是请求 registry 的/v2/端点。一个正常的镜像源访问/v2/会返回401 Unauthorized因为没带认证信息连不上则会超时或报错。可以执行下面的命令快速批量测试for m in docker.1ms.run docker.m.daocloud.io docker.1panel.live hub.rat.dev; do code$(curl -skI -m 5 https://$m/v2/ -o /dev/null -w %{http_code}) echo $m - $code done输出里如果看到401说明服务端正常响应看到403、000、timeout等基本可以判断该镜像源当前不可用。注意这里加了-k参数只是为了跳过证书校验来测连通性正常拉取镜像时 Docker 仍然会用系统证书链校验 TLS。当然连通性检查只是第一步最准确的验证永远是实际拉取一个镜像。我的习惯是拉一个体积小、标签稳定的镜像比如 Alpinetime docker pull alpine docker image inspect alpine --format {{json .RepoDigests}}如果镜像确实来自镜像源RepoDigests里会出现类似docker.1ms.run/library/alpinesha256:xxx的记录而不是docker.io/library/alpinesha256:xxx。这一步能确认 daemon 确实走了镜像源而不是凭空以为自己配置成功了。3. 三种环境配置 daemon.json以及重启后的验证3.1 Linux 服务器直接编辑 daemon.jsonLinux 上配置镜像源最标准的方式就是修改/etc/docker/daemon.json。这个文件是 Docker daemon 的核心配置如果之前没创建过直接新建一个。用编辑器打开后写入{ registry-mirrors: [ https://docker.1ms.run, https://docker.m.daocloud.io, https://docker.1panel.live ] }保存后重启 Docker 服务。现代 Linux 发行版大多使用 systemd执行sudo systemctl daemon-reload sudo systemctl restart docker如果是 CentOS 7 等使用旧版 init 的系统可以改用sudo service docker restart。这里有一点要提醒重启 Docker 时候运行中且没有配置restartalways的容器可能会被中断。生产环境建议提前确认容器重启策略或者挑维护窗口再操作。配置完成后用docker info查看 Registry Mirrors 字段是否展示你刚写的地址docker info | grep -A 5 Registry Mirrors如果这里显示为空说明 daemon.json 没有被正确读取。常见原因包括JSON 语法错误、文件权限不对、路径写成了/etc/docker/config.json。改完以后重新执行sudo systemctl daemon-reload再重启一次试试。3.2 Docker DesktopGUI 配置与 JSON 编辑器Windows 和 macOS 上的 Docker Desktop 配置方式稍微不同但整体思路一样。Windows 用户在系统托盘找到 Docker 图标右键进入 Settings左侧选择 Docker Engine这时会看到一个类似文本编辑器的窗口里面就是 daemon 的 JSON 配置。直接把registry-mirrors写进去然后点击右下角的 Apply Restart。macOS 的操作几乎一样只是 Docker Engine 配置页的入口位置略有差异。需要注意一个常见的坑Docker Desktop 同时提供了图形化的 “Registry mirrors” 或代理设置如果你在这里配置了镜像源又在 Docker Engine 的 JSON 里写了一份二者可能互相覆盖。我的建议是只用 JSON 编辑器这一处配置避免两边配置不一致时出现诡异问题。如果你使用的是 WSL2 后端在 Windows 上配置 Docker Desktop 之后WSL2 内部的 Docker 客户端也会自动使用这套配置。但如果你是在 WSL2 里单独安装了 Linux 版 Docker没走 Docker Desktop那就得按上一节的方法修改 Linux 内的/etc/docker/daemon.json两套配置互不相通。很多人在 Windows 下配好了进 WSL 里发现还是拉不动就是因为搞混了这两条配置链路。3.3 生效验证的正确姿势配置完镜像源别急着拉大镜像先做两个小验证。第一确认docker info输出里的 Registry Mirrors 已经是你配置的那几个地址。第二按 2.3 的方法拉一个hello-world或alpine小镜像检查 RepoDigest 是否带上了镜像源域名。有一个细节容易踩坑如果你的本地环境之前已经拉过测试镜像比如本机已经存在hello-world的本地镜像那再次docker pull hello-world会秒完成但它来自本地缓存根本不走网络。测试前记得先docker rmi hello-world确保本地没有存档。速度对比可以这样测time docker pull busybox连续测两次第一次如果走了镜像源缓存会快第二次可能因为缓存没命中或镜像源回源而稍慢多测几次取个中位数。整体来说配置成功后的速度感觉应该是“刷一下就完”而不是长时间卡在 “Waiting” 或 “Retrying”。4. 配好镜像之后容易踩的四个坑4.1 docker-compose 里写死镜像源地址很多教程会告诉你可以直接docker pull docker.1ms.run/library/nginx:1.27-alpine这在排查时没问题但我强烈不建议你在docker-compose.yml或 Dockerfile 里把镜像源地址写死。原因很简单镜像源地址一变你就要全局搜索替换改漏一处就是一个故障。更稳妥的做法是借助 Compose 的环境变量机制把镜像地址的域名部分抽出来。比如在项目根目录放一个.env文件REGISTRYdocker.1ms.run IMAGE_TAG1.27-alpine然后在docker-compose.yml里这样引用services: nginx: image: ${REGISTRY:-docker.io}/library/nginx:${IMAGE_TAG:-latest}切换镜像源的时候只需改.env里的REGISTRY一行不用动 Compose 主文件。这里需要提醒library之前其实还藏着 docker.io 的命名空间逻辑Docker Hub 上的官方镜像其实都存放在library仓库下写成library/nginx才能兼容不同镜像源的路径规划。4.2 镜像加速源只管拉取管不了 Dockerfile 里的下载依赖镜像加速源解决的是 Docker 引擎拉取镜像的加速问题但很多人配置完镜像源发现docker build依然慢得要命。原因在于构建过程中大量时间消耗在RUN pip install、RUN npm install、RUN apt-get install这些指令上它们下载依赖时的默认源依然是官方源跟 Docker 镜像源半毛钱关系没有。我就见过一个项目Docker 镜像源配好了但 Dockerfile 里写的是RUN pip install -r requirements.txt每次构建都从 PyPI 官方源拉依赖慢到怀疑人生。解决方法很简单手动指定国内源RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simplenpm 同理RUN npm install --registryhttps://registry.npmmirror.com对于apt-get可以在构建阶段先替换 sources list或使用带国内镜像源的基础镜像。总而言之把 Docker 镜像源和 Dockerfile 内部的依赖源混为一谈是新手最常见的误解。搜索引擎里搜“npm 国内镜像源”“anaconda 国内镜像源”“huggingface 国内镜像源”的人特别多其实就是这个问题在不同工具链上的体现。4.3 只配一个镜像源遇到故障就全挂有的同事图省事registry-mirrors数组里只写一个地址觉得够用就行。但问题在于镜像源本身也可能抽风特别是社区维护的公共站偶尔会出现连接超时或证书过期。如果列表里只有一个镜像源Docker 只会尝试这一个失败就直接报dial tcp: lookup xxx on ... no such host。registry-mirrors本身支持配置多个地址Docker daemon 拉取时会按顺序尝试。你就把它理解成一个故障转移列表优先级从高到低依次排列。我通常会写三个一个云厂商加速器、两个社区公共站。这样即使一个挂了另一个还能顶上来不会出现“配置了镜像源反而比没配还难用”的情况。4.4 confuse 镜像源域名和 HTTPS 证书镜像源域名必须是 Docker 能正确解析并验证 HTTPS 证书的合法域名。有些教程会让用户在 daemon.json 里填不带https://的裸域名或者用 IP 直连。这在某些环境下可行但一旦镜像源启用了强制 HTTPS 跳转Docker 可能因为协议不匹配报错。我的建议是统一写https://前缀。同时如果某个镜像源出现certificate signed by unknown authority大概率是该镜像源的证书链不完整或者域名被中间设备劫持换成了自签证书。遇到这种问题不要图省事关闭 TLS 验证而是直接把该镜像源从列表里去掉换下一个更靠谱的。有一类特殊镜像源是内网或企业自建的它们有时会使用自签证书这时正确的做法是把证书加到系统信任链而不是让 Docker 跳过校验。任何声称“关闭证书校验就能用”的教程都是在给你的安全埋雷。5. 仍然拉不下来的故障排查链路5.1 排查的第一步确定问题到底出在哪有一次帮一个朋友排查他学了一篇教程配置了镜像源结果docker pull仍然一直报错。他在群里说镜像源不行我让他把错误完整发过来结果是error pulling image configuration: Get https://registry-1.docker.io/v2/...这说明配置压根没生效。排查镜像源的问题第一件事是先分清楚你拉取时到底在请求哪个域名。最简单的办法是执行docker info --format {{json .RegistryConfig.Mirrors}}如果输出是[]或null说明 daemon 根本没有读到配置。这时候不要盯着网络看回去检查 daemon.json 的路径和 JSON 语法。如果输出是你配置的镜像源域名而报错信息里依然出现registry-1.docker.io那要看看报错是不是发生在 manifest 列表阶段这种情况经常是镜像源已经拉到了 manifest但继续拉取 layer 时回源失败。还有一种很容易被忽略的情况环境变量代理。如果你的机器上设置了HTTP_PROXY、HTTPS_PROXY、NO_PROXY而 Docker daemon 的代理配置没有把镜像源域名排除流量就会绕到代理节点上。虽然代理本身不是坏事但代理连接质量差时镜像源请求同样会超时。检查一下 daemon 的代理配置systemctl show docker --propertyEnvironment如果发现代理变量被注入了可以编辑/etc/systemd/system/docker.service.d/http-proxy.conf在NO_PROXY里加上镜像源域名然后 reload 并重启 Docker。5.2 判断镜像源本身是否还活着在不确定是本地问题还是镜像源问题时最有效的办法是绕开 daemon 配置直接对镜像源发请求。上文的/v2/端点测试就是干这个用的另外还可以直接尝试拉取一个带镜像源域名的完整镜像docker pull docker.1ms.run/library/alpine:3.20这条命令不需要 daemon.json 配置如果它能秒拉成功说明镜像源是好的问题出在 daemon 侧的配置或解析如果它也超时或报 manifest 不存在那基本可以断定镜像源当前不可用该换下一个了。这里要特别提醒一个和 Docker Hub 官方源相关的现象当镜像源的缓存过期而它回源去 Docker Hub 拉取时遇到旧版本镜像或不存在的最新标签Docker 会报manifest unknown。这种情况和镜像源挂掉不是一回事它只是暂时没同步到最新。解决办法是等一下重试或者给镜像指定更具体的版本号而不是直接用latest。实际部署中我遇到过不少次latest标签导致的 manifest 问题所以一直建议生产环境把镜像 tag 写死。5.3 Docker Desktop 启动失败的坑这不是镜像源的问题还有一个高频问题必须单独拎出来说Windows 上 Docker Desktop 启动时直接报Docker Desktop failed to start because virtualization support was not detected。这个问题和镜像源没有任何关系纯粹是虚拟化环境没就绪。碰到这个报错按以下顺序排查进 BIOS/UEFI 确认开启了 Intel VT-x 或 AMD-V在 Windows 功能里确认启用了“适用于 Linux 的 Windows 子系统”和“虚拟机平台”如果刚装完 WSL2 内核执行wsl --update更新内核最后重启电脑再试。有些旧型号 CPU 确实不支持嵌套虚拟化直接升级硬件或换用 Linux 服务器可能更省心。很多初学者在配置镜像源时正好赶上 Docker Desktop 启动失败就误以为是配置写错了反复修改 daemon.json 却始终无效。这里给所有刚入门的朋友一个建议任何配置改完后先确认 Docker 服务本身是健康的再判断是否是网络问题。不要在一个错误的路线上反复打转。6. 把“可用镜像源”从一次性列表变成可维护清单6.1 实操经验我是怎么维护这份清单的说了这么多我还是回到这张“9 月 13 日更新”的列表本身。其实单发一份地址列表很容易难的是让这份列表在你手上有持续价值。我现在维护镜像源清单的习惯是每半个月抽 10 分钟跑一遍验证命令把连不上的地址从可用池里摘掉把新发现的公共站加进候选池。云厂商加速器的地址不是永久不变的尤其阿里云账号迁移或重新开通服务后加速器地址可能变化。定期登录控制台确认一遍。不要在团队 wiki 里只放一个镜像地址而是放一个“优先序 验证命令 切换办法”的完整说明。这样即使镜像源失效任何同事都能按文档自助切换不用每次都在群里喊运维。对规模较大的团队建议直接在公司内网部署一个 registry mirror把所有镜像统一代理到内网让开发者直接拉内网地址。这样互联网镜像源再跳票也不影响日常开发。如果你想把验证自动化可以把上面的命令存成一个mirror-check.sh脚本每天用 cron 跑一次发现某个地址连续三次无法返回 401 就自动发送告警。给一个小示例#!/bin/bash MIRRORS(docker.1ms.run docker.m.daocloud.io docker.1panel.live) for m in ${MIRRORS[]}; do code$(curl -skI -m 5 https://$m/v2/ -o /dev/null -w %{http_code}) if [ $code ! 401 ]; then echo $(date %F %T) $m unreachable (HTTP $code) /var/log/mirror_check.log fi done把脚本加入 crontab 每天执行日志积累久了你就能看出不同镜像源在你自己网络环境里的可靠性曲线这时候才真正做到了“心里有数”。6.2 别把镜像源当成一切整体加速策略要比单一技巧重要回到开头那句话镜像源只是一个环节不是万能钥匙。真正让 Docker 变流畅的做法是组合拳合理配置多个镜像源减少对单一源的依赖在 Dockerfile 里针对 pip、npm、apt 单独配置国内源基础镜像尽量挑选体积小的变体比如alpine而不是完整的ubuntu利用 Docker 的 layer 缓存把不常变的依赖层放在 Dockerfile 前面。我还见过有同事为了规避镜像拉取问题把镜像从一个机器docker save导出再传到另一台docker load导入。这个方式在服务器之间迁移镜像时确实高效尤其适合内网隔离环境。但如果是日常开发高频拉取不同的镜像配置好镜像源才是正道save/load 只能作为临时救急手段。另外就像很多人搜索“ollama 国内镜像源”“github 加速”这些关键词时心情复杂一样每个工具链都有自己的加速方式Ollama 模型下载靠的是模型仓库镜像GitHub 代码拉取靠的是 Git 代理或者镜像仓库这些和 Docker 镜像加速完全是两套体系。不要指望在 Docker daemon.json 里配一个地址就能解决模型下载、代码克隆、npm 安装的所有问题每个领域的加速策略需要单独跟进。最后再分享一个我实际踩过多次的体会不要盲目迷信某一份镜像源列表也不要因为一次拉取失败就把某个镜像源一棍子打死。镜像源的表现和你的网络环境、地域、运营商都有关系同一个地址在北方某城市可能很快在南方便民网络里可能就是反复超时。所以最好的做法是手里始终有一个候选池池子里保持三到四个地址定期验证、动态排序。把这份 9 月 13 日实测的列表当作起点搭配我上面给的验证和排查方法你在国内用 Docker 的体验会稳定很多。