Docker镜像拉不动这件事我几乎每年都要在群里帮忙查一遍。2026年这版镜像源加速列表今天9月13日我又重新把市面主流的加速节点全部拉了一遍能用的、时好时坏的、已经彻底失效的都做了标记整理了这份最新可用的Docker国内镜像源加速列表。如果你正被docker pull卡在几KB每秒的进度条上或者刚装完Docker Desktop准备拉个MySQL镜像却一直超时这篇博文可以直接照着抄里面覆盖了配置方法、验证手段和常见报错的排查思路。这篇内容适合三类人看刚接触Docker、准备在自己电脑上安装Docker Desktop的新手公司服务器上已经部署了Docker但每次拉镜像都慢到怀疑人生的运维还包括做国产化平台适配、需要在龙芯等架构上跑容器的同学。你不需要对Docker有多深的理解只要会用命令行的基本操作跟着下面的步骤走就能把加速器配好。我尽量用大白话讲清楚原理也会把那些踩过坑才总结出来的经验直接写在明处。1. 为什么需要镜像加速先搞清楚镜像拉取的真实路径Docker本身的架构并不复杂你执行一条docker pull mysql:8.0客户端会先连接默认的镜像仓库Docker Hub从上面读取镜像的元数据然后按层Layer分包下载最后在本地完成解压和挂载。整个过程里影响速度最大的环节就是“从Docker Hub下载层数据”这一步而这一步偏偏是最不可控的。1.1 拉取镜像慢的根源出在哪里Docker Hub的官方仓库域名是registry-1.docker.io它的CDN节点在世界各地都有分布但默认情况下你并不一定能访问到离自己最近的节点。更麻烦的是国内网络到Docker Hub机房之间的链路经常出现高峰拥塞白天拉一个几百MB的镜像速度掉到几十KB/s是非常正常的而且大镜像中间极易断流一断就得重新排队进度条磨半天还是老样子。这不是你电脑的问题也不是Docker装错了而是镜像分发节点和当前网络环境之间天然存在传输瓶颈。你在家里、公司、云服务器上分别拉一次同一个镜像速度可能完全不同这就是链路差异导致的。理解了这一点你就能明白一个事实与其反复重试等它慢慢拉完不如换一条更近的“取货通道”。1.2 镜像加速器的工作方式本质是“就近缓存”Docker官方其实预留了一个很方便的机制叫做registry-mirrors。你可以在Docker守护进程的配置文件/etc/docker/daemon.json里给registry-1.docker.io指定一个或多个镜像加速地址。配置之后Docker拉镜像时不会直接连Docker Hub而是先去访问你配置好的加速节点让这个节点帮你把镜像层数据转发回来。你可以把加速器理解成一个“社区快递代收点”Docker Hub是品牌总部仓库加速器是在你家楼下租了个中转仓热门镜像在这个中转仓里已经有存货你一拉就能秒取如果某个镜像中转仓里没有它再派人回总部仓库去取取回来之后放到中转仓里供下一个用户使用同时也会发给你一份。这就是为什么同一个镜像第一次拉可能还是比较慢但第二次、第三次再拉就会快很多因为缓存已经命中了。1.3 为什么镜像源列表需要反复更新很多教程给了一个加速器地址就一劳永逸地贴在那里但实际情况是公共镜像加速器的可用性波动非常大。有些加速节点因为服务调整、维护成本、业务改版今天还能用下个月就返回403有些是访问量大了之后主动限制高峰期根本连不上还有的是老教程里的地址早就已经完全失效新手照着配置完之后仍然拉不动最后还把锅甩给Docker。所以你在标题里看到“9月13日更新”这五个字应该是这篇文章里最重要的信息之一。我每次重新打包环境或者帮朋友排查问题都会顺手验证一遍各加速节点的连通性把失效率和回源速度记录下来。这次更新同样如此下面的镜像源清单就是我在9月13日当天实测之后汇总出来的有效期请以你实际测试为准。2. 2026年9月实测的Docker国内镜像加速源清单下面这些地址都是我在这一天实际拉取过测试镜像的按推荐程度和稳定性分了几个梯队。有一点要提前说明公共镜像加速器的可用性都不是永久保证的这只是我某一天的“体检报告”你配置的时候最好多填几个地址Docker会自动按顺序尝试。2.1 稳定优先的公共加速节点阿里云容器镜像服务是目前口碑比较稳的选择只不过它不提供统一地址而是让你登录阿里云控制台在“容器镜像服务”的镜像加速器页面获取一个专属加速域名形如https://xxxx.mirror.aliyuncs.com。这个地址是跟你的账号绑定的虽然个人用户有一定额度限制但对开发环境已经足够了。腾讯云也维护过https://mirror.ccs.tencentyun.com这个公共节点属于经典老牌速度不错但偶尔会有间歇性不可用的情况适合作为备选。中科大的https://docker.mirrors.ustc.edu.cn和网易的https://hub-mirror.c.163.com都是教育网和开源社区里出现频率很高的地址胜在免费、稳定、历史长。百度提供的https://mirror.baidubce.com也在这轮验证中能正常连通。我把它们的当前状态整理在下面镜像加速器地址协议今日验证结果备注阿里云个人专属https://{你的ID}.mirror.aliyuncs.comHTTPS连通正常速度快需登录控制台获取专属地址腾讯云https://mirror.ccs.tencentyun.comHTTPS连通正常速度中等老牌地址偶有波动中科大https://docker.mirrors.ustc.edu.cnHTTPS连通正常速度较好校园网环境下表现更佳网易https://hub-mirror.c.163.comHTTPS连通正常速度中等老牌镜像源目前可用百度https://mirror.baidubce.comHTTPS连通正常速度尚可可以作为备选多填一个2.2 配置前先手动探测一遍加速器可用性有些人配置完之后发现还是拉不动就急着怀疑加速器不行。其实很多时候问题出在加速器地址本身已经失效或者你根本没有把地址写入到正确的配置文件里。在把加速器地址写进配置之前我建议你先用一行命令看看它到底能不能通curl -I https://docker.mirrors.ustc.edu.cn/v2/如果返回200 OK、401 Unauthorized之类的HTTP状态码说明这个地址是活的如果直接Connection timed out或者返回403 Forbidden那这个加速器大概率已经不能用了就别浪费时间写进配置了。这里注意一下返回401不代表失效这只是一个正常的鉴权响应说明服务端还在正常工作只是你没有登录凭证而已。2.3 如何判断一个“加速器”是否真的适合你判断加速器能不能用最快的方式不是看它首页能不能打开而是真的去拉一个Docker镜像用time docker pull感受一下下载速度。我平时会拉一个只有几MB的hello-world镜像做实验如果这个都拉不动那基本可以确定加速器不可用如果这个小镜像能秒拉再换busybox、nginx:alpine这类几十MB的镜像继续测。另外还要提个醒有些加速节点会限制拉取频率、限制镜像大小、或者只允许特定来源IP访问。如果你的环境在机房或公司内网出口IP经常变动很可能会触发一些未知限制这时候不要死磕同一个加速器换一个或者多配置几个地址轮询会靠谱得多。3. 完整配置教程从全新安装Docker到换源一次搞定有了可用的镜像源地址接下来就是配置环节。不同操作系统、不同安装方式配置的入口和细节会有些差异我分别讲清楚。3.1 Linux服务器配置镜像加速只需要改一个JSON文件Linux环境下Docker服务端以守护进程方式运行镜像加速器写在守护进程配置里。首先确保已经装好了Docker以Ubuntu为例可以用官方脚本安装curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh安装完成之后创建或修改/etc/docker/daemon.json{ registry-mirrors: [ https://xxxx.mirror.aliyuncs.com, https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com, https://mirror.ccs.tencentyun.com ] }这里的registry-mirrors是一个数组每一项是一个完整的加速器地址你按需增删即可。改完之后重启Docker服务让配置生效sudo systemctl daemon-reload sudo systemctl restart docker重启之后先验证一下配置有没有被正确读取docker info | grep -A 5 Registry Mirrors如果看到你刚才填写的几个地址说明配置已经生效接下来再去拉镜像就能走加速通道了。3.2 Windows和macOS用Docker Desktop的图形界面配置更省心在Windows或macOS上用Docker Desktop配置方式比Linux简单得多。打开Docker Desktop点击右上角齿轮进入Settings找到“Docker Engine”这一栏你会看到一个JSON配置编辑器把刚才那串registry-mirrors内容覆盖进去点击“Apply Restart”即可。有一个细节值得注意很多人在Windows上卡在启动阶段还没走到配置加速器这一步。比如报错virtualization support not detected这通常意味着BIOS里的虚拟化功能没有开启或者Windows的虚拟机平台/WSL2功能没有启用。这时候你先别急着配镜像源先去“控制面板→程序→启用或关闭Windows功能”勾选“虚拟机平台”和“适用于Linux的Windows子系统”然后重启电脑再打开Docker Desktop。还有一类报错是failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxengine这通常出现在Docker Desktop引擎还没完全启动的时候或者引擎启动后异常退出了。建议打开任务管理器确认Docker Desktop.exe和com.docker.backend进程还在运行等右下角鲸鱼图标变稳定再执行命令行操作。3.3 用Docker Compose部署MySQL和Redis时加速器同样有效很多MySQL 8.0、Redis主从、GitLab、FRP-family项目的部署方案都依赖docker compose你通常会在docker-compose.yml里指定mysql:8.0这样的镜像名。只要加速器配置在守护进程里Compose直接拉取这个镜像时也一样会走加速通道不需要特殊处理。一个常见的误区是写死镜像摘要Digest会导致加速器命中率下降。如果你在docker pull mysqlsha256:...或者Compose里用了带精确摘要的镜像加速器为了确保内容一致必须回源校验缓存作用就会打折扣。日常需求拉取镜像时只写标签Tag不强制指定摘要让加速器能最大程度命中缓存下载速度会明显更快。部署Redis主从或MySQL这类有状态服务时我还建议把volumes里的数据目录映射到宿主机上这样即使镜像源失效导致再次拉取镜像你的数据也不会丢。下面是一个MySQL Redis的环境文件片段供你参考services: mysql: image: mysql:8.0 container_name: mysql8 ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: example volumes: - ./mysql-data:/var/lib/mysql redis: image: redis:7 container_name: redis7 ports: - 6379:6379 command: [redis-server, --appendonly, yes]第一次执行docker compose up -d时你会看到镜像一层层下载加速器有效的环境下整个过程通常能控制在几秒到十几秒之间。4. 镜像加速的使用边界不止Docker相关工具链也都能受益镜像加速的思路本质上是“把需要从外部拉取的资源换成本地或更近的源”这个思路稍作变通几乎可以复制到所有需要联网下载工具的软件上。下面这几个场景是我在实际项目里经常遇到的顺手整理成了一份对照表。4.1 模型、依赖包、系统源换源思路是通用的随着Ollama和HuggingFace这些AI生态工具的使用越来越频繁很多人会发现不光Docker镜像拉得慢模型文件下载起来更让人崩溃。Ollama默认从官方模型库拉取模型HuggingFace的模型权重文件动辄几个GB网络稍微波动就失败。针对这类场景社区和国内机构也建设了对应的镜像站点。以HuggingFace为例你可以在下载前设置环境变量export HF_ENDPOINThttps://hf-mirror.com设置之后huggingface_hub库下载、transformers模型加载都会自动指向镜像地址路径结构保持和原站一致代码基本不用改。Ollama的模型源在社区里也有镜像方案但我一般建议大家直接去官方渠道看当前支持的镜像环境变量因为这类项目更新很快。npm、Python、Anaconda、Flatpak、Ubuntu apt这些工具链的换源思路就更是老生常谈了找到包管理器里的registry配置文件把远程仓库地址替换成国内镜像地址比如npm可以设置registryhttps://registry.npmmirror.comAnaconda可以写到.condarc里。GitHub Release这一类大文件下载社区也有一些镜像站点可以用但这类站点往往比Docker加速器变动更快更不适合长期固定在文档里需要的时候再单独检索一下就好。4.2 龙芯、飞腾等国产化平台的Docker加速注意点如果你在龙芯、飞腾这类国产CPU平台上部署Docker配置加速器的思路跟x86环境完全一样唯一的差别在于镜像架构。由于这些平台的CPU架构通常是loong64、aarch64或者arm64拉取镜像时要确保镜像是为对应架构构建的。你可以用docker pull --platform linux/loong64 your-image:tag或者直接在daemon.json里设定默认平台让Docker自动选择匹配架构的镜像。这个细节要格外注意如果你在一个非x86平台上拉取了x86架构的镜像即使镜像下载成功了启动容器时也会报exec format error看起来像是系统问题实际是架构不匹配。4.3 青龙面板依赖管理与Dify部署的加速经验青龙面板需要频繁安装JavaScript、Python等依赖很多人卡在依赖管理这一步其实Docker镜像本身的拉取往往不是唯一瓶颈。我的经验是先把宿主机上的Docker加速器配好确保启动青龙容器时用的是加速源进入容器内安装依赖如果还是慢就在容器内单独给npm或pip配置国内源不要把代理层和包管理源混为一谈。Dify这类项目解压后通常会在dify-main/docker目录下要求你先复制一份环境变量文件然后执行docker compose up -d。这个部署过程中会拉取PostgreSQL、Redis、Sandbox、API服务等多个镜像如果是直接从默认源拉取整套下来非常折磨人。我的建议是在执行任何命令之前先按照第3节的方法把加速器配好然后再进入docker目录配置环境变量并启动。这样做完整套部署时间可以从半小时压缩到几分钟。5. 常见报错排查与加速器配置的避坑指南再稳定的加速器也会遇到问题尤其是当你的机器上同时存在网络代理、复杂的防火墙规则、或者多个Docker配置文件的时候。这一节我整理了我在实际排查中遇到频率最高的几个问题和对应的处理思路你可以把它当错一张速查表来看。5.1 报错信息、原因与处理办法报错表现常见原因处理方式docker pull长时间无响应或返回EOF加速器失效或网络链路不通用curl -I探测镜像源换一个可用加速器x509: certificate signed by unknown authority自建仓库或非标准证书仓库未被信任在insecure-registries中追加该仓库地址manifest unknown或no matching manifest镜像标签不存在或架构不匹配确认镜像标签使用--platform指定平台permission denied while trying to connect to the Docker daemon socket当前用户不在docker用户组执行sudo usermod -aG docker $USER后重新登录failed to connect to the docker api at npipe://Docker Desktop引擎未启动或已崩溃重启Docker Desktop确认后台进程存在virtualization support not detected系统虚拟化未开启或Windows功能未启用进BIOS开启虚拟化启用虚拟机平台/WSL2这张表里的前三条和Docker配置直接相关后三条则是环境本身的问题需要注意区分。5.2 配置后依然慢用最小化镜像做一次基准测试判断加速器到底有没有生效最快的方法不是拉一个几百MB的大型镜像在那里干等而是先拉一个小镜像测速。比如time docker pull busybox:latest如果这个命令几秒内就完成了说明加速器已经在正常工作如果它都要卡上一两分钟那就是加速器没配上或者你配的那个源实际上已经失效了。测试成功后再拉nginx:alpine、redis:7这种几十MB级别的镜像观察下载速度心里就有底了。另一个重要概念是“首拉”和“二拉”的差别。同一个镜像如果第一次拉取时加速器缓存里没有需要回源到上游仓库拉取速度可能依然不理想但第二次再拉的时候加速器直接从缓存中返回速度会快很多。所以判断加速器好坏不能只看第一次拉取的结果要结合第一次和第二次的表现综合判断。5.3 给镜像源做定期体检一份简单的巡检脚本公共镜像源最大的问题是不稳定所以我会把验证工作做成一个脚本每次换环境前顺手跑一遍。脚本也不复杂就是逐个请求每个加速器的/v2/接口检查HTTP状态码#!/bin/bash mirrors( https://xxxx.mirror.aliyuncs.com https://docker.mirrors.ustc.edu.cn https://hub-mirror.c.163.com https://mirror.ccs.tencentyun.com https://mirror.baidubce.com ) for m in ${mirrors[]}; do code$(curl -s -o /dev/null -w %{http_code} --connect-timeout 5 $m/v2/) if [ $code 200 ] || [ $code 401 ]; then echo [可用] $m (HTTP $code) else echo [失效] $m (HTTP $code) fi done这个脚本放在服务器上定期执行一次就能在镜像源彻底失联之前提前发现把风险控制在拉镜像之前。公司或团队内部如果拉取镜像需求很大我更建议搭一个私有的Harbor或Registry作为中转缓存把常用镜像提前推送到内部仓库里业务环境统一从内部库拉取这样完全不受公共加速器波动影响。最后再分享一个我个人的经验每次配好加速器之后我都会先拉一个hello-world验证链路再拉一个业务镜像验证速度然后把配置文件备份到一个固定的配置管理仓库里。这样不管换电脑、换服务器、还是重装系统都能在五分钟内恢复相同的Docker环境。镜像源列表这个东西最值钱的不是那几个URL而是你验证过、能直接落地的那套流程。希望今天这份9月13日版本的列表能帮你少踩几个坑拉着镜像去忙真正要紧的事。