年初还在跟团队抱怨Docker Hub 的镜像越拉越慢结果今天又帮同事排查了一次docker pull卡死的问题一条docker pull nginx:latest敲下去屏幕上等到Client.Timeout exceeded while awaiting headers整条流水线直接卡住。这种事遇到一次两次还能忍频繁遇到就真的耽误活了。用过 Docker 的人基本都经历过这种绝望尤其在拉一些大镜像或者 CI 构建高峰期的时候那真是转圈圈转到怀疑人生。这篇文章不做 Docker 基础科普就是一份能直接用的“国内 Docker 镜像源加速”方案汇总。9月8日我刚把市面上还在活跃的公共镜像源挨个测了一轮整理了这份 2026 年最新可用的加速列表同时把不同环境下的配置步骤、验证方法、常见报错和排查思路都写在里面。不管你是个人开发者、运维还是玩 NAS、搞 AI 应用部署照着下面的步骤操作基本几分钟就能把拉镜像的速度提上来。1. 为什么 Docker 拉镜像这么慢加速到底改的是哪一环1.1 一次 docker pull 的完整链路先说清楚问题出在哪儿。你执行docker pull nginx:latest的时候Docker 客户端会先去找镜像仓库服务器默认就是 Docker 官方的registry-1.docker.io。找到之后它会去下载 manifest 清单然后按清单里的分层地址去拉取数据。问题的关键就在这Docker Hub 的镜像数据存储层走的是海外 CDN在你没有额外配置的情况下这些流量会直接连到海外的存储节点。中间经过的链路越长延迟就越明显高峰期还可能遇到带宽拥塞最终表现就是下载速度只有几十 KB甚至直接超时。这不是你带宽不够是物理链路决定了拉取体验就是这么差。1.2 registry mirror 到底是什么Docker 官方其实早就考虑过这个问题所以提供了 registry mirror镜像加速器机制。它的原理不复杂在 Docker 配置里指定一个registry-mirrors地址拉镜像的时候 Docker 会先去你配置的这个镜像源上找如果找到就直接从那里下载完全不走 Docker Hub 海外节点。本质上registry mirror 是一个位于国内、离你更近的“前置缓存”。它会在你第一次拉某个镜像时把数据缓存到自己的存储里后续再有其他人拉同一个镜像就直接从缓存命中速度自然就快了。加了镜像源之后你平时执行docker pull的方式完全不用变不需要手动改镜像名只需改 Docker 守护进程的配置就行。1.3 为什么公共镜像源一直在变很多朋友都遇到过这种情况今天照着网上的教程配了一个镜像源用了一个月突然又不通了然后就只能再去找新地址很折腾。这里面有几个现实原因第一运营一个公共镜像源有实打实的带宽成本用的人越多成本越高一旦超出承受范围就可能限流或者停服第二部分镜像源会收到各种合规审查要求为了安全起见选择关闭公共入口第三公共源经常被脚本批量刷镜像长期下去对运营方是不小的负担。这些都决定了一个公共镜像源的寿命可能只有几个月到一两年。所以网上那些 2022、2023 年分享的镜像源列表到 2026 年基本已经大面积失效了。这也是为什么更新一份当前可用的列表是有价值的——配置镜像源这件事除了方法要对时效性也非常重要。2. 2026年9月8日实测可用的镜像加速源列表2.1 当前推荐优先使用的镜像源这一轮我测试的方式很简单先看 HTTPS 端口能否正常返回再用docker pull拉一个小镜像验证实际效果。最终筛选出下面几个在大部分网络环境下都能稳定通的情况。注意不同地区不同运营商的实际访问效果会有差异建议主备都配上。镜像源地址当前状态说明https://docker.1ms.run推荐使用近期社区反馈比较稳定速度表现不错支持 Docker Hub 镜像直接拉取https://docker.1panel.live推荐使用1Panel 团队维护可用性较高适合作为主源或备源https://docker.m.daocloud.io推荐使用DaoCloud 的公共加速地址运营时间长多仓库支持相对完善https://docker.rainbond.cc可用好雨科技维护的公益源速度不算最快但胜在稳定https://docker.udayun.com可用优云科技提供的公益源适合作为备用https://mirror.ccs.tencentyun.com特定环境腾讯云内网专用腾讯云服务器上用这个效果很好其他网络环境一般你的阿里云专属加速器推荐使用阿里云容器镜像服务页面分配的专属地址格式为xxxxx.mirror.aliyuncs.com阿里云那个地址值得单独说一下。它不像其他公共源是所有人共用同一个域名而是每个阿里云账号都有一个专属加速地址。登录阿里云控制台搜“容器镜像服务”在镜像加速器页面就能看到属于你的那个地址格式类似xxxxxxxx.mirror.aliyuncs.com。没有账号的话也可以注册一个个人版免费额度足够平时使用了。这个源的稳定性在几大云厂商里算比较靠前的。2.2 已经被限流或停止服务的镜像源大家可能在一些老教程里看到过很多熟悉的地址这里必须提醒一下这些源现在已经基本不能用了镜像源地址当前状态说明https://docker.mirrors.ustc.edu.cn已限制中科大源早已公告限制外部访问现在配了基本拉不动https://hub-mirror.c.163.com不稳定网易源近两年基本处于不可用状态不建议再配置https://registry.docker-cn.com已停止Docker 官方中国站早已停止服务https://dockerproxy.com已关闭老教程里的高频地址现已关闭https://docker.mirror.daocloud.io不稳定DaoCloud 的老版地址推荐换成新版docker.m.daocloud.io如果你发现自己 daemon.json 里配置的是上面这些地址别怀疑失效就是原因。直接删掉换成新的就行。2.3 如何自己快速验证一个镜像源是否可用公共源的生命周期谁也说不准与其完全依赖别人的列表不如自己掌握验证方法。判断镜像源是否可用最快的方式是用 curl 访问它的 registry API 入口curl -s -o /dev/null -m 10 -w %{http_code} %{time_total}s https://docker.1ms.run/v2/registry API 的/v2/接口正常会返回 401 或 200只要不是超时、连接失败就说明这个源还活着。返回时间也很重要如果你发现某个源响应时间超过了 3 秒那实际拉镜像时大概率也不会有多快。更严谨的验证是直接拉一个小镜像实测docker pull docker.1ms.run/library/hello-world:latesthello-world只有几 KB拉取很快不会被带宽因素干扰很适合用来判断一个镜像源是否真的能回源拉取数据。3. 不同环境下配置镜像加速的完整步骤3.1 Docker DesktopWindows / macOS图形界面配置用 Docker Desktop 的朋友最简单不用碰命令行。打开 Docker Desktop进入Settings-Docker Engine这里会看到一个 JSON 格式的配置编辑框。在registry-mirrors字段里填上镜像源地址{ registry-mirrors: [ https://docker.1ms.run, https://docker.1panel.live, https://docker.m.daocloud.io ] }如果原文件里已经有其他字段保留原有内容只把registry-mirrors这段加进去就行。填完之后点击Apply RestartDocker 会自动重启守护进程等状态变成 running 就完成了。这里有一个比较容易踩的坑Docker Desktop 的配置框里 JSON 语法是很严格的少一个逗号、多一个引号都会导致启动失败。如果点击 Apply 后 Docker Desktop 一直起不来大概率是 JSON 格式写错了回到配置框仔细检查一遍尤其是中英文标点符号别混用。3.2 Linux 服务器修改 daemon.json 并重启 DockerLinux 服务器上的配置是通用的不管你是 Ubuntu、CentOS 还是 Debian操作基本一样。先创建/etc/docker/daemon.json没有这个文件就新建一个sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://docker.1ms.run, https://docker.m.daocloud.io ] } EOF然后重新加载 systemd 配置并重启 Dockersudo systemctl daemon-reload sudo systemctl restart docker重启之后可以用systemctl status docker确认服务状态如果状态显示active (running)说明配置没有把服务弄挂。需要提醒的是如果你手上的机器是线上生产环境的单机 Docker建议先备份原来的 daemon.json 再改避免配置错误导致 Docker 无法启动影响线上服务。备份命令很简单sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak3.3 containerd 节点配置Kubernetes 集群场景如果你用的是 Kubernetes节点上的容器运行时一般不是 Docker而是 containerd那配置方式就不一样了。containerd 的默认配置文件在/etc/containerd/config.toml需要修改其中的registry.mirrors配置块。containerd v2.x 的配置格式如下version 2 [registry.mirrors] [registry.mirrors.docker.io] endpoint [https://docker.1ms.run]如果集群版本比较老containerd 还在 v1.x那么配置路径会嵌套在 CRI 插件下面[plugins.io.containerd.grpc.v1.cri.registry.mirrors] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [https://docker.1ms.run]改完之后重启 containerdsudo systemctl restart containerd这里有一个细节containerd 配置里镜像源地址不用加https://之外的路径直接写到根路径即可。还有如果你修改配置前用containerd config default生成过默认配置里面可能会有很多插件配置项注意别把它整段覆盖掉只改或添加 mirrors 相关段落就行。3.4 配置后必须做的验证配置完镜像源最忌讳的就是以为完事了一定要验证是否真的生效。第一个验证命令docker info | grep -A 5 Registry Mirrors输出里如果列出了你配置的镜像源地址说明 Docker 守护进程已经加载了配置。注意docker info显示的是 registry mirror 的配置如果你配置了多个会全部列出来。第二步是实际拉一个镜像测试docker pull nginx:alpine如果拉取速度明显提升不再卡在 waiting 阶段说明配置生效。还可以在拉取日志里观察如果 Docker 走了镜像源速度会快很多不会出现反复重试的情况。配置多个镜像源时Docker 会按列表顺序依次尝试如果第一个源拉取失败会自动切换到第二个源。所以推荐把最稳定的源放在第一位备用源放后面。4. 镜像源的进阶玩法4.1 直接用镜像源前缀拉取任意镜像除了在registry-mirrors里配置全局加速公共镜像源还有一个很实用的用法手动把镜像地址的前缀替换成镜像源的域名。比如你要拉 nginx正常写法是docker pull nginx:latest走镜像源前缀直拉就是docker pull docker.1ms.run/library/nginx:latest原理很简单Docker Hub 上的官方镜像路径是library/nginx前面的docker.1ms.run就是镜像源服务器的地址。遇到某些 registry mirror 对特定镜像拉取有问题时这种前缀直拉的方式反而能绕过去。这个方式也适用于非官方镜像。比如grafana/grafana正常拉取是docker pull grafana/grafana走镜像源就是docker pull docker.m.daocloud.io/grafana/grafana。日常部署中如果遇到镜像拉不下来的情况可以试试用这种方式直拉。4.2 让公共源代理 ghcr、gcr、k8s 等第三方仓库Docker Hub 虽然是最常用的镜像仓库但实际工作中还会遇到各种其他仓库的镜像GitHub Container Registryghcr.io、Google Container Registrygcr.io、Kubernetes 官方镜像仓库registry.k8s.io等。这些仓库在国内的访问情况跟 Docker Hub 半斤八两甚至更差。针对这些仓库不少高校和公益组织维护了专门的代理源典型的有南京大学、上海交大等高校镜像站提供的 ghcr、gcr、k8s 代理地址# 拉取 ghcr.io 上的镜像 docker pull ghcr.nju.edu.cn/owner/repo:tag # 拉取 gcr.io 上的镜像 docker pull gcr.nju.edu.cn/project/image:tag # 拉取 registry.k8s.io 上的镜像 docker pull k8s.nju.edu.cn/kube-apiserver:v1.30.0需要提醒的是高校镜像站通常对访问范围有限制不一定所有网络都能通。用之前可以先 curl 看一下通不通或者直接拉一个小镜像测试。另外也有部分公共镜像源宣称支持多仓库代理比如把docker.m.daocloud.io当成前缀后面接上第三方仓库路径去拉取但是这种支持并不保证长期有效最稳的做法还是先测试。4.3 在内网自建一个 registry mirror 长期兜底公共镜像源毕竟是公共资源今天能用不代表明天能用。如果你的工作环境对稳定性要求比较高尤其是团队多人共用一套 Docker 环境最推荐的长期方案是在内网自己搭一个 registry mirror。Docker 官方提供了一个很轻量的镜像registry:2它本身可以配置成代理模式pull-through cache。一条命令就能启动一个内网镜像加速器docker run -d --name registry-mirror \ -p 5000:5000 \ -e REGISTRY_PROXY_REMOTEURLhttps://registry-1.docker.io \ -v /data/registry:/var/lib/registry \ --restartalways \ registry:2启动之后把团队服务器的 daemon.json 里的registry-mirrors指向这台机器的地址{ registry-mirrors: [ http://192.168.1.100:5000 ] }这样团队里所有成员拉镜像都会先经过内网这台缓存同一个镜像第一次可能还是有点慢但第二次开始就是从内网磁盘直接读速度直接拉满。这个方案能有效摆脱对公共镜像源的依赖也是企业内网常见的做法。要注意的是自建 registry mirror 那台机器需要能访问外网且防火墙只对内网开放 5000 端口。不要暴露到公网否则容易被当成公共源滥用在你不知情的情况下把磁盘和带宽撑爆。4.4 集群和 CI/CD 环境下的最优做法再说一种更规范的做法如果你有自建的 Harbor 镜像仓库可以在 Harbor 里配置一个“代理仓库”Proxy Cache这本质上也是 registry mirror 的企业版。CI/CD 流水线里把镜像拉取的源改成内网 Harbor 地址不管外网公共源怎么变化流水线都不受影响。这个方案适合已经有 Harbor 的团队。配置方式很简单Harbor 的管理界面里新建一个仓库类型选“代理缓存”填上registry-1.docker.io作为上游之后所有镜像通过harbor.example.com/dockerhub/nginx:latest这种形式拉取即可。这个思路跟前面自建 registry mirror 一脉相承但多了权限管理、物尽其用的能力更适合多人协作场景。5. 常见问题与排查技巧实录5.1 常见报错速查表我整理了平时收到问题最多的几类报错以及对应的排查方向报错或现象原因解决办法Client.Timeout exceeded while awaiting headers没有配置镜像源或者配置的源已失效配置可用的国内镜像源换成文中推荐地址配置镜像源后拉取依然超时镜像源地址填错、DNS 解析异常、源本身被限流检查 URL 是否多了/用 curl 验证连通性换备用源manifest unknown镜像 tag 不存在或镜像源回源失败确认 tag 名称拼写正确换一个镜像源尝试pull access denied或 404镜像不存在或仓库名写错使用前缀直拉方式或去官方页面确认镜像路径x509: certificate signed by unknown authority自建 registry 未配置证书或 Docker 不信任自签名证书给自建 registry 配置可信任的证书或将 registry 加入 insecureregistriestoomanyrequests镜像源被限流等一段时间再试或切换到其他镜像源Docker Desktop 启动失败提示虚拟化未开启BIOS 中 VT-x / AMD-V 未打开或和 Hyper-V 冲突重启进入 BIOS 开启虚拟化并在 Windows 功能里启用所需组件5.2 换了镜像源还是慢问题出在哪如果你按前面的步骤配置好了镜像源拉镜像还是慢可以从以下几个方向排查。第一确认配置真的生效了。不要只看docker info里列出了镜像源就觉得 OK因为某些版本 Docker 即使加载了 mirror如果 mirror 拉取失败也会自动再回源到 Docker Hub最终表现就是你依然卡在等待阶段。所以验证配置生效的唯一标准是实际拉镜像的速度明显提升。第二检查 DNS 解析。常见的现象是 DNS 把镜像源域名解析到一个不可达的 IP导致请求一直卡在连接阶段。这时可以先curl测试镜像源域名如果解析出来的 IP 响应很慢可以手动修改/etc/docker/daemon.json之外的系统 DNS 配置把 DNS 换成国内公共 DNS 再进行测试。第三IPv6 网络干扰。部分网络环境的 IPv6 不稳定Docker 默认会优先走 IPv6 解析和连接如果 IPv6 链路质量差同样会导致拉取缓慢。对于这种场景可以在 daemon.json 里显式关闭 IPv6{ ipv6: false }这个问题在双栈网络中很常见很多用户换了镜像源依然慢排查到最后发现是 IPv6 路由绕了远路。5.3 批量测速多个镜像源选出最适合你的那个不同地区对不同镜像源的访问效果差异很大与其一个个手动试不如写一段批量测速脚本一次跑完直接把响应时间列出来。下面这个脚本是我一直在用的放到本机执行即可#!/bin/bash mirrors( https://docker.1ms.run https://docker.1panel.live https://docker.m.daocloud.io https://docker.rainbond.cc https://docker.udayun.com ) for m in ${mirrors[]}; do code$(curl -s -o /dev/null -m 8 -w %{http_code} $m/v2/) time_total$(curl -s -o /dev/null -m 8 -w %{time_total} $m/v2/) echo $m - HTTP $code, ${time_total}s done跑完结果里HTTP 状态码不是000基本说明源是活的time_total越小说明这个源在你的网络环境下响应越快。注意/v2/接口在没有带认证信息时返回 401 是正常的只要连接没有超时就算通。5.4 一些实操中的避坑经验最后分享几条这几个月实际使用的经验每条都是踩过坑之后的体会。镜像源不要配太多。很多人喜欢把能找到的源全部塞进 daemon.json实际上 Docker 会按顺序依次尝试每个源如果前面的源挂掉要等到超时才会切换下一个反而拉长了等待时间。配一个主源加一个备源就足够了最多两个。尽量只依赖一个公共源另一个人工记住备用地址。公共源这种服务随时可能调整建议把备用地址放在备忘录里等主源不可用时再换不要在主源好的时候反复横跳。对于经常用的镜像尤其是基础镜像建议先手动拉一次缓存到本地或者内网 registry 中。不管是公共源还是自建源缓存命中永远比回源快这个道理在任何镜像源场景下都成立。使用公共镜像源时要注意合规性不要在上面跑敏感业务或上传包含敏感信息的镜像公共源不是私有仓库。最后再分享一点个人体会使用国内镜像源这件事我总结起来就是方法要掌握列表要常更新。镜像源列表这种东西本质上是一个消耗品几个月不维护就废了。最好的状态是你既知道怎么配置也具备自己验证某个源还能不能用、快不快的能力这样不管列表怎么变你都不会慌。如果你之前也在为拉镜像头疼建议今天就把文中的推荐源配上实测一次拉取速度那种几十 KB 的速度变成几十 MB 的感觉是真的能让人心情舒畅不少。