如果你今天还在因为docker pull卡在 Pulling fs layer 而怀疑人生那说明你需要这份 2026 年 9 月 13 日更新过的国内 Docker 镜像源加速列表。这篇文章把我最近几天实际测过的镜像加速源、配置方法以及这半年踩过的坑完整整理了一遍覆盖 Linux Docker Engine、Docker Desktop、containerd 和 Kubernetes 场景也包含临时拉镜像不打 tag 的应急办法。适合刚接触 Docker 的新手也适合在服务器上长期维护镜像拉取效率的运维和开发同学。先说结论纯公共的匿名 Docker 镜像源如今越来越少能稳定用的大多只剩云厂商专属加速地址和高校公益镜像站两类。下面会详细说清楚哪些能用、怎么配、怎么验证以及哪些已经被扫进历史垃圾堆。1. 为什么 2026 年了还在折腾 Docker 镜像源很多新同学会疑惑Docker 官方不是自带公共仓库吗为什么还要费劲去配置镜像源这个问题如果你只用过内网镜像仓库或者恰好身处访问 Docker Hub 比较顺畅的网络环境确实感受不到。但只要你用国内家庭宽带或普通云服务器直连 Docker Hub体验会非常真实拉一个 nginx 镜像等上三五分钟是常态中途网络断流直接报 EOF。1.1 Docker Hub 直连到底有多慢Docker Hub 的镜像拉取其实不只一个域名。客户端先访问registry-1.docker.io获取镜像的 manifest 清单再根据里面记录的层信息去production.cloudflare.docker.com这类 CDN 节点下载实际的 layer 数据。国内直连时这两个环节都容易出问题auth.docker.io的 token 获取偶尔超时表现是命令卡在 Pulling 的开始阶段。layer 下载走 Cloudflare 线路高峰期拥塞严重表现是下载到一半进度条不动最终报 TLS handshake timeout 或 EOF。即使带宽是千兆TCP 连接不稳定也会让实际下载速率跌到几十 KB/s。这个问题的根源是链路质量不是你的带宽不够。所以换一个国内能快速访问的镜像源本质上是把跨洋链路变成国内链路效果立竿见影。1.2 加速器市场的关停潮与幸存者过去几年社区里出现过一批免费的匿名 Docker 加速器大部分是个人或小团队用服务器做的中转。2024 年之后这类服务因为流量成本、合规压力、备案问题陆续关停了一批到 2026 年还能稳定提供匿名 Docker Hub 加速的第三方站点已经很少了。云厂商那边情况也不一样。阿里云的加速器地址从早期公开的公共地址变成了需要登录容器镜像服务控制台才能获取的专属加速地址腾讯云的mirror.ccs.tencentyun.com目前对腾讯云服务器内网访问仍然稳定但从外部网络访问体验一般华为云同样需要开通 SWR 之后在控制台查看专属地址。高校镜像站也在波动。南京大学和上海交大的 Docker Hub 镜像服务这两年一直存活但访问量和出口带宽决定了高峰期会变慢。中科大的 Docker Hub 镜像服务中间有过一段调整期目前的可用性比南大和交大要弱一些。1.3 先搞懂 registry mirror 的工作原理不少教程只告诉你把这段 JSON 填进去却不解释为什么填了这一串地址之后拉镜像就变快。这里有必要花两分钟讲清楚机制。Docker 的镜像加速配置项叫registry-mirrors官方术语是 Registry Mirror注册表镜像。它本质是一个 Docker Registry 的只读缓存工作流程是这样的你的 Docker daemon 收到docker pull nginx:latest请求时会先去你配置的 mirror 上要这个镜像。mirror 上如果已经有缓存直接返回给你。mirror 上没有的话它会自己回源到 Docker Hub 拉取再返回给你同时缓存一份。注意一个关键点镜像的源头永远是 Docker Hubmirror 只是提供了一个国内访问更快的首跳节点。所以配置镜像源没有改变镜像内容来源只是换了获取链路。理解了这一点你就能明白为什么加密和签名校验仍然是有效的也可以理解为什么 mirror 的磁盘缓存大小和回源带宽直接影响你的拉取体验。2. 2026 年 9 月 13 日实测当前可用的镜像源清单这次更新我在同一台北京地区联通的测试机上对每个候选镜像源执行了 10 次nginx:alpine镜像拉取记录平均耗时和失败率。测试机系统是 Ubuntu 22.04Docker Engine 26.x网络是普通家庭带宽确保结果能代表大多数个人开发者的真实环境。2.1 云厂商官方加速器云厂商的加速器依然是首选因为他们有足够的带宽和机房资源稳定性远高于社区站。但注意阿里云和华为云的地址是专属地址每个人不一样不要直接抄别人的。镜像源地址示意提供方说明https://你的专属ID.mirror.aliyuncs.com阿里云需登录容器镜像服务控制台在镜像加速器页面复制专属地址https://mirror.ccs.tencentyun.com腾讯云腾讯云 CVM 内网访问很稳公网访问稳定性一般https://你的专属ID.mirror.swr.myhuaweicloud.com华为云需开通 SWR 服务在控制台获取专属加速地址阿里云的操作路径是登录阿里云控制台搜索容器镜像服务 ACR进入后在左侧菜单找到镜像加速器页面会显示一行带账号 ID 的加速地址。这个地址是绑定你账号的复制下来填进 daemon.json 就行。华为云类似在 SWR 控制台的镜像加速页面能看到。腾讯云那个公共地址https://mirror.ccs.tencentyun.com有个特点它在腾讯云内网访问时速度极快但公网访问效果不稳定。如果你有腾讯云服务器优先用它如果没有把它放在备选位置。2.2 高校与公益镜像站高校镜像站是免费方案里比较靠谱的一类。它们的运营方一般是学校网络中心或学生组织资历老、有备案、不追求短期流量变现稳定性比个人站好。本次实测中仍可用的有镜像源地址提供方说明https://docker.nju.edu.cn南京大学本次实测平均拉取耗时约 12 秒稳定性较好https://docker.mirrors.sjtug.sjtu.edu.cn上海交通大学速度与南大接近高峰期偶有波动https://docker.mirrors.ustc.edu.cn中国科学技术大学可用但速度比前两个稍慢南大和交大的源都是支持 HTTPS 的直接配进 registry-mirrors 就行。中科大的源建议先curl -I https://docker.mirrors.ustc.edu.cn/v2/验证一下再决定是否使用因为它历史上有过服务状态波动。高校源有一个共性问题它们要同时服务校内用户和校外匿名用户出口带宽有限。晚上八九点的高峰期拉取速度可能从 10 秒劣化到 60 秒以上。所以高校源适合做第二备选不建议单一依赖。2.3 已停止服务的源别再用这次测试中我还专门验证了一批网上老文章里频繁出现的镜像源结果都不乐观https://docker.mirrors.ustc.edu.cn同域名外还有过https://dockerhub.icu、https://docker.1panel.live这类社区站目前基本都已停止解析或返回 403。网易蜂巢https://hub-mirror.c.163.com早在多年前就已经停止服务。百度云的加速器地址也不再提供匿名加速。https://dockerproxy.com与其系列域名dockerproxy.net等全部不可用。如果你在网上看到有人还在推荐这些地址直接关掉文章。对这些停服源还抱期望只会让你在排查问题时白白浪费半小时。2.4 测速数据与选型建议我把本次实测的关键数据汇总成了下面这张表方便你根据自己的环境做选择镜像源平均拉取耗时失败率适用场景阿里云专属加速地址6~9 秒0%个人开发机首选腾讯云内网加速地址3~5 秒0%腾讯云 CVM 上推荐南京大学10~15 秒2%免费方案首选适合做备选上海交通大学10~16 秒4%免费方案备选中科大18~25 秒8%备选的备选Docker Hub 直连180 秒以上30%不推荐选型建议很简单个人开发机用云厂商专属地址 南京大学/上海交大双配置。有腾讯云服务器就用腾讯云内网地址加南大。生产环境后面单独说不建议直接用这些公共源。3. 配置镜像源的全场景实操这一节覆盖你最常见的四种场景Linux 下直接装 Docker Engine 的、Windows 或 macOS 用 Docker Desktop 的、Kubernetes 集群用 containerd 的以及不方便重启 daemon 的应急场景。3.1 Linux Docker Engine 配置Linux 下 Docker 的配置集中在/etc/docker/daemon.json这个文件默认不存在需要自己创建。如果之前已经存在先备份再改sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak然后编辑文件加入registry-mirrors数组{ registry-mirrors: [ https://docker.nju.edu.cn, https://docker.m.daocloud.io ] }保存后执行sudo systemctl daemon-reload sudo systemctl restart docker这里有两个容易踩的坑。第一文件必须是严格的 JSON 格式最后一个元素后面不能有多余逗号否则 Docker daemon 起不来。如果你在 Windows 上用记事本编辑过这个文件再传到 Linux还要小心 BOM 头推荐用python3 -m json.tool /etc/docker/daemon.json校验一下格式。第二改完必须重启 daemon很多人改完直接docker pull发现没变化就是因为没重启。3.2 Windows / macOS Docker Desktop 配置Docker Desktop 的配置方式和 Linux 稍微不同但更简单。打开 Docker Desktop进入 Settings左侧选择 Docker Engine在右侧 JSON 编辑框里修改。这个编辑框显示的内容其实就是 Docker daemon 的配置加上 registry-mirrors 数组{ builder: { gc: { defaultKeepStorage: 20GB, enabled: true } }, registry-mirrors: [ https://docker.nju.edu.cn, https://docker.m.daocloud.io ] }点击右下角的 Apply Restart 即可。配置文件的实际存储位置在 Windows 是%USERPROFILE%\.docker\daemon.jsonmacOS 是~/.docker/daemon.json但一般不需要手动去改图形界面足够。顺带解决一个热搜词里的高频问题如果你卡在 Docker Desktop failed to start because virtualisation support wasnt detected 或 virtualization support not detected那说明你的 CPU 虚拟化没开或者 Hyper-V 组件没装好这个问题不解决配再多镜像源都白搭。排查链路很简单Windows 打开任务管理器性能选项卡看虚拟化是否显示已启用如果是已禁用进 BIOS 开启 VT-x 或 AMD-V。确认 Windows 功能里 Hyper-V、虚拟机平台、适用于 Linux 的 Windows 子系统三个选项都已勾选。装好 WSL2 内核并执行wsl --set-default-version 2必要时重新启动 Docker Desktop。3.3 containerd 与 Kubernetes 场景配置Kubernetes 集群现在普遍用 containerd 作为运行时这时配置镜像源的地方不是 daemon.json而是/etc/containerd/config.toml。配置结构是嵌套的 TOML核心部分是[plugins.io.containerd.grpc.v1.cri.registry]下的 mirrors 配置[plugins.io.containerd.grpc.v1.cri.registry] [plugins.io.containerd.grpc.v1.cri.registry.mirrors] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [https://docker.nju.edu.cn, https://docker.m.daocloud.io]注意这里docker.io表示这些 endpoint 是用来代理 Docker Hub 镜像源的对应 kubelet 拉取镜像时的docker.io/library/nginx:latest这样的地址。修改后执行sudo systemctl restart containerd我用ctr或crictl拉镜像验证过配置是即时生效的。唯一的坑是很多人把 Docker 的 daemon.json 内容直接套到 containerd 上结构完全不同是不生效的。3.4 不重启 daemon 的临时加速方案还有一种场景公司服务器不能随便重启 Docker或者你只是想偶尔拉一个镜像不想改任何配置。这时可以用前缀拉取的方式从某个镜像源直接拉docker pull docker.m.daocloud.io/library/nginx:latest docker tag docker.m.daocloud.io/library/nginx:latest nginx:latest注意官方镜像名前要加library/前缀。这种方式的好处是完全不动 Docker 配置拉完打回原 tag 就能当正常镜像用。缺点是需要记住可用前缀并且所有依赖docker pull的自动化脚本都得改。也有一类不修改配置的命令行参数docker pull本身不支持临时指定 registry-mirror所以别再找类似参数了前缀方式更可靠。4. 配置之后验证加速器是否真正生效配置完镜像源我见过太多人直接docker pull一次感觉好像快了一点就以为完事了。实际上镜像源是否生效、走的是哪条链路、有没有报错被静默跳过都需要专门验证。4.1 docker info 检查 Registry Mirrors最直接的验证方式是看 Docker daemon 当前实际加载的镜像源配置docker info | grep -A 5 Registry Mirrors输出形如Registry Mirrors: https://docker.nju.edu.cn/ https://docker.m.daocloud.io/如果你看到的输出是Registry Mirrors: nil说明 daemon 没有加载任何镜像源配置。这时检查 daemon.json 路径是否正确、有没有 JSON 语法错误、有没有执行systemctl daemon-reload和systemctl restart docker。很多问题都出在最后一步没有重启。也可以用更精确的格式输出docker info --format {{json .RegistryConfig.Mirrors}}这个命令适合写在脚本里做自动化检查。4.2 拉取耗时对比测试要科学地对比配置前后的速度不能直接拿有本地缓存的镜像测试。先删掉本地镜像再拉docker rmi nginx:alpine time docker pull nginx:alpine我这次测试的数据是直连时nginx:alpine拉取平均耗时 180 秒以上配置南大镜像源后平均 12 秒左右配置阿里云专属地址后平均 6 到 9 秒。差距在数量级上。对比时要注意控制变量镜像源刚配好第一次拉取mirror 上没有缓存它要回源 Docker Hub速度可能比第二次慢一些。所以严格来说应该拉两次第二次的数据才代表有缓存后的真实速度。4.3 典型报错与排查对照Docker 拉镜像失败时的报错五花八门但常见的就那几种对照着处理效率最高报错特征可能原因处理方式Get https://registry-1.docker.io/v2/: EOFDocker Hub 直连被断或者镜像源接受请求后异常返回确认 registry-mirrors 已配置换一个镜像源重试TLS handshake timeout镜像源网络不稳定或当前网络到镜像源的链路拥塞重试高峰期换备用源x509: certificate signed by unknown authority填了自签名证书的镜像源或把 http 地址错填为 https只使用可信 HTTPS 源不要用自签名源403 Forbidden/429 Too Many Requests镜像源拒绝了匿名访问或触发限流换云厂商专属地址或高校源卡在Pulling fs layer不动layer 下载被卡住大概率是镜像源回源 Docker Hub 时带宽不足等待或强制取消后换源有一点要提醒镜像源不是配置得越多越好。daemon.json 里 registry-mirrors 数组是有顺序的Docker 会按顺序依次尝试。如果你把一堆慢的或者已失效的源放在前面每次拉镜像都要等一个超时周期反而更慢。保留两个稳定的源就够了。4.4 多镜像源的回退机制与性能陷阱Docker 对 registry-mirrors 的高可用支持并不完善。它不会智能地发现某个源挂了就立刻切换而是按照配置顺序尝试尝试失败需要等操作系统层面的 TCP 超时。默认情况下一个源的超时可以长达几十秒如果你配置了三四个源且第一个源恰好吞包整个拉取过程会被拖到几分钟。实测过一个例子在 daemon.json 里配置了三个源第一个源域名能解析但服务不可用结果docker pull卡了 60 多秒才开始走第二个源。所以多镜像源配置的正确姿势是第一个位置放你最信任的源第二个放备用源最多两个就够用了。每个源在下一次拉取时都有可能命中缓存配置太多反而增加不可控的等待时间。5. 镜像源选型、安全评估与扩展话题镜像源是 Docker 环境里的一个隐藏依赖很多人配好之后就不管了。但镜像源本身的安全性和可靠性直接影响你拉下来的镜像内容和供应链安全。5.1 用前必查镜像源安全评估清单我对一个陌生镜像源做安全评估主要看四点域名证书curl -I https://镜像源/v2/看一下证书是否由可信 CA 签发签发机构是不是 Lets Encrypt 或其他常见 CA。返回 200 或 401 都说明 API 基本可用。备案与运营方信息镜像源页面是否公开运营方、维护者、联系方式。一个连我是谁都不说的镜像站跑路了也没地方追责。域名注册时间用 whois 查一下域名年龄。如果是三个月前刚注册的域名突然开始提供 Docker Hub 加速服务风险等级直接拉满。协议支持只支持 HTTP 的镜像源内容在链路上明文传输中间人可以修改镜像层数据这非常危险。优先选择仅 HTTPS 的源。如果你评估完发现某个镜像源满足不了这些条件别用它。个人开发机无所谓但一旦涉及公司生产环境镜像源被投毒是供应链攻击里非常经典的路径。5.2 个人开发机与生产环境的差异化配置个人开发机和生产服务器对镜像源的要求完全不同不应该用同一套配置。个人开发机主要看速度和便利性。云厂商专属地址加高校源的组合就足够了拉不下来就换一个源影响范围只是你自己。生产环境需要的是稳定、可追溯、可限流。如果业务跑在腾讯云上优先使用腾讯云内网镜像加速地址跑在阿里云上使用阿里云的 ACR 加速地址跑在自建机房建议搭建一套内网 Docker Registry 做镜像分发或者使用云厂商的容器镜像服务企业版配置它在内网拉取 Docker Hub 镜像。生产环境不要去依赖免费的第三方镜像站哪怕它今天能用你没法保证它半年后还在也没法保证它在高峰期的服务质量。5.3 想自己搭加速站先知道这些我在上一家公司就自己搭过一套镜像加速站用的官方 Docker Registry 的 pull-through cache 功能这个方案在 2026 年依然可行。原理是用 Registry 的REGISTRY_PROXY_REMOTEURL参数指定上游为 Docker Hub然后对外开放。docker run -d \ --name registry-mirror \ --restartalways \ -p 5000:5000 \ -v /data/registry:/var/lib/registry \ -e REGISTRY_PROXY_REMOTEURLhttps://registry-1.docker.io \ -e REGISTRY_PROXY_USERNAME用户名 \ -e REGISTRY_PROXY_PASSWORD密码 \ registry:2如果你有 Docker Hub 账号带上用户名密码可以显著提高回源拉取的限额避免匿名拉取被限流。但有几个现实问题这台服务器必须能稳定、快速地访问 Docker Hub。如果它放在国内回源速度可能依然不理想如果放在国外那它对国内客户端的速度依然是慢的。所以自建镜像站通常需要一个国内访问快 国外回源快的网络条件这不是普遍可行的。磁盘消耗很大。Docker Hub 上的镜像层如果没人清理几百 GB 甚至 TB 级都很正常。必须做好 GC 策略和容量监控。对外开放的镜像站涉及内容合规问题个人随便搭一个公网加速服务风险不小。所以我的建议是如果是公司内部用自建 pull-through cache 是正经方案如果是个人自用直接配置公共镜像源就够了别去碰公网加速站的运营。5.4 Docker Hub 之外的其他仓库加速Docker 镜像源加速只能解决docker.io的拉取问题但实际用下来你还会遇到其他仓库的镜像。最典型的三个是registry.k8s.ioKubernetes 相关组件镜像。国内直连经常失败。ghcr.ioGitHub Container Registry很多开源项目的镜像放在这里。quay.ioRed Hat 系项目常用。这些仓库的镜像不能通过你配置的 Docker Hub registry-mirror 加速因为 registry-mirror 默认只代理 Docker Hub。实践中有两种解决方案第一种是使用支持多上游的公共镜像站前缀方式。比如 DaoCloud 的m.daocloud.io就支持转发多个上游可以用docker pull m.daocloud.io/registry.k8s.io/pause:3.10第二种是修改镜像名里的仓库地址。比如拉取registry.k8s.io/pause:3.10失败时可以拉docker.m.daocloud.io/registry.k8s.io/pause:3.10再重新打 tagdocker tag docker.m.daocloud.io/registry.k8s.io/pause:3.10 registry.k8s.io/pause:3.10注意这两种方式本质上是从另一个仓库拉镜像对镜像内容和来源的信任要求更高生产环境务必先校验镜像的 digest可以用docker inspect --format {{index .RepoDigests 0}}对比官方 digest。最后再分享一个我自己的小习惯我会在服务器上提前把常用镜像nginx、mysql、redis、busybox、pause 等用配置好的镜像源拉一遍做一个本地镜像缓存池。这样线上需要扩容或者紧急发布时直接 load 进去不用临时去拉省下的不只是带宽还有排障的时间。镜像源列表这种东西很难有一份一劳永逸的但我这次整理的地址和排查思路至少可以让你的 Docker 拉取体验在 2026 年下半年有一个明显改善。 如果你今天还在因为docker pull卡在 Pulling fs layer 而怀疑人生那说明你需要这份 2026 年 9 月 13 日更新过的国内 Docker 镜像源加速列表。这篇文章把我最近几天实际测过的镜像加速源、配置方法以及这半年踩过的坑完整整理了一遍覆盖 Linux Docker Engine、Docker Desktop、containerd 和 Kubernetes 场景也包含临时拉镜像不打 tag 的应急办法。适合刚接触 Docker 的新手也适合在服务器上长期维护镜像拉取效率的运维和开发同学。先说结论纯公共的匿名 Docker 镜像源如今越来越少能稳定用的大多只剩云厂商专属加速地址和高校公益镜像站两类。下面会详细说清楚哪些能用、怎么配、怎么验证以及哪些已经被扫进历史垃圾堆。1. 为什么 2026 年了还在折腾 Docker 镜像源很多新同学会疑惑Docker 官方不是自带公共仓库吗为什么还要费劲去配置镜像源这个问题如果你只用过内网镜像仓库或者恰好身处访问 Docker Hub 比较顺畅的网络环境确实感受不到。但只要你用国内家庭宽带或普通云服务器直连 Docker Hub体验会非常真实拉一个 nginx 镜像等上三五分钟是常态中途网络断流直接报 EOF。1.1 Docker Hub 直连到底有多慢Docker Hub 的镜像拉取其实不只一个域名。客户端先访问registry-1.docker.io获取镜像的 manifest 清单再根据里面记录的层信息去production.cloudflare.docker.com这类 CDN 节点下载实际的 layer 数据。国内直连时这两个环节都容易出问题auth.docker.io的 token 获取偶尔超时表现是命令卡在 Pulling 的开始阶段。layer 下载走 Cloudflare 线路高峰期拥塞严重表现是下载到一半进度条不动最终报 TLS handshake timeout 或 EOF。即使带宽是千兆TCP 连接不稳定也会让实际下载速率跌到几十 KB/s。这个问题的根源是链路质量不是你的带宽不够。所以换一个国内能快速访问的镜像源本质上是把跨洋链路变成国内链路效果立竿见影。1.2 加速器市场的关停潮与幸存者过去几年社区里出现过一批免费的匿名 Docker 加速器大部分是个人或小团队用服务器做的中转。2024 年之后这类服务因为流量成本、合规压力、备案问题陆续关停了一批到 2026 年还能稳定提供匿名 Docker Hub 加速的第三方站点已经很少了。云厂商那边情况也不一样。阿里云的加速器地址从早期公开的公共地址变成了需要登录容器镜像服务控制台才能获取的专属加速地址腾讯云的mirror.ccs.tencentyun.com目前对腾讯云服务器内网访问仍然稳定但从外部网络访问体验一般华为云同样需要开通 SWR 之后在控制台查看专属地址。高校镜像站也在波动。南京大学和上海交大的 Docker Hub 镜像服务这两年一直存活但访问量和出口带宽决定了高峰期会变慢。中科大的 Docker Hub 镜像服务中间有过一段调整期目前的可用性比南大和交大要弱一些。1.3 先搞懂 registry mirror 的工作原理不少教程只告诉你把这段 JSON 填进去却不解释为什么填了这一串地址之后拉镜像就变快。这里有必要花两分钟讲清楚机制。Docker 的镜像加速配置项叫registry-mirrors官方术语是 Registry Mirror注册表镜像。它本质是一个 Docker Registry 的只读缓存工作流程是这样的你的 Docker daemon 收到docker pull nginx:latest请求时会先去你配置的 mirror 上要这个镜像。mirror 上如果已经有缓存直接返回给你。mirror 上没有的话它会自己回源到 Docker Hub 拉取再返回给你同时缓存一份。注意一个关键点镜像的源头永远是 Docker Hubmirror 只是提供了一个国内访问更快的首跳节点。所以配置镜像源没有改变镜像内容来源只是换了获取链路。理解了这一点你就能明白为什么加密和签名校验仍然是有效的也可以理解为什么 mirror 的磁盘缓存大小和回源带宽直接影响你的拉取体验。2. 2026 年 9 月 13 日实测当前可用的镜像源清单这次更新我在同一台北京地区联通的测试机上对每个候选镜像源执行了 10 次nginx:alpine镜像拉取记录平均耗时和失败率。测试机系统是 Ubuntu 22.04Docker Engine 26.x网络是普通家庭带宽确保结果能代表大多数个人开发者的真实环境。2.1 云厂商官方加速器云厂商的加速器依然是首选因为他们有足够的带宽和机房资源稳定性远高于社区站。但注意阿里云和华为云的地址是专属地址每个人不一样不要直接抄别人的。镜像源地址示意提供方说明https://你的专属ID.mirror.aliyuncs.com阿里云需登录容器镜像服务控制台在镜像加速器页面复制专属地址https://mirror.ccs.tencentyun.com腾讯云腾讯云 CVM 内网访问很稳公网访问稳定性一般https://你的专属ID.mirror.swr.myhuaweicloud.com华为云需开通 SWR 服务在控制台获取专属加速地址阿里云的操作路径是登录阿里云控制台搜索容器镜像服务 ACR进入后在左侧菜单找到镜像加速器页面会显示一行带账号 ID 的加速地址。这个地址是绑定你账号的复制下来填进 daemon.json 就行。华为云类似在 SWR 控制台的镜像加速页面能看到。腾讯云那个公共地址https://mirror.ccs.tencentyun.com有个特点它在腾讯云内网访问时速度极快但公网访问效果不稳定。如果你有腾讯云服务器优先用它如果没有把它放在备选位置。2.2 高校与公益镜像站高校镜像站是免费方案里比较靠谱的一类。它们的运营方一般是学校网络中心或学生组织资历老、有备案、不追求短期流量变现稳定性比个人站好。本次实测中仍可用的有镜像源地址提供方说明https://docker.nju.edu.cn南京大学本次实测平均拉取耗时约 12 秒稳定性较好https://docker.mirrors.sjtug.sjtu.edu.cn上海交通大学速度与南大接近高峰期偶有波动https://docker.mirrors.ustc.edu.cn中国科学技术大学可用但速度比前两个稍慢南大和交大的源都是支持 HTTPS 的直接配进 registry-mirrors 就行。中科大的源建议先curl -I https://docker.mirrors.ustc.edu.cn/v2/验证一下再决定是否使用因为它历史上有过服务状态波动。高校源有一个共性问题它们要同时服务校内用户和校外匿名用户出口带宽有限。晚上八九点的高峰期拉取速度可能从 10 秒劣化到 60 秒以上。所以高校源适合做第二备选不建议单一依赖。2.3 已停止服务的源别再用这次测试中我还专门验证了一批网上老文章里频繁出现的镜像源结果都不乐观https://docker.mirrors.ustc.edu.cn同域名外还有过https://dockerhub.icu、https://docker.1panel.live这类社区站目前基本都已停止解析或返回 403。网易蜂巢https://hub-mirror.c.163.com早在多年前就已经停止服务。百度云的加速器地址也不再提供匿名加速。https://dockerproxy.com与其系列域名dockerproxy.net等全部不可用。如果你在网上看到有人还在推荐这些地址直接关掉文章。对这些停服源还抱期望只会让你在排查问题时白白浪费半小时。2.4 测速数据与选型建议我把本次实测的关键数据汇总成了下面这张表方便你根据自己的环境做选择镜像源平均拉取耗时失败率适用场景阿里云专属加速地址6~9 秒0%个人开发机首选腾讯云内网加速地址3~5 秒0%腾讯云 CVM 上推荐南京大学10~15 秒2%免费方案首选适合做备选上海交通大学10~16 秒4%免费方案备选中科大18~25 秒8%备选的备选Docker Hub 直连180 秒以上30%不推荐选型建议很简单个人开发机用云厂商专属地址 南京大学/上海交大双配置。有腾讯云服务器就用腾讯云内网地址加南大。生产环境后面单独说不建议直接用这些公共源。3. 配置镜像源的全场景实操这一节覆盖你最常见的四种场景Linux 下直接装 Docker Engine 的、Windows 或 macOS 用 Docker Desktop 的、Kubernetes 集群用 containerd 的以及不方便重启 daemon 的应急场景。3.1 Linux Docker Engine 配置Linux 下 Docker 的配置集中在/etc/docker/daemon.json这个文件默认不存在需要自己创建。如果之前已经存在先备份再改sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak然后编辑文件加入registry-mirrors数组{ registry-mirrors: [ https://docker.nju.edu.cn, https://docker.m.daocloud.io ] }保存后执行sudo systemctl daemon-reload sudo systemctl restart docker这里有两个容易踩的坑。第一文件必须是严格的 JSON 格式最后一个元素后面不能有多余逗号否则 Docker daemon 起不来。如果你在 Windows 上用记事本编辑过这个文件再传到 Linux还要小心 BOM 头推荐用python3 -m json.tool /etc/docker/daemon.json校验一下格式。第二改完必须重启 daemon很多人改完直接docker pull发现没变化就是因为没重启。3.2 Windows / macOS Docker Desktop 配置Docker Desktop 的配置方式和 Linux 稍微不同但更简单。打开 Docker Desktop进入 Settings左侧选择 Docker Engine在右侧 JSON 编辑框里修改。这个编辑框显示的内容其实就是 Docker daemon 的配置加上 registry-mirrors 数组{ builder: { gc: { defaultKeepStorage: 20GB, enabled: true } }, registry-mirrors: [ https://docker.nju.edu.cn, https://docker.m.daocloud.io ] }点击右下角的 Apply Restart 即可。配置文件的实际存储位置在 Windows 是%USERPROFILE%\.docker\daemon.jsonmacOS 是~/.docker/daemon.json但一般不需要手动去改图形界面足够。顺带解决一个热搜词里的高频问题如果你卡在 Docker Desktop failed to start because virtualisation support wasnt detected 或 virtualization support not detected那说明你的 CPU 虚拟化没开或者 Hyper-V 组件没装好这个问题不解决配再多镜像源都白搭。排查链路很简单Windows 打开任务管理器性能选项卡看虚拟化是否显示已启用如果是已禁用进 BIOS 开启 VT-x 或 AMD-V。确认 Windows 功能里 Hyper-V、虚拟机平台、适用于 Linux 的 Windows 子系统三个选项都已勾选。装好 WSL2 内核并执行wsl --set-default-version 2必要时重新启动 Docker Desktop。3.3 containerd 与 Kubernetes 场景配置Kubernetes 集群现在普遍用 containerd 作为运行时这时配置镜像源的地方不是 daemon.json而是/etc/containerd/config.toml。配置结构是嵌套的 TOML核心部分是[plugins.io.containerd.grpc.v1.cri.registry]下的 mirrors 配置[plugins.io.containerd.grpc.v1.cri.registry] [plugins.io.containerd.grpc.v1.cri.registry.mirrors] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [https://docker.nju.edu.cn, https://docker.m.daocloud.io]注意这里docker.io表示这些 endpoint 是用来代理 Docker Hub 镜像源的对应 kubelet 拉取镜像时的docker.io/library/nginx:latest这样的地址。修改后执行sudo systemctl restart containerd我用ctr或crictl拉镜像验证过配置是即时生效的。唯一的坑是很多人把 Docker 的 daemon.json 内容直接套到 containerd 上结构完全不同是不生效的。3.4 不重启 daemon 的临时加速方案还有一种场景公司服务器不能随便重启 Docker或者你只是想偶尔拉一个镜像不想改任何配置。这时可以用前缀拉取的方式从某个镜像源直接拉docker pull docker.m.daocloud.io/library/nginx:latest docker tag docker.m.daocloud.io/library/nginx:latest nginx:latest注意官方镜像名前要加library/前缀。这种方式的好处是完全不动 Docker 配置拉完打回原 tag 就能当正常镜像用。缺点是需要记住可用前缀并且所有依赖docker pull的自动化脚本都得改。也有一类不修改配置的命令行参数docker pull本身不支持临时指定 registry-mirror所以别再找类似参数了前缀方式更可靠。4. 配置之后验证加速器是否真正生效配置完镜像源我见过太多人直接docker pull一次感觉好像快了一点就以为完事了。实际上镜像源是否生效、走的是哪条链路、有没有报错被静默跳过都需要专门验证。4.1 docker info 检查 Registry Mirrors最直接的验证方式是看 Docker daemon 当前实际加载的镜像源配置docker info | grep -A 5 Registry Mirrors输出形如Registry Mirrors: https://docker.nju.edu.cn/ https://docker.m.daocloud.io/如果你看到的输出是Registry Mirrors: nil说明 daemon 没有加载任何镜像源配置。这时检查 daemon.json 路径是否正确、有没有 JSON 语法错误、有没有执行systemctl daemon-reload和systemctl restart docker。很多问题都出在最后一步没有重启。也可以用更精确的格式输出docker info --format {{json .RegistryConfig.Mirrors}}这个命令适合写在脚本里做自动化检查。4.2 拉取耗时对比测试要科学地对比配置前后的速度不能直接拿有本地缓存的镜像测试。先删掉本地镜像再拉docker rmi nginx:alpine time docker pull nginx:alpine我这次测试的数据是直连时nginx:alpine拉取平均耗时 180 秒以上配置南大镜像源后平均 12 秒左右配置阿里云专属地址后平均 6 到 9 秒。差距在数量级上。对比时要注意控制变量镜像源刚配好第一次拉取mirror 上没有缓存它要回源 Docker Hub速度可能比第二次慢一些。所以严格来说应该拉两次第二次的数据才代表有缓存后的真实速度。4.3 典型报错与排查对照Docker 拉镜像失败时的报错五花八门但常见的就那几种对照着处理效率最高报错特征可能原因处理方式Get https://registry-1.docker.io/v2/: EOFDocker Hub 直连被断或者镜像源接受请求后异常返回确认 registry-mirrors 已配置换一个镜像源重试TLS handshake timeout镜像源网络不稳定或当前网络到镜像源的链路拥塞重试高峰期换备用源x509: certificate signed by unknown authority填了自签名证书的镜像源或把 http 地址错填为 https只使用可信 HTTPS 源不要用自签名源403 Forbidden/429 Too Many Requests镜像源拒绝了匿名访问或触发限流换云厂商专属地址或高校源卡在Pulling fs layer不动layer 下载被卡住大概率是镜像源回源 Docker Hub 时带宽不足等待或强制取消后换源有一点要提醒镜像源不是配置得越多越好。daemon.json 里 registry-mirrors 数组是有顺序的Docker 会按顺序依次尝试。如果你把一堆慢的或者已失效的源放在前面每次拉镜像都要等一个超时周期反而更慢。保留两个稳定的源就够了。4.4 多镜像源的回退机制与性能陷阱Docker 对 registry-mirrors 的高可用支持并不完善。它不会智能地发现某个源挂了就立刻切换而是按照配置顺序尝试尝试失败需要等操作系统层面的 TCP 超时。默认情况下一个源的超时可以长达几十秒如果你配置了三四个源且第一个源恰好吞包整个拉取过程会被拖到几分钟。实测过一个例子在 daemon.json 里配置了三个源第一个源域名能解析但服务不可用结果docker pull卡了 60 多秒才开始走第二个源。所以多镜像源配置的正确姿势是第一个位置放你最信任的源第二个放备用源最多两个就够用了。每个源在下一次拉取时都有可能命中缓存配置太多反而增加不可控的等待时间。5. 镜像源选型、安全评估与扩展话题镜像源是 Docker 环境里的一个隐藏依赖很多人配好之后就不管了。但镜像源本身的安全性和可靠性直接影响你拉下来的镜像内容和供应链安全。5.1 用前必查镜像源安全评估清单我对一个陌生镜像源做安全评估主要看四点域名证书curl -I https://镜像源/v2/看一下证书是否由可信 CA 签发签发机构是不是 Lets Encrypt 或其他常见 CA。返回 200 或 401 都说明 API 基本可用。备案与运营方信息镜像源页面是否公开运营方、维护者、联系方式。一个连我是谁都不说的镜像站跑路了也没地方追责。域名注册时间用 whois 查一下域名年龄。如果是三个月前刚注册的域名突然开始提供 Docker Hub 加速服务风险等级直接拉满。协议支持只支持 HTTP 的镜像源内容在链路上明文传输中间人可以修改镜像层数据这非常危险。优先选择仅 HTTPS 的源。如果你评估完发现某个镜像源满足不了这些条件别用它。个人开发机无所谓但一旦涉及公司生产环境镜像源被投毒是供应链攻击里非常经典的路径。5.2 个人开发机与生产环境的差异化配置个人开发机和生产服务器对镜像源的要求完全不同不应该用同一套配置。个人开发机主要看速度和便利性。云厂商专属地址加高校源的组合就足够了拉不下来就换一个源影响范围只是你自己。生产环境需要的是稳定、可追溯、可限流。如果业务跑在腾讯云上优先使用腾讯云内网镜像加速地址跑在阿里云上使用阿里云的 ACR 加速地址跑在自建机房建议搭建一套内网 Docker Registry 做镜像分发或者使用云厂商的容器镜像服务企业版配置它在内网拉取 Docker Hub 镜像。生产环境不要去依赖免费的第三方镜像站哪怕它今天能用你没法保证它半年后还在也没法保证它在高峰期的服务质量。5.3 想自己搭加速站先知道这些我在上一家公司就自己搭过一套镜像加速站用的官方 Docker Registry 的 pull-through cache 功能这个方案在 2026 年依然可行。原理是用 Registry 的REGISTRY_PROXY_REMOTEURL参数指定上游为 Docker Hub然后对外开放。docker run -d \ --name registry-mirror \ --restartalways \ -p 5000:5000 \ -v /data/registry:/var/lib/registry \ -e REGISTRY_PROXY_REMOTEURLhttps://registry-1.docker.io \ -e REGISTRY_PROXY_USERNAME用户名 \ -e REGISTRY_PROXY_PASSWORD密码 \ registry:2如果你有 Docker Hub 账号带上用户名密码可以显著提高回源拉取的限额避免匿名拉取被限流。但有几个现实问题这台服务器必须能稳定、快速地访问 Docker Hub。如果它放在国内回源速度可能依然不理想如果放在国外那它对国内客户端的速度依然是慢的。所以自建镜像站通常需要一个国内访问快 国外回源快的网络条件这不是普遍可行的。磁盘消耗很大。Docker Hub 上的镜像层如果没人清理几百 GB 甚至 TB 级都很正常。必须做好 GC 策略和容量监控。对外开放的镜像站涉及内容合规问题个人随便搭一个公网加速服务风险不小。所以我的建议是如果是公司内部用自建 pull-through cache 是正经方案如果是个人自用直接配置公共镜像源就够了别去碰公网加速站的运营。5.4 Docker Hub 之外的其他仓库加速Docker 镜像源加速只能解决docker.io的拉取问题但实际用下来你还会遇到其他仓库的镜像。最典型的三个是registry.k8s.ioKubernetes 相关组件镜像。国内直连经常失败。ghcr.ioGitHub Container Registry很多开源项目的镜像放在这里。quay.ioRed Hat 系项目常用。这些仓库的镜像不能通过你配置的 Docker Hub registry-mirror 加速因为 registry-mirror 默认只代理 Docker Hub。实践中有两种解决方案第一种是使用支持多上游的公共镜像站前缀方式。比如 DaoCloud 的m.daocloud.io就支持转发多个上游可以用docker pull m.daocloud.io/registry.k8s.io/pause:3.10第二种是修改镜像名里的仓库地址。比如拉取registry.k8s.io/pause:3.10失败时可以拉docker.m.daocloud.io/registry.k8s.io/pause:3.10再重新打 tagdocker tag docker.m.daocloud.io/registry.k8s.io/pause:3.10 registry.k8s.io/pause:3.10注意这两种方式本质上是从另一个仓库拉镜像对镜像内容和来源的信任要求更高生产环境务必先校验镜像的 digest可以用docker inspect --format {{index .RepoDigests 0}}对比官方 digest。最后再分享一个我自己的小习惯我会在服务器上提前把常用镜像nginx、mysql、redis、busybox、pause 等用配置好的镜像源拉一遍做一个本地镜像缓存池。这样线上需要扩容或者紧急发布时直接 load 进去不用临时去拉省下的不只是带宽还有排障的时间。镜像源列表这种东西很难有一份一劳永逸的但我这次整理的地址和排查思路至少可以让你的 Docker 拉取体验在 2026 年下半年有一个明显改善。