搞 Docker 的人应该都经历过这种名场面docker pull nginx一执行进度条走了两格就卡死等五分钟弹出一句net/http: TLS handshake timeout。不是你的网不行而是 Docker Hub 官方仓库和你的电脑之间隔着一条又慢又绕的链路。所谓 Docker 镜像源加速列表就是围绕这条链路做的“国内可达替代入口”把原本指向 registry-1.docker.io 的 pull 请求改定向到国内访问更快的镜像缓存站让docker pull从“看运气”变成“基本秒下”。这份列表是我在 2026 年 9 月 11 日整理的最新版本既有我实测能用的公共加速地址也包括云厂商需要按账号开通的专属通道配置方法、回退策略、常见报错一并写清楚。适合刚装好 Docker 的新手也适合整天在 CI 里拉镜像、动不动被限流卡脖子的开发者和运维。1. 先搞清楚镜像源到底在加速什么1.1 Docker 镜像拉取慢的根源很多人以为拉镜像慢是带宽不够其实绝大多数情况是链路问题。Docker 默认情况下执行docker pull客户端会访问 registry-1.docker.io这是 Docker Hub 的注册服务入口。接着客户端先向这个地址请求镜像的 manifest清单文件拿到 manifest 之后再根据里面的 layers 信息逐个去下载镜像层。整个过程只要有一个 blob 的下载连接超时这次 pull 就整体失败。这里有个很关键的细节Docker 客户端并不会直接把你输入的nginx解析成完整地址而是自动补全为docker.io/library/nginx再转发到 registry-1.docker.io。所以加速的本质是在“客户端发起请求 → 官方 registry”这段路径上插入一个能被客户端访问到的中转缓存节点。你可以理解成Docker Hub 是一个国外大超市镜像加速器是你在国内租的一个社区自提点超市先把货统一发到自提点你直接去自提点取货。省掉的是“每次买一件东西都要从国外寄一次”的时间。1.2 加速器的作用范围有边界这里必须先泼一盆冷水配置了镜像加速器不代表所有和 Docker 相关的下载都会变快。它的作用范围有明确边界。第一加速器只对 Docker Hub 仓库下的公共镜像生效。也就是registry-1.docker.io、docker.io这两个默认地址下的镜像。如果你拉的是ghcr.io/xxx、gcr.io/xxx、quay.io/xxx这些第三方仓库里的镜像普通镜像源基本不会缓存还是会走原始地址。第二加速器是“拉取加速”不是“上传加速”。docker push到 Docker Hub 依旧慢因为推送走的是官方上传通道。第三公共镜像站不一定缓存冷门镜像。热门镜像如 nginx、redis、mysql、ubuntu 这类镜像站会提前回源缓存好冷门镜像第一次拉取时镜像站需要现场回源第一次慢很正常第二次开始才会走缓存。我刚接触 Docker 时犯过一个错误以为配了加速器连 GitHub 上的克隆、pip 下载、npm 安装都能一起加速。实际上每种生态都有自己的镜像体系这个后面第五章会展开。1.3 2026年镜像源生态的现状与变化这几年国内镜像源生态变化非常大。早几年比较出名的一些公共 Docker 镜像站有些因为带宽和存储成本关停了有些转向了登录制。与此同时新的社区维护站点也在不断冒出来但质量参差不齐。高校开源镜像站的态度也比以前谨慎不少只保留了软件包安装源关闭了 Docker Hub 的公共加速入口。所以“最新列表”这个说法其实很严谨镜像源列表是有时效性的不是一劳永逸。我今天整理这份列表时会尽量多列几个备选也会把验证方法写出来。因为再过三个月谁还能用、谁已经失效真的没人能打包票。2. 镜像源配置方法三种场景一套思路2.1 Linux 下用 /etc/docker/daemon.json 配置Linux 环境包括 Ubuntu、CentOS、Debian 等配置镜像源核心文件是/etc/docker/daemon.json。如果文件不存在自己新建一个即可。完整步骤是这样的# 1. 先备份现有配置防止改错 sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak # 2. 写入镜像源配置 sudo tee /etc/docker/daemon.json EOF { registry-mirrors: [ https://docker.1ms.run, https://docker.m.daocloud.io, https://docker.1panel.live ] } EOF # 3. 重载并重启 Docker 服务 sudo systemctl daemon-reload sudo systemctl restart docker # 4. 验证配置是否生效 docker info | grep -A 5 Registry Mirrorsregistry-mirrors是一个数组可以填多个地址。Docker 客户端在拉取时会按顺序尝试这些地址第一个不通或者失败就会自动回退到下一个。这也是为什么我建议至少填两到三个源而不是只填一个单一镜像源一旦挂掉你的docker pull就彻底不能用。这里有几个容易踩的坑JSON 格式必须严谨不能有注释不能有多余逗号。写错的话 Docker 服务会启动失败systemctl status docker显示 failed用journalctl -u docker能看到 JSON 解析错误。改完配置要重启 Docker光重载不一定生效。虽然有人试过只需要systemctl reload docker但我实测下来最稳妥的还是 restart。如果 daemon.json 里原本还有其他配置项比如 log driver、storage driver不要直接覆盖只改registry-mirrors字段其他保留。2.2 Docker Desktop 图形界面配置Windows 和 macOS 上用 Docker Desktop 的话配置方式更简单不需要去 SSH 到虚拟机里改文件。打开 Docker Desktop → SettingsmacOS 叫 Preferences→ Docker Engine会看到一段 JSON 配置。把registry-mirrors加进去{ registry-mirrors: [ https://docker.1ms.run, https://docker.m.daocloud.io, https://docker.1panel.live ] }然后点Apply Restart等 Docker Desktop 重启完成在终端执行docker info | grep -A 5 Registry Mirrors如果看到你填的几个地址就说明生效了。要注意的是Docker Desktop 的 daemon.json 和 Linux 下的路径不一样不要试图去改~/.docker/config.json那个文件主要保存的是docker login的认证信息不是镜像源配置。你在界面上改Docker Desktop 会自动同步到它托管的虚拟机里。另外Docker Desktop 如果在 Windows 上一直启动失败报virtualisation support wasnt detected那多半不是镜像源的问题而是虚拟化没开这个在第四章详细说。2.3 临时指定镜像源拉取有时候你只是偶尔拉一次镜像不想动全局配置。这时可以直接在镜像地址前面拼上镜像源域名。例如从 DaoCloud 公共源拉 nginxdocker pull docker.m.daocloud.io/library/nginx:1.27拉取成功后可以再打个标签把它“伪装”成官方地址方便后面运行docker tag docker.m.daocloud.io/library/nginx:1.27 nginx:1.27这种方式的好处是即时生效、不污染全局配置坏处是每条命令都要带一长串前缀比较繁琐。适合测试某个镜像源是否可用或者临时应急。2.4 验证配置是否生效配置镜像源之后很多人“以为配好了”结果拉镜像还是慢一看docker info里 Registry Mirrors 是空的。所以我建议配置后第一时间做两件事。第一件事是docker info检查。重点看这两行Registry Mirrors: https://docker.1ms.run/ https://docker.m.daocloud.io/有输出说明 Docker 已经识别到镜像源。第二件事是主动探测镜像源服务是否健康。镜像源本质是一个 registry 服务访问它的/v2/路径会返回 HTTP 状态码。用 curl 就能快速判断curl -s -o /dev/null -w %{http_code} --connect-timeout 5 https://docker.1ms.run/v2/返回200基本说明这个源是可用的返回401也正常因为有的 registry 需要认证但只要 TCP 能通、TLS 握手成功就说明服务是活的返回000或者卡住则是连接失败这种源不要用。3. 2026年9月11日 最新加速列表3.1 公共可用镜像加速站下面是截至 2026 年 9 月 11 日社区反馈相对可用的公共镜像加速站。注意“可用”不等于“永远可用”这个列表随时会变动使用前一定要按 2.4 的方法先探测。镜像源地址维护方/类型说明https://docker.1ms.run社区维护近期反馈速度不错热门镜像缓存较全https://docker.m.daocloud.ioDaoCloud 公共源老牌源比较稳支持 Docker Hub 镜像https://docker.1panel.live1Panel 社区面板社区配套提供的镜像加速https://hub.rat.dev社区维护冷门镜像回源速度波动较大https://dockerproxy.net社区维护可用性一般建议作为备选https://docker.nju.edu.cn南京大学开源镜像站教育网/校园网环境速度快https://docker.mirrors.sjtug.sjtu.edu.cn上海交大 SJTUG 镜像站教育网友好校外访问速度靠缘分说句实话公共镜像站基本是靠爱发电带宽和存储成本都是实打实的钱。哪天站长不想续费了整个站说没就没。所以公共源只适合个人开发机、小团队这种场景生产环CI 环境最好用云厂商的专属加速器或自建缓存。3.2 云厂商专属加速器云厂商提供的镜像加速器特点是“专属通道、限流友好、稳定性相对更高”。缺点是需要登录控制台获取专属地址每个用户都不一样。阿里云登录阿里云容器镜像服务控制台找到“镜像加速器”会给你一个https://xxxx.mirror.aliyuncs.com的专属地址。把这个地址填到 daemon.json 的registry-mirrors里即可。这个加速器对阿里云 ECS 以及公网用户都开放我个人体验是高峰期速度虽会降但基本可用。腾讯云历史上有过https://mirror.ccs.tencentyun.com这个地址但后来主要限制为腾讯云内网使用外网用户直接用它经常连不上。如果你用的是腾讯云 CVM可以试试本地开发机就别折腾了。网易、百度等早期源早年间的https://hub-mirror.c.163.com等地址目前基本处于维护或关停状态不推荐再写入配置。偶尔还能通但没有维护价值的源会拖累整体拉取效率因为 Docker 会先尝试第一个源失败后才回退下一个。3.3 高校与开源镜像站高校镜像站在 Linux 软件源领域地位很高但 Docker 镜像加速这块情况特殊。很多同学去清华 TUNA、中科大镜像站找 Docker 镜像加速结果发现页面里写的是 docker-ce 的安装包源不是拉取镜像的加速地址。这两个东西容易混docker-ce 软件源用于apt install docker-ce解决的是“安装 Docker 软件”的问题。Docker Hub 镜像加速用于docker pull时加速解决的是“拉取容器镜像”的问题。清华和中科大都提供前者对后者的支持要看当前声誉。南大和上交出现过 Docker Hub 加速入口但公开访问经常不稳定。我的建议是高校源做备选可以别做主源。教育网用户在校内访问这些源速度很快出了教育网就不好说了。3.4 多源配置与回落策略不管用公共源还是云厂商源我都建议组合配置而不是把宝押在一个源上。推荐结构是{ registry-mirrors: [ https://你的云厂商加速地址, https://docker.1ms.run, https://docker.m.daocloud.io ] }云厂商源放第一位因为限流相对宽松公共源紧随其后作为兜底。Docker 会按顺序依次尝试直到拉取成功。另外龙芯等非 x86 架构用户要特别注意很多公共镜像站只缓存了 amd64 和 arm64 的层对于 loong64 这类小众架构可能拿到不到对应层导致拉取失败。这种场景下优先用官方源直连或者确认镜像站支持 multi-arch 全量回源。建议写一个小脚本定期批量检查配置里的每个源是否健康#!/usr/bin/env bash mirrors( https://docker.1ms.run https://docker.m.daocloud.io https://docker.1panel.live ) for mirror in ${mirrors[]}; do code$(curl -s -o /dev/null -w %{http_code} --connect-timeout 5 $mirror/v2/) echo $mirror - $code done我个人的习惯是每周跑一次这个脚本发现失效源就及时从 daemon.json 里移除避免影响整体拉取效率。3.5 安全提醒不要乱用不明来源脚本镜像源列表满天飞很多文章附带“一键配置脚本”但说实话我不推荐直接复制运行。原因有两点一是镜像源地址可能被篡改。如果源指向的是一个恶意 registry拉下来的镜像是被投毒的镜像轻则应用运行异常重则容器内被植入挖矿程序。Docker 镜像的信任链本来就复杂从非官方渠道拉镜像风险更高。二是脚本可能夹带其他操作。有些“配置镜像源”脚本会顺手添加计划任务、导出环境变量、替换系统文件等。运行前一定要打开脚本看一遍确认里面没有多余动作。拉取完镜像后特别是从冷门镜像源拉取的建议校验一下 digestdocker inspect --format {{index .RepoDigests 0}} 镜像名如果显示的是镜像源仓库而不是 docker.io 官方仓库的 digest就要留个心眼确认这个源是否可靠。4. 高频问题排查与避坑记录4.1 Docker Desktop 启动失败虚拟化未开启Windows 上 Docker Desktop 最常见的报错之一就是开头提到的那句Docker Desktop failed to start because virtualisation support wasnt detected。这个和镜像源没有任何关系是 Windows 的虚拟化能力没打开。排查和解决路径如下进 BIOS/UEFI确认Intel VT-x或AMD-V已开启不同主板位置不一样一般在 CPU Configuration 或 Advanced 菜单下。在 Windows 功能里开启相关组件。以管理员身份打开 PowerShell执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart重启电脑。打开 Docker Desktop如果还不行去 Settings 里确认 Backend 选的是 WSL2 而不是 Hyper-V或者反过来换一个试试。macOS 上如果出现类似提示Intel 机型需要检查系统设置里的虚拟化支持Apple Silicon 机型一般没有这个问题因为底层是原生虚拟化框架。4.2 拉取镜像超时 / TLS handshake timeout这个报错太典型了net/http: TLS handshake timeout、dial tcp ... i/o timeout。第一反应不是去重启 Docker而是先确认能不能连通镜像源curl -v https://docker.1ms.run/v2/如果返回 HTTP 状态码说明网络通问题可能出在 Docker 配置没生效或者源本身在回源慢。如果 curl 直接超时说明这个源对你所在的网络环境不可达换源。还有一种情况DNS 解析出的 Docker Hub 官方地址质量很差。可以试着把主机 DNS 改成国内公共 DNS比如阿里云的223.5.5.5、腾讯云的119.29.29.29然后docker pull再试一次。4.3 报错 received unexpected HTTP status code: 500 / 503 / 429这类状态码基本是镜像站自身的问题429 Too Many Requests拉取频率太高触发了镜像站的限流。等几分钟再拉或者换备用源。503 Service Unavailable镜像站正在回源或者上游链路拥挤。可以先拉另一个镜像试试确认是不是全站都有问题。500 Internal Server Error镜像站缓存层出错一般等一会儿能恢复也可以临时用官方源直连。我自己遇到过一种很隐蔽的情况镜像站某个特定镜像的缓存损坏了拉其他镜像都正常唯独拉某一个镜像一直报 500。这种情况直接改用其他源拉同一个镜像或者用docker pull原始官方地址绕开该镜像站。4.4 自建内网镜像缓存如果你在公司内网或家里 NAS 上维护多台 Docker 主机自建一个 registry 缓存远比依赖公共镜像源靠谱。官方registry:2镜像本身就支持回源缓存功能你只需要把它跑起来并指定上游源为 Docker Hubdocker run -d -p 5000:5000 --name registry-cache \ -e REGISTRY_PROXY_REMOTEURLhttps://registry-1.docker.io \ -v $(pwd)/registry-data:/var/lib/registry registry:2然后在每台主机的 daemon.json 里把 registry-mirrors 指向这台缓存服务{ registry-mirrors: [http://192.168.1.10:5000], insecure-registries: [192.168.1.10:5000] }这里的insecure-registries很关键因为自建服务默认走 HTTPDocker 对非 TLS 的 registry 是拒绝连接的必须在 insecure 列表里显式声明。这种做法的好处是同网段内第一台机器拉取过的镜像第二台机器再次拉取时几乎秒下。副作用是首次拉取冷门镜像时缓存服务需要现场回源可能会比直接用公共源稍慢一点。这个方案我用了快两年真正解决了我团队在 CI 高峰期被公共源限流的问题。如果集群规模再大一些可以上 dragonfly 这类 P2P 分发方案但配置复杂度会高一个量级小团队没必要。4.5 镜像源认证失败与拉取限额Docker Hub 对匿名用户一直有拉取速率限制有时候你会看到toomanyrequests: You have reached your pull rate limit。解决办法docker login登录 Docker Hub 账号登录后限额会提升一个档位。优先使用公共镜像源因为镜像站有集中缓存你的拉取请求命中镜像站的缓存不直接回源官方。如果拉的是私有镜像即使配了镜像源客户端也不会把私有仓库交给镜像站去拉认证失败时优先检查 Docker Hub 账号权限和仓库名称是否正确。5. 从 Docker 源延伸到周边生态的镜像加速思路5.1 不只 Docker操作系统和编程语言都有一批自己的镜像源从热门搜索词能看到苦于“慢”的不只是 Docker 拉镜像。Ubuntu 的apt慢、Python 的pip慢、Node 的npm慢、Go 模块下载慢、Java 的 Gradle 依赖慢本质上都是一回事默认远程仓库在海外链路长。解决思路也是同一个换成国内可达的镜像站。通用做法是去清华 TUNA、中科大、阿里云开发者社区这些镜像站站点找到对应项目的页面上面会给出配置命令。以最常见的 pip 和 npm 为例# pip 使用清华源 pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple # npm 使用 npmmirror 源 npm config set registry https://registry.npmmirror.com这种配置方式和 Docker 镜像源的思路完全一致把默认仓库地址改成一个更近的副本。但注意每个生态的镜像站维护情况不同有的更新快有的只看热门包配置前还是先看一眼镜像站的同步状态。5.2 公共代码仓库文件下载加速容器之外开发者最常碰到的问题是从公共代码仓库下载 release 附件很慢。社区里通常的做法是通过“下载链接拼接加速域名”的方式比如把一个 release 下载链接拼上特定的加速前缀从而访问到一个更近的缓存节点。这类服务只适合下载公开开源项目的安装包或二进制文件下载后强烈建议校验 SHA 值。这个思路和 Docker 镜像源是相通的默认链路慢就换一个国内可达的缓存节点。但要提醒一句不要用这些节点传递任何隐私或内部文件安全隐患很大。5.3 Ollama、Flatpak、ComfyUI 等新场景的镜像源模型下载工具、Linux 应用分发、AI 绘画工具这些场景同样有各自的镜像体系。Ollama模型仓库的默认地址在大陆访问不稳定。常见的替代方式是两种一是从国内模型社区手动下载 GGUF 文件再通过 Modelfile 导入到本地二是用支持国外路径的模型下载工具将模型文件转存到本地后直接加载。FlatpakLinux 桌面应用分发工具默认的 Flathub 仓库访问也慢。部分高校镜像站提供 Flathub 镜像配置命令大致是flatpak remote-modify flathub --url镜像站地址具体地址要以镜像站当前页面为准。ComfyUI主要慢在两部分一是 Python 依赖安装慢用清华 pip 源解决二是模型文件下载慢项目里常见的 checkpoint、LoRA 模型可以从国内模型社区下载不一定非要走原始地址。5.4 青龙容器里的依赖慢怎么办青龙面板本身安装在 Docker 容器里镜像拉取问题靠第一节的镜像源配置解决。但很多人忽略的是容器内部的依赖安装同样需要配置源。青龙的依赖管理脚本执行npm install或pip install时默认会走国际源速度同样感人。进容器后执行npm config set registry https://registry.npmmirror.com pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple但容器一旦重建这些配置就没了。所以建议你把配置写进启动命令或 Dockerfile 里而不是手动进容器改。顺便多说一句青龙面板拉取依赖失败时日志里报的 error 不一定是依赖本身的问题很可能是源访问超时。先换源再排查依赖版本冲突顺序不要反。最后分享一个我的真实习惯。我会在每台开发机上放一个check-mirrors.sh脚本内容就是第三节那个 curl 循环定时跑一遍哪天某个源返回非 200我会第一时间看到。镜像源这个东西生命力完全取决于维护者的精力和成本今天能用不代表下个月还能用。与其每次等docker pull超时再去搜新列表不如把验证这件事自动化把主动权握在自己手里。