很多人在用 Docker 时第一个拦路虎往往不是语法而是docker pull永远卡在下载阶段。Docker Hub 官方仓库本身没有问题但从国内网络环境访问它经常是几十 KB/s 的龟速甚至直接超时报context deadline exceeded。这篇博文是 2026 年 9 月 13 日更新的一版 Docker 国内镜像源加速列表我会把截至今天实际验证过还能用的加速地址整理出来同时把配置原理、验证方法和排障思路一起讲清楚。你不仅能填一个daemon.json还能自己判断某个镜像源到底能不能用。无论你是刚入门 Docker 的新手还是被生产环境拉镜像折磨过的运维这份列表和操作方法都可以直接参考。镜像源有很强的时效性今天能用的地址也许明天就失效所以我会把“怎么验证”放在“抄什么地址”前面避免你照着一篇旧列表操作配置完发现还是不行。1. 为什么 Docker 镜像下载这么慢1.1 慢在 Docker Hub 的链路而不是 Docker 本身很多人第一次遇到 Docker 拉镜像失败第一反应是“Docker 是不是坏掉了”。其实 Docker 客户端本身一点问题都没有瓶颈基本都出在 Docker Hub 这个官方公共仓库上。Docker Hub 的节点和 CDN 主要部署在海外国内访问时链路易受国际出口带宽、跨运营商调度等因素影响表现就是连接不稳定、丢包重传、速度忽高忽低。常见症状有三个一是docker pull刚开始还能跑出几百 KB/s过几秒直接卡住不动二是反复出现retrying三是等了几分钟后提示net/http: request canceled while waiting for connection。可以把 Docker Hub 想象成一个服务器在海外的大型下载站。你在国内直连它每次请求都要经过长距离链路转发任何一个环节拥塞整个下载就停了。这和国内云厂商的镜像仓库相比体验差距非常明显。1.2 镜像加速器到底在加速什么镜像加速器registry mirror本质上是一个针对 Docker Hub 的缓存代理服务。Docker 守护进程启动时会读取/etc/docker/daemon.json里的registry-mirrors列表当你执行docker pull时守护进程会优先请求这个列表里的镜像源而不是直接访问 Docker Hub。镜像源的处理逻辑是这样的如果你要拉的镜像它已经有缓存直接从缓存返回如果没有缓存它替你回源到 Docker Hub 拉取一次拉完保存在本地缓存里后续再有相同请求就直接命中。所以热门镜像比如nginx、redis、mysql、busybox在靠谱的加速器上命中率很高拉起来特别快。需要明确一点镜像加速器不是在网络层面做转发它解决的是“Docker 镜像仓库访问链路”的问题。配置好之后Docker 本身、容器运行、Compose 编排这些都不受影响只是拉取镜像的通道换了。1.3 为什么这份列表更新这么频繁你现在随便在网上搜“Docker 国内镜像源”能搜出一堆列表但实际去验证大概率会有三分之一已经失效。这不是标题党的问题而是镜像源这种东西天然不稳定。高校和社区维护的公共源带宽有限访问量一大就可能扛不住有的会直接限制外部访问有的会因为合规或运营成本暂停服务。云厂商提供的加速器相对稳定但很多需要注册账户并绑定专属地址没办法做成一个所有人通用的公共 URL。再加上电信、联通、移动不同运营商以及家庭宽带、公司内网、云服务器不同网络环境同一个镜像源在不同人手里的表现可能天差地别。结论很简单不存在一份“永久有效”的镜像源列表。我每过一段时间就会重新跑一遍验证脚本把失效的源从配置里踢出去。这也是我在这篇文章里反复强调验证方法的原因。2. 2026 年 9 月实测参考国内镜像源加速列表2.1 主力加速源公共云厂商与可靠第三方以下地址是我这次梳理时优先推荐的一档稳定性相对较好。注意“相对”两个字实际能不能用还是建议你在自己网络环境下验证一遍。类别名称加速地址说明主力DaoCloud 公共加速器https://docker.m.daocloud.io公共开放无需注册历史可用性表现较好主力阿里云容器镜像服务个人加速器https://你的专属ID.mirror.aliyuncs.com需要登录阿里云控制台获取专属地址稳定性最好备选腾讯云内网加速器https://mirror.ccs.tencentyun.com腾讯云服务器内网环境效果好公网环境下表现一般阿里云那个地址要单独说明一下登录阿里云容器镜像服务控制台找到“镜像加速器”页面里面会给你分配一个形如xxxx.mirror.aliyuncs.com的专属地址。填到daemon.json之前把你的专属ID换成你自己的前缀即可。DaoCloud 这个源在公共源里属于比较能打的。它不需要注册配置完直接能用我在多个网络环境下测试响应时间都还算稳定。如果你的场景只是个人开发、学习把它放在第一位基本够用。2.2 备选加速源高校与老牌公共源第二档是老牌公共源特点是资历老、口碑好但速度不一定稳定适合作为第二顺位或者应急备用。类别名称加速地址说明备选网易镜像https://hub-mirror.c.163.com老牌公共源速度看网络情况备选百度镜像https://mirror.baidubce.com偶尔可用建议备用备选上海交大 SJTUGhttps://docker.mirrors.sjtug.sjtu.edu.cn高校源网络条件好的时候速度快高校源有个特点带宽有限高峰时段可能变慢但胜在相对干净没有太多商业化诉求。网易这个源我用了很多年虽然有时候速度一般但胜在稳定很少出现彻底挂掉的情况。如果你的主力源突然抽风把第二顺位切换成高校源往往能临时救急。但我不建议把它们作为唯一依赖毕竟高校网络的运营策略随时可能调整。2.3 社区第三方加速源能快但不建议迷信除了上面这些网上还流传着一批社区维护的第三方加速地址比如docker.1ms.run、docker.1panel.live、docker.xuanyuan.me这类。这类源的特点是有时候速度飞快有时候突然无法访问生命周期可能只有几个月甚至几周。我自己的态度是个人开发环境可以尝试但不要过度依赖更不要直接用于生产环境。第三方加速器完全不受你控制你无法知道维护者的运营意图也无法保证服务长期存在。今天测试还能用明天可能就 502。更关键的是安全性问题。镜像加速器相当于 Docker Hub 和你之间的一层中间节点如果它返回篡改过的镜像内容普通拉取流程不一定能立刻发现。这个风险我在后面第 4.4 节展开讲。2.4 被我移除的“过时源”参考这里列几个在旧文章里经常出现、但现在已经不适合继续使用的源帮你避坑。docker.mirrors.ustc.edu.cn中科大源曾经很出名但在我的网络环境下近期已经无法正常拉取 Docker Hub 镜像不建议死守。registry.docker-cn.comDocker 官方中国区源早年可用现在基本已经停止维护。灵雀云在 2018 年前后的镜像源列表里常见现在几乎没有维护意义。看到一份镜像源列表时先注意它的发布时间。如果文章还在推荐这些古老的源大概率是复制粘贴的旧内容里面的操作方式也需要打一个问号。3. 镜像加速配置实操从 daemon.json 到 Docker Desktop3.1 Linux 通用配置步骤修改 daemon.json 并重启Linux 环境下配置镜像加速器的标准做法是修改/etc/docker/daemon.json。这个文件不一定存在不存在就新建一个。先创建一个目录并写配置文件sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://docker.m.daocloud.io, https://hub-mirror.c.163.com ] } EOF修改配置后需要重启 Docker 服务让配置生效sudo systemctl daemon-reload sudo systemctl restart docker重启之后用下面命令确认镜像源已经挂载docker info | grep -A 5 Registry Mirrors正常情况下输出类似Registry Mirrors: https://docker.m.daocloud.io/ https://hub-mirror.c.163.com/这里有一个操作细节修改daemon.json之前建议先备份一份。虽然这个文件出错不至于让系统崩溃但 Docker 服务可能起不来生产环境里会比较被动。sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak如果修改后 Docker 启动失败直接用备份覆盖回来再重启即可。后面第 4.2 节会详细讲排查方法。3.2 Docker DesktopWindows / macOS配置步骤Windows 和 macOS 上装 Docker Desktop 的话配置路径和 Linux 不太一样但原理一致。打开 Docker Desktop进入设置界面左侧找到 Docker Engine里面就是一份 JSON 配置文件。把你希望配置的镜像源填进去{ registry-mirrors: [ https://docker.m.daocloud.io, https://hub-mirror.c.163.com ] }填完点击 Apply RestartDocker Desktop 会自动重启守护进程。重启完成后在终端里执行docker info同样能看到 Registry Mirrors 已经生效。这里提醒一个容易踩的坑Docker Desktop 有自己的配置管理机制不要直接去改它虚拟机内部的文件比如 WSL2 发行版里的/etc/docker/daemon.json。Docker Desktop 重启后很可能会覆盖掉你的修改。所有配置都在 GUI 的 Docker Engine 面板里做或者通过~/.docker/daemon.json管理。如果你的 Docker Desktop 当前启动都报错先别急着配置镜像源。比如 Windows 下常见的virtualization support not detected说明虚拟化层没弄好Docker 守护进程根本没起来这时候配置镜像源没有意义。先解决虚拟化问题我把处理思路放在 4.1 节。3.3 配置完成后如何验证加速效果配置完不等于万事大吉还需要实际验证。我习惯分三步走。第一步检查镜像源地址是否可访问。镜像源本身是符合 Registry HTTP API 规范的服务直接请求它的/v2/路径看返回码即可curl -s https://docker.m.daocloud.io/v2/ -o /dev/null -w %{http_code}\n返回200表示完全正常返回401也不代表有问题因为很多镜像源会要求认证头但这恰好说明服务是活的。如果返回000或者超时说明这个源在当前网络下不可用直接换掉。第二步拉一个小镜像实测速度。注意别用hello-world它太小速度差异体现不出来。用busybox、alpine:3.20或nginx:alpine更合适。time docker pull nginx:alpine第一次拉取时镜像源可能没有缓存需要回源 Docker Hub所以速度不一定快。多拉几次热门的镜像比如redis:7-alpine缓存命中后速度才会提上来。判断标准很简单原来几分钟超时的任务现在几十秒内完成基本就算生效。第三步观察实际使用场景。比如拉一次mysql:8.0time docker pull mysql:8.0MySQL 镜像有几百 MB是验证加速器效果的绝佳对象。配置了靠谱的源之后整个镜像拉取时间应该会明显缩短。同样的方法也适用于gitlab/gitlab-ce这种大镜像镜像源的重要性在它身上体现得最明显——不配置加速器时几百 MB 甚至 GB 级镜像基本拉不动。3.4 多镜像源时 Docker 的优先级规则registry-mirrors是一个数组可以配置多个地址。但你要清楚它的工作方式不是负载均衡而是按顺序尝试失败才切换。Docker 守护进程会先请求列表里的第一个镜像源如果这个源超时或者返回错误才会去请求第二个以此类推。如果所有镜像源都失败最后才回源到 Docker Hub。这里有一个坑如果第一个镜像源本身网络不通但 TCP 连接没有被快速拒绝而是长时间挂起Docker 会等待超时后才切换下一个源。结果就是你配置了三个源实际体验比一个源还差因为大量时间耗在了等待第一个源超时上。我的建议是主力源放一个备选源放一个最多不要超过三个。质量比数量重要把失效的源清理掉比一味堆更多源更有用。4. 常见问题与排查技巧实录4.1 Docker Desktop 启动失败先修好虚拟化再谈镜像源看过很多人在 Windows 上卡在 Docker Desktop 启动阶段报错信息是virtualization support not detected或者Docker Desktop failed to start because virtualisation support wasnt detected。这属于虚拟化环境问题和镜像源配置没有关系。这个报错的常见原因有三个BIOS 里虚拟化开关没开Hyper-V 或 WSL2 功能没有正确启用Windows 版本过旧。排查顺序我建议这样走开机进 BIOS确认 Intel VT-x 或 AMD SVM 已经开启。在 Windows 功能里启用“适用于 Linux 的 Windows 子系统”和“虚拟机平台”。打开 PowerShell执行wsl --status确认默认版本是 2。如果不是执行wsl --set-default-version 2。重启电脑再启动 Docker Desktop。Docker Desktop 需要虚拟化支撑是它的底层要求这个没解决配置任何镜像源都是白搭。我遇到不少人折腾半天镜像加速最后发现 Docker 引擎根本没跑起来。4.2 配置没生效优先检查 daemon.json 与启动日志配置好daemon.json后发现docker info里不显示 Registry Mirrors或者显示的还是旧地址从下面几个点排查。先确认配置文件格式没问题。JSON 格式非常严格多一个逗号、少一个引号都会解析失败。检查方式python3 -m json.tool /etc/docker/daemon.json如果输出报错说明文件格式有问题修正后再重启 Docker。再确认 Docker 服务是否正常启动。很多人执行了systemctl restart docker但服务其实启动失败了。看日志journalctl -u docker -f如果日志里有类似unable to configure the Docker daemon with file /etc/docker/daemon.json的报错基本就是配置文件的语法或内容有问题。我曾经在生产环境遇到过因为daemon.json里同时配置了多个storage-driver导致 Docker 直接起不来这类问题靠日志很快就能定位。还有一种比较隐蔽的情况systemd 的 drop-in 配置文件里通过DOCKER_OPTS或ExecStart显式传入了--registry-mirror参数。命令行参数的优先级高于daemon.json所以文件里的配置不生效。这种情况需要检查/etc/systemd/system/docker.service.d/下的文件把冲突参数去掉。4.3 拉取仍然超时的四个排查方向如果docker info里已经能看到镜像源地址但执行docker pull还是超时别急从四个方向逐个排查。第一镜像源本身不可达。回到 3.3 节提到的 curl 验证方法先看镜像源返回码。如果 curl 都超时那就不是 Docker 的问题是网络到镜像源不通换一个地址重新配置。第二第一个镜像源占据太多超时时间。我在 3.4 节说过列表里如果有一个高延迟的源排在最前面所有拉取请求都会先卡在它身上。把慢的源挪到列表末尾或者直接删掉。第三镜像 tag 在镜像源上没有缓存且镜像源回源 Docker Hub 失败。有些冷门镜像或新发布的版本镜像源第一次遇到会去上游拉取如果上游链路不稳定同样会失败。解决办法是换一个知名 tag或者用其他镜像源试一下。第四DNS 解析异常。极少数情况下镜像源的域名在你当前网络里解析到错误的 IP导致请求发到一个不可达的地址。执行nslookup docker.m.daocloud.io看看解析结果是否正常如果解析异常考虑换用 IP 直连或更换其他镜像源。4.4 安全红线别在生产环境乱用第三方加速源镜像加速器虽然解决下载问题但也引入了一个信任问题。你配置的每一个镜像源都相当于告诉 Docker“我信任这个节点请从它那里获取镜像”。如果这个节点不可信它可以返回任意构造的镜像内容安装到你的系统里执行。我见过有人为了方便把所有第三方公共源一股脑填进去这在个人电脑上问题不大但在生产环境是高风险操作。第三方的源可能有恶意运营者也可能因为维护不善被入侵镜像内容被替换成带后门的版本。三条安全建议一是生产环境优先使用云厂商官方提供的加速器或者干脆自建私有镜像仓库Harbor做内部中转。二是拉取关键镜像时尽量使用带 digest 的方式比如docker pull mysqlsha256:xxxxxx。digest 是对镜像内容的摘要只要 digest 正确镜像内容就无法被替换。三是开启 Docker Content TrustDCT。设置环境变量DOCKER_CONTENT_TRUST1后Docker 会验证镜像签名没有有效签名的镜像无法拉取。这里额外说一句很多热门镜像的拉取命令都可以在 Docker Hub 页面找到 digest 信息花几分钟固定下来安全收益很大。4.5 周边生态一起看Ollama、Hugging Face、npm、PyPI 等镜像源Docker 加速只是“国内下载加速”这个大主题里的一部分。把镜像源配置好之后容器里跑各种应用还会遇到类似的下载问题这里整理几个常见场景。Ollama 拉取模型默认走国外源速度不稳定。两个思路一种是设置环境变量HF_ENDPOINThttps://hf-mirror.com让 Hugging Face 相关下载走国内镜像另一种是先从 ModelScope 这类国内模型社区下载 GGUF 文件再通过ollama create从本地文件创建模型。Hugging Face 是国内 AI 开发者最容易踩坑的下载源。Transformer 模型动辄几个 GB直连基本拉不动。设置HF_ENDPOINThttps://hf-mirror.com之后huggingface_hub库的下载会走国内镜像速度提升非常明显。ComfyUI 的模型下载也适用同样方案。npm、PyPI、Anaconda 这些语言生态的包管理也有对应的国内源。npm 用https://registry.npmmirror.comPyPI 用清华源https://pypi.tuna.tsinghua.edu.cn/simpleAnaconda 通过.condarc配置镜像 channel。Flatpak 用户可以把 Flathub 地址换成上海交大镜像。这些虽然和 Docker 没有直接关系但当你用 Docker 部署青龙面板这类依赖繁多的应用时容器内执行apk add、pip install、npm install都绕不开这些源提前配置好能省下大量等待时间。4.6 常见错误速查表报错信息可能原因处理方式manifest for xxx not found镜像不存在或镜像源未同步该 tag换一个 tag或换镜像源重试Pull access denied for xxx镜像源中没有该镜像或镜像为私有确认镜像名称或直接使用 Docker Hub 重试context deadline exceeded网络到镜像源链路超时用 curl 验证镜像源可达性更换可用源http: server gave HTTP response to HTTPS client镜像源地址写成了 http确认地址是否正确或配置 insecure-registriesError response from daemon: Get ... connection refusedDocker 服务未正常启动先解决 Docker 启动问题再排查镜像源x509: certificate signed by unknown authority镜像源证书异常换用正规公共源不要随意信任未知证书5. 最后分享一个我自己的小习惯我这些年反复配置镜像源总结出一个很实用的习惯把镜像源验证脚本固化下来每次换新机器或者感觉拉镜像变慢时先跑一遍脚本再写daemon.json。脚本逻辑很简单遍历候选镜像源curl 请求/v2/路径输出可用的地址#!/usr/bin/env bash mirrors( https://docker.m.daocloud.io https://hub-mirror.c.163.com https://docker.1ms.run ) for mirror in ${mirrors[]}; do code$(curl -s -o /dev/null -w %{http_code} --connect-timeout 5 $mirror/v2/) echo $mirror - $code done看到返回码为200或401的就保留到配置里。这个脚本我放在自己的 dotfiles 仓库里配合系统初始化配置一起使用重装环境时不用再去翻收藏夹里那些过期列表。镜像源这种事说复杂也复杂说简单也简单。关键不是背下几个 URL而是掌握验证方法和配置原理。今天的可用列表只能代表今天我 9 月 13 日测试通过的地址可能过两个月就需要更新。但这篇文章里的配置思路和排障方法至少在短期内不会过时。