先说结论今天2026年9月8日我把手头几台服务器、测试机以及新装的Docker Desktop环境从头到尾重新拉了一遍镜像把当前还能稳定工作的Docker国内镜像源整理成了一份列表。这篇文章不只有地址还会把配置方法、验证方式、失效判断和排查思路一起写清楚方便你直接照着做不用再一篇篇试教程。很长一段时间里Docker pull慢已经不是个例问题。无论你是Windows上装了Docker Desktop还是Linux服务器上用命令行拉镜像只要默认走Docker Hub大概率会经历几KB每秒的速率、反复超时的连接、拉到一半断流的“经典三连”。尤其是换新机器、部署测试环境、跑docker-compose的时候镜像拉不下来直接卡住整个流程非常折磨人。这篇博文适合所有和Docker打交道的人刚入门的小白照着配置就能提速老手也可以对照我踩过的坑做一次自查顺便把Ollama、Conda这些周边工具的源一起优化掉。我尽量不堆术语遇到原理部分用大白话拆开讲拿过来就能用。1. 列出镜像源之前先搞懂三个现状网络上有太多文章上来就甩给你一堆地址但没过多久就失效了。所以在给列表之前我觉得有必要先说清楚三件事这些是理解后面所有配置和排查的基础。1.1 Docker Hub 为什么在国内下载这么费劲Docker Hub的镜像文件存放在海外服务器上国内访问时要经过漫长的跨海链路。这就像你从外地寄快递包裹每经过一个中转站就有可能多一分延迟和丢失风险而这条链路偏偏又不稳定于是大镜像经常传一半断掉小镜像也要磨蹭很久。这里说的“慢”不只是带宽问题还有连接被重置、TLS握手超时、DNS解析异常等多种情况。很多新手以为是Docker没装好重装好几遍都没有用实际上问题出在默认的下载通道上。1.2 “镜像加速”和“换源”不是一回事我经常看到有人把“换源”和“镜像加速”混为一谈导致配置了半天镜像还是拉不下来。换源的意思是你主动把镜像地址改成一个国内的仓库地址比如拉取某个云厂商提供的公共镜像时镜像名要带上一长串前缀。这种方式对于你明确知道“某个镜像在某个仓库里”的场景是适用的但日常使用中非常麻烦因为Docker Hub上的镜像成千上万你不可能给每个镜像都找国内替代品。镜像加速则是另一种思路。它需要在Docker引擎层面配置registry mirror注册表镜像配置好之后当你执行docker pull nginx:latest时Docker不会直接去找Docker Hub而是先去你配置的加速地址找缓存。如果加速站有这份镜像它直接返回给你如果没有加速站会替你去Docker Hub拉取后再返回。整个过程里你写的命令不用变镜像名也不用加前缀体验上最接近“透明加速”。绝大多数场景下配置registry mirror是优先方案这也是本文的核心。1.3 为什么这类文章总在“月月更新”海外镜像加速这事从来不是一劳永逸的。维护一个公共镜像站需要不小的带宽和存储成本有些站点做了几年关停了有些站点因为政策或流量原因调整了访问策略还有一些站点地址变了但旧地址仍然能被解析配置进去之后超时。所以你会发现Docker镜像源文章都有很强的时效性。标题里标注“9月8日更新”就是在告诉你这份列表的可用状态以今天为基准过几个月再看不一定仍然成立。这可能有点残酷但确实是这类话题的常态。理解了这一点你就明白为什么不能背下一串地址就永远用一辈子而是要学会验证和排查的方法。2. registry mirror 的工作原理一条 pull 命令背后的链路配置镜像加速之前非常建议先花两分钟理解它背后的机制。这样遇到问题的时候你才知道是哪一环出了故障而不是在那里瞎试。2.1 配置一个 mirror 会发生什么当你执行docker pull nginx:latest时Docker daemon会按照配置的优先级顺序访问镜像仓库。默认情况下它直接访问Docker Hub官方仓库。当你配置了registry mirror之后daemon会先去mirror地址查找。整个过程可以这样理解Docker收到你的pull命令发现镜像名里没有指定私有仓库地址于是把它当作docker.io/library/nginx:latest处理。Docker daemon查看daemon.json里的registry-mirrors列表把请求转发给排在第一个的mirror。mirror收到请求后如果本地缓存里有nginx:latest直接把数据流返回给daemon。如果mirror没有缓存它会回源到Docker Hub拉取存一份在自己的存储里同时返回给你。如果第一个mirror连不上或者超时Docker会自动尝试下一个mirror。这种“拉取即缓存”的模式意味着越多人用某个镜像源热门镜像的缓存命中率越高你的拉取速度就越快。这也是为什么一些社区维护的公共镜像站对热门镜像的加速效果特别明显。2.2 为什么有些镜像源拉取“时好时坏”很多用户反馈说某个镜像源“昨天还好好的今天突然不行了”这不是错觉。公共镜像源的稳定性受到很多因素影响。首先是流量高峰。白天是使用高峰期大量用户同时向镜像站发起请求分流到每个连接上的带宽自然就少了表现就是速度慢、超时率高。深夜时段访问量下降速度又会恢复。其次是缓存策略差异。有些镜像源只缓存热门镜像冷门镜像每次都要回源到Docker Hub回源速度慢的话整个拉取过程就被拖住了。还有一个容易忽略的点不同运营商到同一个镜像源的网络路径差异。电信、联通、移动三家网络到达同一节点的路由不一定相同可能你在电信网络下访问很快换了移动网络就超时。我自己的经验是多配几个镜像源做兜底比迷信某一个“神级地址”要靠谱得多。2.3 多源兜底与优先级Docker允许在registry-mirrors里配置多个地址这一点非常实用。请求会按顺序尝试第一个挂了自动换下一个。所以我的建议是配置三个左右比较合理一个稳定性最好的放第一位一个社区公益的放第二位再放一个云厂商的兜底。配太多反而有害。每个mirror之间切换需要等待连接超时如果一个源没响应可能要等几十秒才会跳到下一个你会在终端里看着进度条一动不动非常难受。三个是最佳平衡点既保证有冗余又不会因为无效等待把时间浪费掉。3. 2026年9月实测仍在服务的镜像加速列表下面这份列表是我今天在个人电脑、云服务器和测试环境里实际验证过的包含公共加速地址和云厂商专属加速地址。需要说明的是我的网络环境不能代表所有人的网络环境所以我把实测情况和我推荐的优先级一起列出来方便你根据自己的场景选择。3.1 免费公共加速地址这里直接给结论然后说注意点。提供方加速地址今日实测状态说明DaoCloudhttps://docker.m.daocloud.io可正常拉取社区公益维护热门镜像缓存好目前比较稳百度智能云https://mirror.baidubce.com可正常拉取云厂商提供公网可以访问速度比较稳定腾讯云https://mirror.ccs.tencentyun.com腾讯云内网推荐外网环境有时超时在腾讯云服务器上用很好网易https://hub-mirror.c.163.com时好时坏老的镜像站负载较高不推荐做首选中科大https://docker.mirrors.ustc.edu.cn已不可用已经停止对外提供加速还在用这个地址的可以删掉了阿里云https://你的ID.mirror.aliyuncs.com需要注册后使用专属加速地址稳定性很好推荐首选这里我只列出我自己今天实测可用的。像中科大这种已经停止服务的我专门列出来是想提醒你如果你之前的配置文件里还有这个地址别怀疑自己操作有误就是站点本身关了把它移除即可。3.2 云厂商专属加速地址阿里云的加速地址和其他几个不一样它是个性化的。你需要登录阿里云容器镜像服务控制台在“镜像加速器”页面里找到属于你自己账号的加速地址一般是https://xxxx.mirror.aliyuncs.com这种格式。这个地址是每个用户专属的不能直接用别人的。为什么我把它列为推荐首选因为阿里云做了很多年的容器镜像服务节点覆盖广带宽有保障而且专属地址意味着使用的人相对分散不会被公共流量挤爆。缺点就是需要注册账号多一步操作而已。腾讯云的内网加速地址https://mirror.ccs.tencentyun.com则比较特殊。它在腾讯云服务器内网环境里访问速度非常快因为走的是内网链路不占公网带宽。但是如果你在自己家里的电脑上配这个地址大概率是超时的。所以它更适合云上环境使用不适合个人电脑。3.3 我的选型建议和排序逻辑如果你用的是云服务器我建议这样配第一顺位腾讯云内网地址如果服务器在腾讯云或阿里云专属地址如果注册了阿里云。第二顺位DaoCloud公共加速地址。第三顺位百度智能云地址。如果你用的是个人电脑的Docker Desktop我建议第一顺位阿里云专属加速地址。第二顺位DaoCloud公共加速地址。第三顺位百度智能云地址。这套排序逻辑很简单专属地址稳定性最高放第一位公共公益地址热门镜像命中率高放第二位另一个云厂商地址兜底放第三位。优先级高的在前面Docker会按顺序尝试所以把你觉得最靠谱的放在最上面。4. Docker Desktop、Linux 与 containerd 三种配置实战配置镜像加速的方式取决于你的使用环境主流的无非是Docker DesktopWindows/macOS、Linux下直接改daemon.json以及需要跑Kubernetes时涉及的containerd。我一个个说附上可以直接套用的配置。4.1 Docker Desktop 配置Windows / macOS打开Docker Desktop进入Settings - Docker Engine你会看到一段JSON格式的配置文本。把registry-mirrors加进去整体是这样{ registry-mirrors: [ https://你的ID.mirror.aliyuncs.com, https://docker.m.daocloud.io, https://mirror.baidubce.com ] }点击Apply Restart等Docker重启完成就生效了。这种方式的本质是修改Docker Desktop内置的daemon.json不需要你去命令行里操作。需要注意的是Windows用户如果遇到Docker Desktop无法启动提示virtualization support not detected或failed to start because virtualisation support wasnt detected这跟镜像源无关是你机器没有开启虚拟化功能。解决方法是进BIOS开启Intel VT-x或AMD-V然后在Windows功能里启用“适用于Linux的Windows子系统”和“虚拟机平台”再重启电脑。这个问题经常被人误以为是Docker配置坏了实际上差得很远。4.2 Linux 修改 daemon.jsonLinux环境下直接修改Docker daemon的配置文件。先看文件是否存在sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://你的ID.mirror.aliyuncs.com, https://docker.m.daocloud.io, https://mirror.baidubce.com ] } EOF然后重启Docker服务sudo systemctl daemon-reload sudo systemctl restart docker这里有一个很常见的低级错误daemon.json文件格式必须是严格的JSON很多人手动编辑的时候在最后一个大括号前面多加了一个逗号导致整个文件解析失败Docker服务起不来。报错信息通常是unable to configure the Docker daemon with file /etc/docker/daemon.json: invalid character } looking for beginning of object key string。看到这个提示先检查JSON格式别急着重装。4.3 containerd 与 Kubernetes 环境怎么配如果你用的是Kubernetes集群底层容器运行时是containerd那改Docker的daemon.json是没用的因为K8s不直接调用Docker。需要改containerd的配置文件/etc/containerd/config.toml。在[plugins.io.containerd.grpc.v1.cri.registry]部分加入mirrors配置[plugins.io.containerd.grpc.v1.cri.registry.mirrors] [plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [ https://你的ID.mirror.aliyuncs.com, https://docker.m.daocloud.io, https://mirror.baidubce.com ]然后重启containerdsudo systemctl restart containerd这里的关键是配置层级要正确路径写错一个字就加载不了。改完配置文件以后最好用containerd config dump检查一下实际加载的配置里有没有你写的endpoint避免改了个寂寞。4.4 配置后的正确验证姿势配置完成之后先不要急着拉大镜像测试那样太浪费时间。先看Docker是否识别到你的镜像源配置docker info在输出结果里找到Registry Mirrors这一项如果列出了你配置的地址说明Docker已经加载。然后拉一个小镜像做连通性测试docker pull alpine:latestalpine镜像只有几兆拉取速度可以直观反映加速效果。如果秒下完说明加速源正常工作如果卡住不动继续看后面第五节的内容。还可以用curl直接测镜像源的连通性curl -I https://docker.m.daocloud.io/v2/返回200 OK说明站点活着返回超时或连接失败说明这个源当前不可用可以检查网络或者换一个。5. 镜像拉不下来了从排查到收尾的完整手记即使配置了镜像源也难免遇到拉取失败的情况。这一节我把自己排查这类问题时的完整思路写出来你按这个顺序检查大概率能快速定位到问题。5.1 我看报错的第一眼timeout、EOF、TLS 分别代表什么报错关键词大致含义优先排查方向net/http: TLS handshake timeoutTLS握手超时连接被卡在建立阶段网络链路问题镜像源不可达或本地网络存在干扰dial tcp ... i/o timeout连接超时TCP层就没连上检查网络连通性镜像源域名解析是否正常EOF连接被服务端重置镜像源负载过高或被限流换个时间再试manifest unknown镜像标签不存在确认你写的tag是否正确不是加速问题no space left on device磁盘空间不足清理Docker缓存和旧镜像不是加速问题我最早遇到TLS handshake timeout的时候第一反应是加速源坏了换了好几个地址问题依旧后来发现是本地网络对海外节点的连接被干扰导致的。这种时候换哪个源都没用因为问题出在出口网络层面不是镜像源本身。5.2 判断一个镜像源是否失效如果你怀疑某个镜像源挂了不一定要真的去拉一个几GB的大镜像来验证。更高效的方式是直接请求它的API接口看有没有响应curl -I --connect-timeout 5 https://docker.m.daocloud.io/v2/ curl -I --connect-timeout 5 https://mirror.baidubce.com/v2//v2/是Docker Registry API的版本探测端点服务正常时返回200不可用时通常表现为超时、403或502。每个加速站返回的状态码可能不一样但只要能在几秒内给响应说明服务端还活着。还有一种情况是加速站本身活着但它回源Docker Hub的能力变差了。这种问题从外部很难判断只能实际拉一次镜像看看是秒下还是卡住。我的习惯是拉alpine:latest作为测试探针又快又准。5.3 验证过的“真相”有些加速站其实不支持直接拼镜像名网上很多教程会教你这样拉镜像docker pull docker.m.daocloud.io/library/nginx:latest意思是把加速站地址直接拼在镜像名前面。这种方法在某些站点是可行的因为部分镜像站本身就充当了一个Registry可以接受这种拉取方式。但有些加速站不支持这样直接拼地址拉取时反而报错。这就引出一个重要的经验你把加速站配置成registry mirror它才能稳定发挥作用手动拼镜像名的方式依赖每个站点自己的实现不可控因素多。所以平时使用无需改镜像名直接拉docker pull nginx:latest让Docker引擎自动走镜像源就好。不需要多此一举。5.4 兜底方案实在拉不动怎么处理有时候所有镜像源都不好用这时候有几个兜底办法。第一个办法是重试。网络抖动是常态Docker断点续传的能力有限但重试几次往往能拉完。写个小循环手工操作也行我用过的土办法是for i in 1 2 3 4 5; do docker pull nginx:latest break || sleep 5; done第二个办法是在带宽条件好的机器上拉取然后导出再导入。你在公司或朋友的服务器上拉好镜像用docker save打包成tar文件拷贝到目标机器后执行docker load。这个办法对大镜像很有用绕过所有网络问题。第三个办法是优化镜像体积。很多镜像拉不动是因为体积太大自己写的Dockerfile尽量用alpine基础镜像多阶段构建时只拷贝最终产物这样镜像体积可以缩小一大半拉取自然就轻松了。6. 顺带把 Ollama 和 Conda 的国内源也一起换掉既然都折腾到Docker镜像源这一步了我建议把相关度最高的几个工具也一起优化掉不然你会在接下来几天里重复踩同样的坑。6.1 Ollama 拉模型慢的解决思路Ollama 默认从registry.ollama.ai下载模型文件这个地址在国内访问很慢尤其是几个G甚至几十个G的大模型经常拉到一半就断了。最直接的解决方案不是去给Ollama配置什么隐藏参数而是换个思路从国内合规的大模型社区下载权重文件再导入到Ollama里。以魔搭社区ModelScope为例很多Ollama支持的开源模型如Qwen系列、Llama系列都能在上面找到对应的GGUF格式权重。下载速度快不断流然后通过Ollama的Modelfile把本地权重导入效果和直接拉取几乎一样。如果你的Ollama是通过Docker容器方式部署的那么先把Docker镜像源配置好至少ollama这个镜像本身不会卡在拉取环节。6.2 Conda 换源顺便解决 Python 解释器和包下载问题conda 默认走官方源慢是必然的。换国内源后下载速度和稳定性都会明显改善。直接在命令行执行conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ conda config --set show_channel_urls yes或者编辑~/.condarc文件写入channels: - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ - conda-forge show_channel_urls: true同理Python的pip源也可以一并换掉全球性的包下载速度问题都能用国内镜像解决。这样整条开发链路里Docker镜像、模型文件、Python包这三座“下载大山”全部搞定了。6.3 我的一个长期习惯这几年我在新环境上不停重复配置这些源后来干脆把daemon.json、conda源配置、pip源配置写进了一个初始化脚本。每次开新机器跑一遍脚本几分钟内就把这些下载相关问题全部解决再也不逐个踩坑。这个习惯帮我在搭建测试环境、给同事装开发机的时候省下了大量时间。今天这篇列表也是我日常维护这个初始化脚本的产物之一。上面这些配置和排查方法我每换一次环境都会用一遍验证通过后才敢写出来。你可以照着一套配完试试大概率不用再回到那个拉镜像拉到手抖的状态了。