平时自己折腾 Docker最烦的就是docker pull卡在进度条上半天不动。更烦的是网上一搜镜像源翻出来一堆 2022、2023 年的老帖子照着填进去直接给你报timeout。镜像加速这个事技术本身不复杂真正麻烦的是时效性很多列表今天能用明天可能就 404而官方文档又不会告诉你“现在到底该填哪个地址”。所以 2026 年 9 月这个时候我干脆把目前还活着的国内 Docker 镜像源加速列表重新理了一遍同时也把手动的验证方法、配置技巧和排错经验一起写出来。这篇文章不是只给你一串地址我会把“为什么慢”“怎么配”“怎么确认生效”“失效了怎么办”全部覆盖到适合正在配 Linux 服务器、Windows 上的 Docker Desktop或者 NAS 里跑容量的朋友当成一份可收藏的操作参考。1. 先把原理说清楚镜像源到底加速了什么1.1 Docker pull 为什么慢镜像加速器在其中做了什么要理解镜像加速器有没有用得先知道一次docker pull到底发生了什么。Docker 客户端会先访问远程 Registry默认是 Docker Hub拿到镜像的 manifest 文件里面描述了镜像由哪些 layer 组成、每一层的 digest 和大小。然后客户端会按顺序把每一层都下载到本地解压、校验、合并最终变成可运行的容器镜像。这个过程最耗时的就是下载阶段。一个稍微完整点的镜像动辄几百 MB底层基础镜像往往还带有几十个 layer。Docker 客户端是分层并发拉的但每一层都需要和 Docker Hub 的存储节点建立连接。国内访问这些海外节点延迟高、丢包多是常态经常是某个 layer 卡住整个拉取就晾在那里。镜像加速器在中间扮演的角色我习惯把它理解成一个“离你更近的缓存分发点”。它本身也是一个 Docker Registry只是它会提前把 Docker Hub 上的热门镜像同步到自己机房里。你把它配到registry-mirrors之后Docker 客户端拉镜像时会优先请求这个加速器地址相当于把原来的跨海长途改成了本地高速传输速度自然就上来了。注意registry-mirrors只对 Docker Hub 官方仓库里的镜像生效。你如果配置的是其他独立镜像仓库比如某些第三方 registry或者企业内部自建的仓库这个加速配置不会起作用。这也是很多新手踩坑的地方明明配置了加速器但docker pull走私有仓库或别的 registry 时速度依旧感人。那不是你的配置不对而是加速器根本不在那条链路上。1.2 为什么镜像源的生命周期越来越短说句实在话在国内运营一个公共 Docker 镜像源是一件纯成本的事情。镜像仓库需要存海量数据热门镜像的 layer 动辄几 GB 甚至几十 GB回源带宽成本也不低。公共源面对的又是所有开发者高并发流量一来带宽账单非常好看。再加上偶尔有人拿加速器干一些不该干的事给运维带来各种麻烦愿意长期免费维护的机构越来越少。所以你会发现一个规律网上流传的镜像源列表很多都是两三年没更新过的。里面有些源早就关停有些源改成需要登录认证还有些直接只对特定网络环境开放。如果你照着一张旧列表去配置踩坑几乎是必然的。这也是我写这篇文章时特别想强调的任何一份列表都代表“截至发布时点可用”不代表“永远可用”。所以我会在后面的章节里把验证一个镜像源是否可用的具体方法一起给你。授人以鱼还得授人以渔。2. 2026 年 9 月实测当前主流国内 Docker 镜像源加速列表2.1 目前还能用的镜像源汇总表以下是我在 2026 年 9 月写这篇文章时逐个验证过、在当前网络环境下还能连通的主流镜像加速源。先说明一下这里列出的都是运营时间比较长、相对靠谱的源那种今天建站明天跑路的小众个人源我不建议在生产环境用所以没有收进表格。镜像源名称加速地址协议特点与备注阿里云加速器https://你的专属ID.mirror.aliyuncs.comHTTPS需要登录阿里云容器镜像服务控制台在“镜像加速器”页面获取专属地址个人使用相当稳定腾讯云加速器https://mirror.ccs.tencentyun.comHTTPS腾讯云内部网络体验好外部网络有时会被限流需要现场验证华为云加速器https://docker.mirrors.huaweicloud.comHTTPS整体稳定性不错是当前我比较推荐优先尝试的源之一网易加速器http://hub-mirror.c.163.comHTTP只支持 HTTP新版 Docker 默认会拒绝不太建议直接用百度加速器https://mirror.baidubce.comHTTPS可用性波动比较大适合当一个备用源DaoCloud 加速器https://docker.m.daocloud.ioHTTPS社区维护的老牌源镜像量比较大速度看地区中科大镜像站https://docker.mirrors.ustc.edu.cnHTTPS高校源背景历史上多次暂停过 Docker 相关服务使用前建议先验证看到这张表你应该明白一个事实没有哪个源是“永远的神”。同一时间可能上海用户访问华为云很快北京用户却发现中科大更稳这都是跟网络链路有关的。所以最稳妥的做法不是只配一个源而是选两三个不同运营商背景的源放在配置里做一个多备份。2.2 哪些地方的“镜像源”不能直接填进 Docker热搜里经常能看到“清华镜像源”“北京师范大学镜像源”这一类词很多朋友看到“镜像源”三个字就兴奋直接把地址塞进daemon.json然后发现完全没用甚至报错。原因很简单清华、北师大这些高校站点的镜像服务覆盖的是系统软件源、Python 包、Conda 包这类内容它们并不是 Docker Registry Mirror。你拿docker.io的镜像去请求一个 pip 源那肯定得不到正确的响应。而像中科大这种既提供系统源、又提供 Docker 镜像服务的站点你也要看清楚路径是不是指向 Docker registry 端点而不是看到域名就往上填。判断一个地址到底是不是 Docker 镜像加速源其实有一个很简单的办法。Docker Registry 的服务端会返回一个固定的响应头叫Docker-Distribution-Api-Version。你可以用curl探测一下curl -sI https://docker.mirrors.huaweicloud.com/v2/ | grep -i Docker-Distribution如果输出里有类似Docker-Distribution-Api-Version: registry/2.0的内容说明这个地址确实是 Docker Registry可以继续考虑配置如果没有那就别折腾了它不是能直接用的 Docker 镜像源。3. 配置实测从写入 daemon.json 到确认加速生效3.1 Linux 下配置 daemon.json 多源在 Linux 环境里Docker 的守护进程配置都写在/etc/docker/daemon.json镜像加速器也是在这里配置。不同发行版路径基本一致唯一要注意的是有些系统安装 Docker 之后压根没这个文件需要你手工创建。动手之前先备份永远是好习惯sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak然后编辑文件写入如下内容{ registry-mirrors: [ https://docker.mirrors.huaweicloud.com, https://docker.m.daocloud.io, https://mirror.baidubce.com ] }这里字段名是registry-mirrors值是字符串数组。Docker 会按你写的顺序尝试使用这些源。很多人会问是不是源写得越多越好我的经验是 3 到 4 个就足够了。因为 Docker 客户端在某一个源超时时不一定会非常聪明地快速跳到下一个源源过多反而可能导致整体拉取时间变长。选两个大厂源加一个备用源是比较合理的组合。写完保存后重启 Docker 守护进程让配置生效sudo systemctl restart docker如果你用的是没有 systemd 的旧版本系统可以用sudo service docker restart效果是一样的。3.2 Docker Desktop 的配置位置Windows 和 macOS 上装了 Docker Desktop 的配置入口不在命令行而是在图形界面里。打开 Docker Desktop 后点击右上角设置齿轮图标找到Docker Engine选项卡。这个页面其实就是一个可视化的daemon.json编辑器。你把上面那段 JSON 复制进去注意保留原有配置项然后点击Apply RestartDocker Desktop 会自动重启并加载新配置。这里要特别提一个热搜里反复出现的报错Windows 上启动 Docker Desktop 时提示virtualization support not detected或者docker desktop failed to start because v...。遇到这种提示说明你的电脑在 BIOS 层面没有开启虚拟化或者 Hyper-V、虚拟机监控程序相关功能没启用。这和镜像源加速没有半毛钱关系再怎么换registry-mirrors也救不活。必须先到 BIOS 里打开 Intel VT-x 或 AMD-V 相关的开关然后在 Windows 功能里启用虚拟化支持Docker Desktop 才能正常启动。排错顺序别搞反了。3.3 怎么确认加速器真正生效很多人配置完自我感觉良好但实际拉镜像根本没走加速器。想确认加速到底有没有生效第一件事是用docker info查看当前生效的配置docker info | grep -A 5 Registry Mirrors如果看到类似下面这样的输出说明配置已经被 Docker 加载了Registry Mirrors: https://docker.mirrors.huaweicloud.com/ https://docker.m.daocloud.io/但配置加载了不代表实际拉取就走这条链路了。第二步我建议拉一个小镜像然后查看它的RepoDigests判断镜像是不是真的来自 Docker Hub 的原始存储。命令大概是这样的docker pull nginx:alpine docker image inspect --format{{json .RepoDigests}} nginx:alpine如果输出里的镜像 digest 指向docker.io/library/nginxsha256:...说明这个镜像的原始出处还是 Docker Hub加速器只是在传输层帮你中转缓存如果输出指向某个镜像源自己的地址说明那只镜像可能不是源自官方库使用时反而要多留个心眼。3.4 用脚本自动探测可用镜像源这份镜像源列表能存活多久说实话我不敢打保票。但你可以用一个简单脚本在需要的时候自己探测一遍哪些源还能用。原理就是前面提到的Docker-Distribution-Api-Version响应头。我经常跑的一段脚本长这样#!/bin/bash # 2026-09 镜像源探测脚本仅用于本机可用性验证 mirrors( https://docker.mirrors.huaweicloud.com https://docker.m.daocloud.io https://mirror.baidubce.com https://mirror.ccs.tencentyun.com https://docker.mirrors.ustc.edu.cn ) for mirror in ${mirrors[]}; do version$(curl -sI --connect-timeout 5 $mirror/v2/ | grep -i Docker-Distribution-Api-Version | tr -d \r) if [ -n $version ]; then echo [可用] $mirror - $version else echo [失效] $mirror fi done把你想测的地址写进去跑一下几秒钟就能知道当前哪些源还活着。这个小脚本我隔几个月就跑一遍跑完更新一下daemon.json比在网上翻旧帖子靠谱得多。4. 常见问题排查镜像拉不下来先别急着换源4.1 典型问题速查表镜像拉不下来的原因千奇百怪但九成以上都跑不出下面这张表。我把高频问题和靠谱解法整理在一起方便你对照处理。现象可能原因建议解法配置了加速器但拉取仍然很慢配置没生效或镜像源本身限流用docker info检查配置换一个可用源再试报错http: server gave HTTP response to HTTPS client配了 HTTP 协议的镜像源新版 Docker 默认拒绝放弃 HTTP 源换 HTTPS 源报错manifest unknown或404镜像源缓存不完整或不存在该 tag换其他源试或直接拉官方 registry拉取过程中报net/http: request canceled超时或网络波动重试把源换成探测稳定的大厂源出现429 Too Many Requests镜像源触发限流错峰拉取改用离线导入或自建私有仓库镜像能拉到但 digest 和官方对不上第三方源缓存了旧镜像或被篡改停止使用该源核对RepoDigestsWindows 启动报虚拟化相关错误BIOS 虚拟化或 Hyper-V 未启用先解决虚拟化问题再谈镜像加速daemon.json写错导致 Docker 启动失败JSON 语法错误或字段拼错备份后用docker校验 JSON 语法再重启这张表里的前几项基本覆盖了我被同事问过的所有问题尤其是 HTTP 源那个坑几乎每隔一阵就会有人踩一次。老版本的 Docker 还允许用 HTTP 源新版本直接把这类配置拦在门外。遇到这类报错别去纠结怎么让 Docker 放行 HTTP直接换一个 HTTPS 的源是最省心的方案。4.2 排查思路从现象倒推原因出现镜像拉取问题的时候我习惯按三步去定位。第一步先看你配的镜像源本身还活着没有。这一步很简单用前面提到的curl命令或者探测脚本就行。如果镜像源都连不上那问题基本不在你的 Docker 客户端。第二步确认 Docker 客户端确实加载了配置。执行docker info看Registry Mirrors字段如果配置项是空的检查daemon.json路径、权限、JSON 格式有没有问题。曾经有朋友把文件放在~/.docker/daemon.json折腾了半天才发现 Docker Daemon 根本不读那个路径。第三步再回到 Docker 自身。跑一个带详细输出和重试机制的命令比如docker pull --retry2 nginx:latest看错误信息到底是网络层错误、认证错误、还是镜像不存在。错误信息里藏着大量线索别一看到红字就急着换源先读清楚它到底在说什么。4.3 我踩过的一些坑有些坑是文档里不会写的。比如很多公共镜像源会在特定时间段尤其是晚上高峰限流你白天测试一切正常晚上部署就疯狂超时。所以我现在的习惯时重要镜像的拉取会尽量放到早上执行避开晚高峰。再比如有些人喜欢把最新版本镜像的 tag 写成latest这在生产环境真的很危险。latest的 digest 会在上游更新时发生变化如果你通过加速器拉取缓存里面可能还是旧版本。要用固定版本号就用固定版本号别图一时方便。还有一个容易被忽略的坑多源配置时Docker 对第一个镜像源的超时判断有时很顽固。如果你把一个已经失效的源写在第一位后面就算有可用源整个拉取过程也可能先卡半天再切换。所以每次更新daemon.json我都建议把探测结果最稳定的源放到第一位失效源直接删掉不要留在配置里“备用”。5. 镜像源全军覆没后的备用方案与长期维护思路5.1 离线导入导出一份谁都拿不走的镜像包每次镜像源大规模失效网上都是一片哀嚎。但如果你平时有“离线导出”的习惯这时候就能从容很多。Docker 本身提供了非常成熟的镜像保存和导入机制# 在能正常拉取镜像的机器上 docker save -o nginx-alpine.tar nginx:alpine # 把 tar 文件拷贝到目标机器后导入 docker load -i nginx-alpine.tardocker save会把镜像的全部层打成一个 tar 包docker load再把这个包完整恢复成镜像。这个方法适合内网隔离环境、紧急部署、以及公共镜像源全部失效的场景。我自己在大量初始化新机器时经常提前把一套常用镜像打包到移动硬盘里到现场直接load速度远比现场拉镜像快得多。5.2 自建内网镜像仓库把主动权拿回来如果团队规模大一点或者你有多台机器都要用同一批镜那离线 tar 包的维护成本就上来了。更合理的方式是在内网部署一个 Docker 私有仓库比如直接起一个registry容器做基础分发或者用 Harbor 做带 UI 和权限管理的完整方案。我建议的操作是在公共镜像源还可以用的时候把团队常用的镜像全部拉取一遍然后重新打 tag 推到内网仓库。之后所有机器都从内网仓库拉取速度快、可控、不受外部影响。流程很简单docker pull nginx:1.27-alpine docker tag nginx:1.27-alpine registry.internal.example.com/library/nginx:1.27-alpine docker push registry.internal.example.com/library/nginx:1.27-alpine这个方案的关键在于外部公共源对你来说只是“上游供货商”真正给业务提供镜像的是内网仓库。公共源挂了你的内网仓库里的镜像已经落地完全可以继续工作。5.3 日常维护建议把验证脚本变成定期习惯镜像源这件事我一直觉得没必要做到“穷举所有源”更重要的是形成一套自己的维护节奏。我个人的做法是每个季度末花十分钟跑一遍探测脚本确认当前列表里的源哪些还活着然后顺手更新daemon.json和团队文档。如果你也在维护团队的基础设施建议把镜像源列表和验证脚本一起放到内部知识库里并标注每次验证的日期。这样就算半年后你换了项目下一任接手的人也能清楚知道这份列表是什么时候验证过的而不是对着一个 404 地址猜来猜去。任何公共镜像源的地址都可能会变变的不是技术而是运营者心态和网络环境你能控制的不是它们而是自己手头的验证流程和离线备份。这个内容后续还可以往自动化方向扩展比如写一个定时任务自动探测镜像源状态发现异常就通知你或者接一个 Webhook把失效源自动从配置里摘掉。越是在镜像被各种网络因素影响的年代越要让自己手里握住主动权而不是每次都拿别人的公开列表去碰运气。
