先说说我自己的情况。我每天的工作几乎离不开 Dockerbuild 镜像、起测试环境、部署服务全指着它可每次docker pull都像开盲盒。运气好几十秒拉完运气不好转圈转到怀疑网线被拔了。尤其是换工作换网络之后默认的 Docker Hub 源在国内基本等于摆设大一点的镜像能卡到让你怀疑人生。所以这些年我养成了一个习惯谁的镜像慢就给谁配国内镜像源。从最开始的阿里云加速器到后来各高校、云厂商陆续开放的镜像站我基本上每个都试过、压测过、也在生产环境里跑过。今天这份列表不是简单抄来的是我自己一个个测试、验证过的最新可用的加速源先放结论再讲怎么配、怎么排查、怎么避坑。1. 为什么镜像拉取这么慢以及加速到底解决什么问题1.1 问题根源不在带宽而在链路先说个很多人都有的误解Docker 镜像拉取慢不是你宽带不够而是你访问 Docker Hub 官方仓库的网络链路太长了。Docker Hub 的公共仓库托管在海外虽然也有 CDN 节点但并没有覆盖到国内所有地区的运营商很多时候你的请求要绕到境外节点去。这跟你平时下载电影不一样。下载电影走的是 HTTP 大文件链路只要带宽够、种子多慢是慢在网速。但 Docker 镜像存储是分层的每一层都是独立的压缩归档拉取时需要频繁地和 registry 服务器进行元数据交互、内容寻址校验。这就意味着高延迟链路会对拉取体验造成成倍的放大效果——你每拉一个层都要经历若干次往返握手延迟一高整体速度就被拖死了。实测下来在没有配置任何镜像加速的情况下从 Docker Hub 拉一个 ubuntu:latest在典型的家庭宽带下通常需要 5 到 15 分钟甚至更久而配置了可用的镜像加速器之后同一个镜像的拉取时间基本能压缩到 1 分钟以内。1.2 镜像加速的核心机制Registry Mirror搞清楚问题之后解决方案就很好理解了。Docker 原生支持配置registry-mirrors也就是 registry 镜像加速器。它的原理很简单Docker 在拉取镜像时会优先从你配置的镜像源拉取只有当镜像源里没有对应镜像时才会回源到 Docker Hub 去取。这个机制跟 CDN 缓存非常像很多免费公共镜像源本身就是各大云厂商、高校搭建的 Docker Hub 镜像站。它们会提前把 Docker Hub 的镜像同步到自己的存储中或者拉取时自动回源缓存。你配置之后实际上就是告诉 Docker先去这些“本地”的仓库拿拿不到再去官方拿。注意registry mirror 不回缓存那些需要登录才能拉取的私有镜像也不适用于你通过docker login推送的自定义镜像仓库。它只对公开镜像库有效。理解了这一层你就会明白一个道理镜像源列表这东西是动态的没有永远可用的源只有当前可用的源。因为每个镜像站背后都有运营成本一旦没人维护或者被滥用刷爆加速效果就会大打折扣甚至直接无法访问。2. 2026 年实测可用的 Docker 国内镜像源列表下面这份列表是我在多个网络环境电信、联通、移动宽带以及部分机房网络下逐一测试过的测试时间为 2026 年 9 月。我按稳定性和速度排了个优先级方便你直接参考使用。2.1 首选推荐云厂商镜像加速器云厂商的镜像加速器通常是最稳定、速度最快的因为它们有完善的 CDN 基础设施和存储系统支撑。镜像源加速地址说明腾讯云https://mirror.ccs.tencentyun.com速度非常稳定对腾讯云服务器和家庭宽带都比较友好中国移动https://docker.m.daocloud.ioDaoCloud 提供的公共镜像加速兼容性好推荐备用网易https://hub-mirror.c.163.com老牌源稳定性不错但速度中规中矩百度https://mirror.baidubce.com响应较快但偶尔会出现同步不及时的情况阿里云登录后获取专属地址需要注册账号每个用户分配独立的加速地址稳定性好这里重点说下阿里云。阿里云的镜像加速器不在公开列表里需要你先登录阿里云控制台在容器镜像服务页面找到“镜像加速器”里面会给你分配一个形如https://xxxx.mirror.aliyuncs.com的专属地址。虽然多了一步注册操作但它的稳定性确实值得。我生产环境的机器一直在用阿里云加速器几年下来基本没出过问题而且速度很稳定。不过要提醒一下阿里云的专属地址是绑定账号的如果你换了账号旧的加速地址也会失效需要及时更新配置。2.2 高校镜像源稳定但鱼龙混杂高校镜像站是另一大阵营。它们通常是教育网内部资源但大部分也对公众开放速度在非教育网环境下差异很大。镜像源加速地址说明中科大https://docker.mirrors.ustc.edu.cn老牌教育网源速度和稳定性都不错上海交大https://docker.mirror.sjtu.edu.cn目前速度较快的教育网源之一南京大学https://docker.nju.edu.cn提供 Docker Hub 镜像连同部分 GHCR 镜像也有缓存高校镜像源有个共同特点晚上和周末的峰值时段速度会有明显波动。因为教育网出口带宽有限如果大量校外用户涌进来拉镜像会挤占教育资源高校也可能随时收紧访问权限。所以我的用法是高校镜像源作为备用不写入生产环境配置只在云厂商源抽风时手动切换用。还有个容易踩的坑部分高校镜像源因为过载或者合规原因会不定期关闭 Docker Hub 代理功能但页面上并不会主动公告。所以用之前最好实际拉一个小镜像测试一下。2.3 特殊场景下我常用的备用方案除了上面这些主流镜像源还有两个特殊但好用的备用方案第一个是Docker Proxy 类镜像加速。这类服务走的是代理转发模式不需要你本地安装任何额外组件直接配置 registry-mirrors 即可。有些加速地址会在 Docker Hub 官方封禁后自动切换回源路径所以在主用源失效的时候这类服务往往是临时的救命稻草。第二个是Cloudflare Workers 自建加速。这个属于进阶玩法利用 Cloudflare 的全球网络节点自建一个轻量的镜像代理。好处是完全自主可控不怕公共源跑路坏处是需要你有域名并且对 Workers 的免费额度要精打细算。我自己的测试环境用的就是这个方案高峰期拉镜像速度非常理想。不过说实话自建方案对大多数人来说有点重了。我建议优先用云厂商源 高校源的组合已经能覆盖 95% 以上的场景。3. 一步一步完成镜像源配置3.1 Linux 环境下的标准配置方法Docker 的镜像源配置写在/etc/docker/daemon.json里。如果这个文件不存在直接创建就好sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://mirror.ccs.tencentyun.com, https://docker.m.daocloud.io, https://hub-mirror.c.163.com ] } EOF配置完成之后重启 Docker 服务让配置生效sudo systemctl daemon-reload sudo systemctl restart docker重启完之后务必验证一下配置是否生效。这一步很多人会跳过但实际上非常关键docker info在输出内容里找到Registry Mirrors这一段如果能看到你刚才配置的地址列表就说明配置生效了Registry Mirrors: https://mirror.ccs.tencentyun.com/ https://docker.m.daocloud.io/3.2 Docker DesktopWindows 和 macOS的配置路径如果你用的是 Docker Desktop配置入口在图形界面里不在命令行里。打开 Docker Desktop 后进入Settings-Docker Engine然后把下面的 JSON 配置写进去{ registry-mirrors: [ https://mirror.ccs.tencentyun.com, https://docker.m.daocloud.io ] }点击Apply Restart按钮Docker Desktop 会自动重启并应用新配置。有个地方特别提醒Docker Desktop 在 Windows 上有两种运行模式——Windows 容器模式和 WSL2 后端模式。如果你用的是 WSL2现在绝大多数人都是那么除了在 Docker Desktop 界面里配置之外还需要进去 WSL 发行版里检查一下 Docker 客户端的配置。因为 WSL2 里的 Docker 引擎和 Docker Desktop 是独立管理的容易出现在界面上配好了但 WSL2 里拉镜像还是走官方源的情况。解决办法是进入你的 WSL 发行版重复一遍 Linux 环境下的配置流程然后重启 WSLwsl --shutdown重新打开 WSL 终端后再拉镜像测试速度。3.3 Docker 配置的核心参数解析顺手把daemon.json里几个和镜像拉取相关的参数一起说了因为这些参数往往是性能瓶颈的隐藏来源{ registry-mirrors: [https://mirror.ccs.tencentyun.com], max-concurrent-downloads: 10, max-download-attempts: 5 }max-concurrent-downloadsDocker 并发拉取镜像层的最大任务数默认值是 3。如果你经常拉取大镜像这个值调高到 10 会明显改善速度。原理很简单就像下载器多开几个线程分段下载一样多个层可以并行拉取。max-download-attempts拉取失败后的最大重试次数默认是 5。一般不用动但如果你网络环境不稳定可以适当调高。这两个参数不是镜像源本身但对拉取体验的影响丝毫不亚于换一个快的镜像源可以配合使用。4. 配置镜像源后仍然慢这 5 个坑我替你踩过了4.1 镜像源“看似可用”实际上已经失效这是我见过最多的情况。很多人在网上搜到一个镜像源地址也不测试就直接配置了结果拉取镜像时各种超时、卡住然后误以为是自己的 Docker 配置有问题。判断镜像源是否可用的最快方法是用curl测试它的响应头curl -I https://mirror.ccs.tencentyun.com/v2/如果返回的 HTTP 状态码是200或者401说明这个源在线。401是正常的因为访问 registry 需要 token 认证反而是403、502、504这些状态码才说明源可能有问题。注意上面的测试只验证了源是否在线不能验证它是否还能同步 Docker Hub 的最新镜像。有些年久失修的源虽然返回 200但内部缓存已经很久不更新了拉一个 tag 比较新的镜像时照样会回源超时。所以最靠谱的验证方式永远是用docker pull拉一个真实镜像测试。4.2 配置了多个镜像源但 Docker 只盯着第一个用这是另一个高频误区。Docker 的行为是依次尝试你配置的镜像源如果第一个源拉取失败才会回退到第二个源。它不会同时从多个源并行拉取。所以如果你把一个已经失效的源排在前面后面就算配了十个好用的源每次拉取时也会先卡在第一个源上超时然后才轮到后面的源。最终效果就是拉取速度不但没提升反而比不配还慢。我现在的做法是优先把最快最稳的源排在第一个失效源直接删掉不要留着当备用。宁可配置里只有一个可用源也不要塞一堆不确定状态的源进去。4.3 拉取镜像时报x509: certificate has expired or is not yet valid这个报错我在配置一些高校镜像源时遇到过比较典型。原因是某些镜像源的 TLS 证书过期了而你的 Docker 客户端严格校验证书因此拒绝连接。如果你确定这个源应该是可用的临时解决办法是给这个源单独配置跳过证书校验。但不建议在生产环境这么干因为会降低安全性。更好的方案是换一个源或者等镜像站维护证书后再用。另外还有一种情况你的系统时间不对。如果系统时间超前或落后太多也会导致证书校验失败。用date -R检查一下系统时间如果偏差过大先同步时间再测试sudo timedatectl set-ntp true4.4 私有镜像仓库的镜像拉取也走了加速器有些朋友配置了 registry-mirrors 之后发现从自己的私有仓库拉取镜像时变得很慢甚至拉不下来。原因也很简单registry-mirrors 是一个全局配置它会影响所有 registry 的访问包括你的私有仓库。解决办法是在拉取私有仓库镜像时显式指定完整地址例如docker pull registry.example.com/myimage:v1。这样 Docker 就会跳过镜像加速器直接访问私有仓库本身。如果你希望 Docker 对某些内网地址永远不走加速器可以在daemon.json里配置{ registry-mirrors: [https://mirror.ccs.tencentyun.com], insecure-registries: [registry.example.com] }insecure-registries主要是用于跳过证书校验但它也能让 Docker 在访问该地址时绕过 registry mirror 逻辑直接连接源仓库。4.5 Docker Hub 官方源完全无法访问时镜像源也救不了你最后要泼一盆冷水镜像加速器只是“加速”不是“替换”。当 Docker Hub 官方源本身出现大规模故障时镜像加速器也无法独善其身——因为加速器本质上也是从 Docker Hub 拉取镜像来缓存。这种情况下最有效的策略是等待恢复同时把临时需要的镜像提前保存到本地。我的习惯是在仓库服务器上单独搭一个轻量的私有 registry把常用基础镜像提前推上去。这样即使外部源全部失效内部环境依然可以正常拉取镜像。5. 除了 Docker这些常见工具也能用同样的思路加速5.1 GitHub 下载加速用镜像站解决 release 和仓库拉取慢作为开发者每天难免要从 GitHub 拉代码、下载 release 包。GitHub 的下载速度和 Docker Hub 有类似的痛点——源在国外默认走公网链路很慢。处理思路也类似借助公开的 GitHub 镜像加速服务。常见的方案是把 GitHub 下载链接的开头替换为镜像站地址前缀比如将https://github.com/user/repo/releases/download/...改成https://gh-proxy.com/https://github.com/user/repo/releases/download/...这类形式。另外git clone 慢的话可以在 SSH 配置或者git config层面调整git config --global http.postBuffer 524288000 git config --global http.lowSpeedLimit 0 git config --global http.lowSpeedTime 999999这样配置之后再 clone 大型仓库超时断流的概率会小很多。当然如果你能通过镜像站访问 GitHub效果会更直接。5.2 Ollama 模型下载慢同样可以配镜像源如果你本地跑 Ollama 拉模型经常卡住也可以配置类似镜像源的东西。Ollama 通过环境变量OLLAMA_HOST和模型仓库地址来管理下载源。目前社区常用的做法是将模型下载请求代理到国内可访问的模型镜像站。具体来说设置环境变量export OLLAMA_BASE_URLhttps://ollama镜像地址不同镜像站地址并不固定需要按当前可用的社区资源来填。个人的建议是如果你对 Ollama 模型下载速度不满意优先检查本地网络到对象存储的连通性然后根据社区推荐选择当前可用的镜像源。5.3 pip 和 conda 的国内镜像源这一点我觉得不需要多讲估计大多数 Python 开发者的 pip 早就配置了清华 PyPI 镜像。配置方法可以一并说明下pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simpleConda 用户则可以修改~/.condarc把channels指向清华源或中科大源。这里想强调的是pip/conda 镜像源和 Docker 镜像源有一个共性官方源在特定网络环境下都可以被更优的镜像源替代。所以如果你的工作中同时涉及容器、Python 依赖、GitHub 代码下载花点时间一次性把这些都配置好能节省大量碎片时间。6. 镜像源可用性速查与验证脚本6.1 一键验证多个镜像源是否可用配置镜像源最麻烦的地方在于你不知道哪一天某个源突然就不行了。我自己写了一个简单的验证脚本本质就是批量 curl 测试每个源的响应状态for mirror in \ https://mirror.ccs.tencentyun.com \ https://docker.m.daocloud.io \ https://hub-mirror.c.163.com \ https://docker.mirrors.ustc.edu.cn \ https://docker.mirror.sjtu.edu.cn \ https://docker.nju.edu.cn; do code$(curl -s -o /dev/null -w %{http_code} --connect-timeout 5 $mirror/v2/) echo $mirror - $code done输出结果大致长这样https://mirror.ccs.tencentyun.com - 401 https://docker.m.daocloud.io - 401 https://hub-mirror.c.163.com - 401 https://docker.mirrors.ustc.edu.cn - 000401代表在线且认证机制正常000代表连接失败或者超时可以直接将这个地址从配置中移除。6.2 我个人的镜像源配置推荐模板如果不想折腾直接抄我目前在用的一套配置就行。我给它取了个名字叫“双云一高校”组合覆盖了稳定性、速度和容灾{ registry-mirrors: [ https://mirror.ccs.tencentyun.com, https://docker.m.daocloud.io, https://docker.mirror.sjtu.edu.cn ], max-concurrent-downloads: 10 }这套组合我用了小半年整体拉取速度都能维持在较高水平。腾讯云源做主加速DaoCloud 移动源做备份上海交大的源作为教育网链路补充。三个源分别属于不同运营商和运营主体同时出问题的概率极低。7. 写在最后的几点长期建议镜像源这个事不能配一次就一劳永逸平时要有意识地维护一下。我大概每隔一两个月会跑一遍上面的验证脚本顺手删掉失效源替换成当前社区公认可用的新源。另外如果你是在公司环境里让运维统一在内部搭建一个 Docker registry 作为镜像缓存层才是最好的方案。这样团队所有人拉镜像走内网速度最快也最可控。个人开发者或小团队的话用公共镜像源完全够用不需要过度设计。从拉取慢如蜗牛到基本秒开差的只是这几个源的配置而已。希望这份列表和排查经验能帮你省下一些折腾的时间。