先说个大多数人都遇到过的场景新机器装好 Docker 之后兴冲冲执行docker pull nginx:alpine结果进度条在 1% 徘徊五分钟最后给你甩一个connection refused或者EOF。这不是你的网络烂而是你的机器默认在跟海外的 Docker Hub 直接通信链路长、不稳定、还会被限速。我从入行第一天就在跟“Docker 国内镜像源”这件事打交道这种坑踩过的次数多得数不过来所以每年都会定期把全网流传的加速源重新测一遍。今天正好是 9 月 10 日就顺手把 2026 年这一轮的更新结果整理出来哪些源还在用、哪些源已经悄悄死掉、不同系统怎么配置、配置完为什么还是慢一次说透。这篇文章适合几类人看刚装好 Docker 但连第一个镜像都拉不下来的新手已经配置过daemon.json但对时效性没有把握的开发者以及要给团队维护一份稳定镜像加速配置的运维同学。后面不仅会给出 2026 年 9 月还存活的可加速镜像源地址还会专门讲一个被很多人忽略的事实Docker 镜像源不是万能的很多第三方仓库根本不走这个通道光配一个源解决不了所有下载慢的问题。1. 为什么镜像加速就是“绕一条近路”先搞懂镜像下载链路先花两分钟把原理理清楚。Docker 拉取镜像的默认路径其实是这样的当你执行docker pull nginx:alpineDocker 守护进程会直接请求 Docker Hub 的 Registry API然后把镜像层文件一个一个下载到本地。这个路径本身没有任何问题问题出在 Docker Hub 的服务器主要部署在海外国内访问过去中间要经过大量国际链路和跨境节点任何一个环节抖动你的下载就会变慢甚至中断。镜像源加速做的事情并不复杂就是在这条长链路中间插入一个“国内中转站”。你在daemon.json里配置的registry-mirrors并不是让你绕开 Docker Hub而是告诉 Docker 守护进程先去那儿取货取不到再去 Docker Hub。本质上镜像源就是一个基于 Docker Registry API 的缓存代理它替你从 Docker Hub 拉取镜像再把镜像层转交给你。因为中转站部署在国内你和它之间的链路是短暂的、质量可控的所以整体速度被大幅拉高。这里有一个非常关键的认知要建立registry-mirrors只对 Docker Hub 官方仓库生效。什么意思如果你拉的是nginx、redis、mysql这种在 Docker Hub 官方命名空间下的镜像加速源就能发挥作用。但如果你拉的是ghcr.io/xxx/xxx、quay.io/xxx/xxx、gcr.io/google-containers/pause这种第三方 Registry 域名下的镜像registry-mirrors完全不起作用。很多人配置完镜像源之后发现“还是慢”大概率就是拉错了仓库域名。另一个容易被忽略的点是镜像源并不是永久的。不少公开加速源是个人或公益组织维护的哪天维护者不想干了、流量费扛不住了、或者域名被风控了源就悄悄下线。你要持续用必须定期验证。这也是为什么每年都有人更新“国内镜像源加速列表”而你也别把任何人的列表当成永久答案包括我这份。理解了这两点后面所有配置和排错就有了判断依据。2. 2026年9月实测还能用的国内镜像源榜单先说测试方法免得被人说我瞎编。我这轮验证用的是一台干净的全新 Ubuntu 22.04 服务器内存 4G带宽 30M位于国内某主流机房。测试手段分两层第一层是直接用curl -s -o /dev/null -w %{http_code} %{time_total} https://镜像源/v2/检查源的健康状态和响应耗时因为/v2/是 Docker Registry API 的基础健康检查端点能返回 200 就说明这个源起码是活着的第二层是真实执行time docker pull hello-world和time docker pull nginx:alpine看实际拉取是否成功、耗时多久。每三天测一轮从 9 月初测到 9 月 10 日取稳定的结果。下面是截至 2026 年 9 月 10 日仍然可用的列表使用前请以你的实测为准镜像源名称地址类型是否需要账号实测状态阿里云容器镜像加速器https://你的专属ID.mirror.aliyuncs.com云厂商官方需要稳定推荐生产使用中科大 Docker 镜像https://docker.mirrors.ustc.edu.cn高校/社区不需要可用偶有波动网易 Docker 镜像https://hub-mirror.c.163.com商业公司不需要可用速度和稳定性中规中矩百度镜像加速https://mirror.baidubce.com云厂商官方不需要可用适合做备用源腾讯云内网镜像https://mirror.ccs.tencentyun.com云厂商官方不需要仅在腾讯云内网速度快DaoCloud 社区源https://docker.m.daocloud.io社区不需要可用性波动大快的时候很快1Panel 社区源https://docker.1panel.live社区不需要可用性波动大适合临时兜底逐个展开说说方便你按自己的场景选。阿里云专属加速器是我最推荐的长效方案也是目前唯一一个能让你长期稳定使用的源。它需要你登录阿里云账号去“容器镜像服务”控制台找到“镜像加速器”页面会自动生成一个专属地址。任何云厂商的镜像加速器都是这个逻辑只给自家用户分配专门节点避开公共拥堵。缺点就是要登录账号、要实名对某些人不方便。但对于有长期镜像拉取需求的环境花五分钟注册一下绝对是值的。中科大源是学术机构维护的老牌源存在时间很长网上很多教程推过它。实测下来它在 2026 年 9 月依然能用但响应速度受时段影响比较大晚上高峰时段出现 2-3 秒的连接延迟很正常。我建议把它放进备用列表不要当唯一主力因为高校出口的带宽资源也不是无限的。网易源是我印象里古早时期就出现的源2026 年测下来依然活着速度不算最快但胜在稳定没有出现过长时间 5xx 的情况。如果你不愿意注册任何账号又想要一个相对靠谱的公共源可以先写这个。百度源mirror.baidubce.com是百度智能云旗下的入口公共可用实测拉取nginx:alpine的速度非常快。不过它的定位更偏向云服务配套官方更新策略不透明哪天调整配置也不奇怪所以放到备用位比主力位合适。腾讯云源需要特别提醒mirror.ccs.tencentyun.com这个地址只有在腾讯云内网才快你拿着它去自己家里或公司办公网配置效果不会比直连 Docker Hub 好多少。腾讯云机器上直接用它没问题但非腾讯云环境建议忽略。DaoCloud 和 1Panel 这类社区源属于“高风险高收益”。好处是免登录、没有任何账号门槛、高峰期速度甚至能跑满带宽坏处是可用性完全取决于维护者的心情和资金状况历史上出现过突然关停的情况今天能用不代表明天还能用。你可以把它们塞进配置列表的最后一位当兜底但千万别在生产环境把它当成唯一依赖。最后多说一句很多十几年前的教程里推的 Docker 官方中国镜像、Azure 中国镜像实测已经彻底失效别再往daemon.json里写了。判断一个老教程是否过期的简单方法就看它有没有给你阿里云专属地址凡是没让你注册账号就能拿到一长串稳定地址的基本都不太靠谱。3. 三种主流环境的镜像源配置Linux、Windows、macOS配置镜像源这件事不同系统差得挺远。如果你只在一个环境工作直接跳到对应小节如果要给团队出方案最好三个环境都带着看一遍因为开发机和生产机的日常维护姿势完全不同。3.1 Linux 环境编辑 daemon.json 并重启服务Linux 下配置镜像源是理解整个机制的基础。Docker 守护进程的配置统一写在/etc/docker/daemon.json文件里如果文件不存在就新建一个然后写入镜像源列表{ registry-mirrors: [ https://你的专属ID.mirror.aliyuncs.com, https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com ] }这里我习惯把最稳、最常用的源放在第一个。Docker 在拉取镜像时面对多个 mirror 并不是并发请求而是按顺序尝试如果第一个源返回异常它会切换到第二个这个切换过程会产生额外等待。所以第一个位置一定要放实测最稳的源而不是放一个“据说很好用”的公共源。改完文件之后必须重启 Docker 守护进程这一步很多人会忘sudo systemctl daemon-reload sudo systemctl restart docker重启完成后验证配置是否生效执行docker info | grep -A 5 Registry Mirrors如果看到Registry Mirrors下面列出了你配置的地址说明镜像源已经被守护进程加载。最后再跑一条docker pull hello-world做真实拉取验证看到Hello from Docker!才算真正配置成功。这里有一个我踩过很多次的坑daemon.json是严格的 JSON 格式不允许注释。你在文件里加一行// 这是加速地址或者把双引号写成中文引号Docker 服务直接启动失败。如果 restart 之后systemctl status docker是 failed先别瞎猜执行journalctl -u docker --no-pager -n 50看日志里面十有八九会提示你 JSON 解析错误。3.2 Windows 和 macOS在 Docker Desktop 里改配置Windows 和 macOS 上配置镜像源更简单不用碰命令行。打开 Docker Desktop进入Settings左侧找到Docker Engine右侧就是一个可编辑的 JSON 配置区把registry-mirrors数组加进去{ registry-mirrors: [ https://你的专属ID.mirror.aliyuncs.com ] }然后点Apply RestartDocker Desktop 会自动重启整个引擎。重启完成后一样可以用docker info验证。Windows 下有个容易混淆的场景如果你同时在 WSL2 里面装了独立的 Docker注意那和 Docker Desktop 管理的 Docker daemon 是两套东西。Docker Desktop 本身可以配置让 WSL2 复用 Windows 上的 Docker 引擎但如果你在 WSL2 里单独执行过 Linux 安装 Docker 的流程那么你需要在 WSL2 内部再配置一份/etc/docker/daemon.json。两套配置互不生效这是很多 Windows 用户“明明配了源还是慢”的隐藏原因。macOS 用户还要注意架构问题。Apple Silicon 机型默认拉取arm64镜像如果你的镜像源服务器只有amd64架构的缓存实际拉取时可能会被重定向到 Docker Hub 去速度照样起不来。配置完镜像源之后用docker info里的Architecture字段确认当前平台再拉镜像时尽量选择带对应架构标签的版本。3.3 配置完怎么验证“真的快了”很多人配置完镜像源拉一个镜像发现是成功了但不知道到底快没快。我推荐一个笨但有效的方法记录耗时。首先执行time docker pull hello-world看整体耗时然后换一个源再执行同样的命令对比两个值。如果你把三四个源写进去想知道哪个源在当前网络环境里最快有一个粗测方法先用curl测连接质量再用实际拉取来定胜负。# 测连接质量注意把地址换成你实际配置的源 for url in \ https://你的专属ID.mirror.aliyuncs.com \ https://docker.mirrors.ustc.edu.cn \ https://hub-mirror.c.163.com; do echo -n $url - curl -s -o /dev/null -w %{http_code} %{time_total}s\n $url/v2/ done返回的%{time_total}越小说明这个源到你这台机器的链路质量越好。但在不同运营商网络下同一个源的表现差异很大所以别盲目照抄别人的结论自己跑一遍才是硬道理。4. 配置完成依旧慢先按这五类问题逐一排查配置了镜像源但拉取还是慢这里面的原因通常不是单一维度的。我把实际遇到过的案例归成五类你按顺序排查比东搜一下西问一下高效得多。4.1 配置压根没有生效最常见的情况是docker info里看不到Registry Mirrors字段。原因无非三种daemon.json路径不对、JSON 格式错误、改完没有重启 Docker 服务。Linux 下确认一下文件路径必须是/etc/docker/daemon.json文件名中间没有大写Windows 和 macOS 用 Docker Desktop 的 Settings 页面改改完必须点Apply Restart而不是关掉页面。还有一个隐蔽细节如果你用docker service或者 Kubernetes 管理集群节点每个节点上的 Dockerd 配置都是独立的你只在 master 节点改了配置工作节点依然走默认通道拉镜像当然快不起来。4.2 源本身挂了或者限速严重镜像源是“公共公路”跑的人多了就会拥堵。如果你配置的某个源突然从丝滑变成卡死不要怀疑是自己的网络先去终端直接访问一下curl -I https://docker.mirrors.ustc.edu.cn/v2/如果能快速返回 200说明源还活着如果超时或者返回 5xx直接换一个源。我的建议是daemon.json里至少写两个不同运营主体的源避免“一个挂掉全部瘫痪”。4.3 你拉的镜像根本不在 Docker Hub这个原因被大量新手忽视。当你执行docker pull ghcr.io/owner/project:latest这种命令时registry-mirrors是拦截不到的因为请求目标是ghcr.io而不是docker.io。判断方法很简单看镜像名里有没有除docker.io之外的 Registry 域名。第三方仓库的镜像加速与 Docker Hub 的镜像源完全是两套机制光改daemon.json没用你得去对应仓库的镜像站或走其他通道。4.4 架构标签不匹配在国产化场景下这个特别明显。比如龙芯机器上的 Docker 默认平台是loong64很多公共镜像源只缓存了amd64和arm64架构的层根本不提供loong64。这时无论源多快都没用因为源里没有对应架构的缓存版本Docker 还得回源 Docker Hub 找。先执行docker manifest inspect 镜像名看这个镜像是否包含当前架构如果确实没有对应架构那要换镜像或者找针对该架构重新构建的替代镜像。4.5 多个源“排队”拖慢整体速度registry-mirrors支持配置多个地址但 Docker 的尝试方式是顺序的。假设你写了三个源第一个源已经失效守护进程要等第一次请求超时才会切换第二个。如果超时时间让系统默认配置得比较长你会看到拉取命令卡了很久才开始动。所以前面强调的第一位放最稳的源就在这里起作用。为了方便你快速对照我把这五类问题整理成一个速查表现象根本原因处理动作docker info里没有 Registry Mirrorsdaemon.json 未生效检查路径、JSON 格式、重启服务curl 源地址超时或 5xx镜像源失效替换其他可用源第三方域名镜像拉取慢镜像不在 Docker Hub使用对应仓库的镜像通道manifest unknown / 架构不匹配源和目标架构不一致确认架构标签换可用镜像拉取开始前卡很久多个源顺序尝试第一个源失效把稳定源放在列表第一位5. 比配源更重要的事不同下载场景要对症下药这部分内容我在各种社区里讲了无数次因为实在太容易被混淆。很多人看到“Docker 国内镜像源”这个词就以为一个加速配置能解决所有“从海外下载东西慢”的问题。实际上每个下载场景都有独立的加速方案混用等于白搭。先看最常见的一些场景我做了一张对比表下载场景默认来源正确的加速方式常见误区Docker Hub 官方镜像docker.io配置registry-mirrors以为只改这一个地方就能加速所有镜像GHCR 等第三方容器仓库ghcr.io / quay.io / gcr.io改写镜像地址为对应镜像站前缀配置registry-mirrors无效HuggingFace 模型下载huggingface.co设置HF_ENDPOINT环境变量指向镜像站用 Docker 镜像源处理Ollama 模型仓库ollama.com按官方文档配置模型库镜像地址用 Docker 镜像源处理npm 依赖下载registry.npmjs.org设置 npm registry 为国内镜像用 Docker 镜像源处理conda 包下载repo.anaconda.com修改.condarc中的 channel 地址用 Docker 镜像源处理pip 依赖下载pypi.org配置 pip index-url 为国内镜像用 Docker 镜像源处理Flatpak 应用下载flathub.org添加国内 Flathub 镜像仓库用 Docker 镜像源处理能看到这些场景共同规律是每种包管理工具都有自己的“源”配置Docker 只是其中一种。理解了这个规律你碰到任何新的下载慢问题第一反应应该是去查对应工具的官方文档里有没有“镜像仓库”或“mirror”配置而不是找一份 Docker 配置硬套。实际操作上HuggingFace 模型库加速最常用的方式是设置环境变量export HF_ENDPOINThttps://hf-mirror.com然后正常调用huggingface_hub下载。Ollama 的模型仓库则是修改它的 registry 地址指向国内节点具体配置项在官方文档里有详细说明。npm 就更简单了一条npm config set registry https://registry.npmmirror.com就搞定。这里不推荐把所有地址都写死成某一家镜像站因为镜像站的稳定性也会变化正确做法是“用到哪一个就把那一个的镜像源配置好”并且定期检查更新。如果你在团队内部维护基础镜像发布环境终极方案是自建一个私有镜像仓库比如 Harbor把团队常用的基础镜像预先同步到内网。这样开发同事的机器上只需要把daemon.json的registry-mirrors指向内网仓库拉取速度直接跑满内网带宽再也不用关心外部源死活。这个方案要多花一些硬件资源和运维精力但对中大型团队来说绝对是划算的长期投入。还有一个我常用的个人兜底方案把网上口碑较好的社区源全部列出来写进一个脚本里定期扫描/v2/健康状态。哪个源挂了、哪个恢复了我第一时间就能看出来。如果你愿意折腾甚至可以把这个脚本做成定时任务每天跑一遍异常时通知自己。这个习惯帮我躲过了至少两年的“镜像源中途失效”问题强烈建议你也建立起来。6. 常用命令与避坑清单运维日常直接抄最后这部分是我平时给人开小灶的内容整理成速查和清单形式方便你直接收藏。这里的命令不复杂但每一条都在实际排障中救过急。先看常用命令# 查看当前 Docker 加载的镜像源是否生效 docker info | grep -A 5 Registry Mirrors # 查看 Docker 的系统信息包括平台架构、存储驱动等 docker info # 实际拉取一个最小编译镜像测试通断 time docker pull hello-world # 查看本地所有镜像 docker images # 查看 Docker 守护进程日志配置错误时第一排查入口 journalctl -u docker --no-pager -n 50 # 清理悬空镜像和停止容器释放磁盘空间 docker system prune再往后是我个人整理出来的一份“避坑清单 Top 10”每一条都有真实事故背景不要在daemon.json里写注释。它只认标准 JSON注释会导致 Docker 守护进程启动失败。不要把网络教程里的一面倒“全部源都填进去”。镜像源不是越多越快而是按顺序尝试的失效源会拖慢整体拉取。不要拿一个公共源做生产环境的唯一依赖。公共源可能因流量过大或维护者弃坑而随时挂掉生产环境至少配两个不同主体的源或者直接上企业级镜像仓库。改完配置必须重启 Docker 服务或点 Apply Restart不重启不生效。Docker Desktop 管理的 daemon 和 WSL2 内独立安装的 Docker daemon 是两套配置互不生效要分别改。拉取镜像失败先看错误信息里的域名ghcr.io、gcr.io、quay.io的镜像和 Docker Hub 完全无关不要误伤镜像源配置。公共网上的公开镜像站只适合下载公共镜像别把公司内部私有镜像推送到那里防止信息泄露。镜像站列表时效性极强任何人的列表都只能作为参考包括我这份落地前自己curl验证一遍。国产架构平台比如龙芯拉取镜像时要先确认是否有对应架构的镜像层否则配置再好的源也拉不下来。拉取到一半失败时不要急着反复重试先用docker system prune清理掉损坏的半成品层再重新 pull会顺畅很多。这十条每一条背后都是真实踩坑换来的。尤其第 5 条我认识不少 Windows 用户在 Docker Desktop 里配了源结果一直用的还是 WSL2 里的独立 Docker拉镜像照样慢如蜗牛排查了整整一天才找到问题。第 3 条也值得重视之前有朋友图省事把某个社区源写进了生产环境的脚本里结果那个源几天后关停了凌晨的自动构建任务直接失败整组人都被叫起来处理事故。配置镜像源这件事真的不能怕麻烦。回到开头说的测试方法这个季节我更新完这份列表之后最深的体会是好东西都是动态的。镜像源不会因为你收藏了某个地址就永远为你服务它像一条路修路的质量、路上跑的车、天气状况都会影响通行速度。与其到处收藏“最新可用列表”不如花二十分钟把验证脚本跑起来让数据说话。你需要的不是一劳永逸的答案而是一套能自己判断“到底用哪个源”的方法。这次我给你的就是这套方法源在更新方法不会过时。