1. 先聊两句为什么镜像下载这么慢镜像源又是怎么加速的Docker 镜像下载慢几乎是每个用过 Docker 的人都绕不过去的问题。我在公司负责内部开发环境维护时最头疼的就是同事拉一个镜像等了十分钟还在转圈尤其是那种几个 GB 的基础镜像下载到一半直接超时整条流水线都卡住。后来统一配上国内镜像源整个团队的拉取速度肉眼可见地上来了关于“镜像卡住”的工单也少了一大半。这篇内容就是把我截至 2026 年 9 月 13 日重新测过一遍的 Docker 国内镜像源加速列表、各平台配置方法以及实际使用中踩过的坑整理出来个人开发者、学生、运维人员还有在国产 CPU 环境做容器化的朋友都可以参考。Docker 默认从 Docker Hub 拉取镜像而 Docker Hub 的服务节点都在海外国内直连延迟高、容易断流。这不是你网络的问题是物理距离和链路质量的问题。镜像源的原理其实是一台“前置缓存服务”它在海外替你把镜像拉下来然后在国内提供下载。你在客户端把registry-mirrors指向这个地址执行docker pull的时候Docker 会优先请求镜像源镜像源本地没有缓存时再回源去 Docker Hub 拉取拉完缓存下来之后再有相同请求就直接走缓存。所以同一个镜像第一次拉可能稍慢第二次就会快很多。也正因为这样镜像源能不能用、快不快很大程度上取决于这个源本身的带宽、机房位置和当前负载。今天能用的地址下个月可能就 502 了这不是哪个团队故意“不干了”而是公益源长期占用带宽和成本扛不住滥用之后就只能限流或关闭。所以我也一直建议大家镜像源列表要当作“工具库”来维护而不是当成一劳永逸的配置隔一段时间就重新验证一次手头永远留两三个备用地址。2. 2026 年 9 月 13 日验证最新可用 Docker 国内镜像源加速列表2.1 镜像源地址列表按来源分类先上硬货。下表是我在 2026 年 9 月 13 日从华东地区一个普通宽带网络环境实测的结果不同地区、不同运营商表现会有差异但“能用”和“不能用”的判断基本是准确的。格式是我整理列表时常用的“地址 类型 实测情况 备注”四列方便你判断该选谁。镜像源地址类型实测情况2026-09-13备注https://docker.m.daocloud.io社区公益可用速度不错DaoCloud 团队维护社区活跃度较高https://docker.1panel.live社区公益可用速度尚可1Panel 团队维护国内口碑不错https://docker.xuanyuan.me社区公益可用偶尔超时适合做备选不建议放第一位https://docker.1ms.run社区公益可用速度还不错备用优选之一https://docker.mirrors.ustc.edu.cn高校机构部分地区失效建议先验证中科大镜像站带宽有保障https://docker.mirrors.sjtug.sjtu.edu.cn高校机构建议先验证上海交大镜像站https://docker.nju.edu.cn高校机构建议先验证南京大学镜像站https://hub-mirror.c.163.com商业历史部分版本可用速度一般网易开源镜像https://registry.docker-cn.com官方历史已关闭不建议使用早期官方国内加速地址现在基本不可用注意阿里云和腾讯云也有容器镜像服务提供的专属加速地址但那个地址需要登录控制台获取并且每个账号都不一样没法直接列在公共表格里。如果你正在用阿里云直接在“容器镜像服务”控制台里找到“镜像加速器”复制你账号专属的加速地址填到 daemon.json 里即可这类专属源通常比公共源更稳。2.2 怎么快速判断一个镜像源还能不能用判断镜像源是否在线不需要真的去拉一个完整镜像只需要确认它的/v2/接口能不能正常响应。我在公司排查镜像源问题时一般就是一条命令curl -I https://docker.m.daocloud.io/v2/返回HTTP/1.1 401 Unauthorized是正常的因为/v2/端点本身要求认证能返回 401 说明服务在线、响应正常。如果返回403、502、504或者直接超时那这个源大概率已经不能用了。这个方法比docker pull更快几秒钟就能判断完适合批量验证一批镜像源。如果你是想彻底确认“能拉镜像”那就找一个小镜像试拉比如docker pull hello-world或者拉一个体积很小的工具镜像比如docker pull alpine:3.20几十秒内就能看出结果。2.3 选镜像源的三个原则第一不要只配一个源。镜像源本身也会有故障只配一个源等于把风险背在自己身上。我建议配置 2 到 3 个至少保证有一个公益源和一个高校/商业源。第二别把最慢的放第一位。Docker 配置多个 mirror 时会按顺序尝试前面的失败或超时才会轮到后面。如果你把一个经常超时的源放在第一位每次拉镜像都会先等它超时体验会非常糟糕。第三注意区分“软件源”和“镜像源”。很多人会把mirrors.aliyun.com/docker-ce这种地址当成 Docker 镜像加速地址来用这是不对的。docker-ce是安装 Docker 软件本身的软件源不是拉取容器的镜像源。镜像源的路径必须是/v2/接口能正常访问的地址这两者完全不同。3. 镜像源配置实操Docker Desktop 与 Linux 一条龙3.1 Docker Desktop 下配置镜像源Windows 和 macOS 上的 Docker Desktop 配置镜像源比较直观不需要碰命令行。打开 Docker Desktop 之后点击右上角齿轮进入 Settings找到 Docker Engine 这一项你会在右侧看到一个 JSON 格式的配置文件默认长这样{ registry-mirrors: [] }把之前整理好的镜像源地址填进去注意是数组格式地址之间用逗号隔开{ registry-mirrors: [ https://docker.m.daocloud.io, https://docker.1panel.live, https://docker.xuanyuan.me ] }填完之后点击 Apply RestartDocker Desktop 会带着新配置重启。重启完成后打开终端执行docker info输出信息里找到Registry Mirrors这一行如果能看到你配置的地址说明已经生效。需要留意的是新版 Docker Desktop 默认使用 WSL 2 作为后端引擎因此配置会同时作用于 WSL 环境。如果 WSL 里也安装了独立的 Docker那就需要按下面的 Linux 方法单独配置一遍。3.2 Linux 服务器下配置镜像源Linux 服务器上 Docker 的配置文件路径是/etc/docker/daemon.json。如果这个文件不存在自己创建即可。我一般用vim编辑sudo mkdir -p /etc/docker sudo vim /etc/docker/daemon.json填入同样的 JSON 内容{ registry-mirrors: [ https://docker.m.daocloud.io, https://docker.1panel.live ] }保存退出后重载配置并重启 Dockersudo systemctl daemon-reload sudo systemctl restart docker然后同样用docker info确认配置是否生效。这里多说一句很多人在重启 docker 时发现服务起不来十有八九是daemon.json的 JSON 格式写错了比如多逗号、少引号或者用了中文标点。编辑完文件先跑一句docker info验证一下如果报错会直接提示解析失败。3.3 配置后如何确认真的生效有个细节容易被忽略docker info里会显示配置的 mirror 地址但显示出来不代表这个源一定能用。你想验证“docker pull 是否真的走了镜像源”可以先把一个没拉过的镜像拉下来然后观察输出信息。如果拉取速度明显快于直连 Docker Hub说明镜像源在起作用。如果拉取时提示error pulling image configuration或者一直卡在waiting那可能是镜像源有问题需要换一个。Windows 用户还可以在 PowerShell 里执行docker info | Select-String -Pattern Registry Mirrors能打印出你配置的地址就说明生效了。3.4 Docker Desktop 启动失败排查Virtualization / npipe 问题在热词里我看到很多人提到virtualization support not detected和failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine这两个问题我非常熟悉几乎每周都会遇到同事来问。先说virtualization support not detected。这个报错说明 Docker Desktop 没有检测到虚拟化能力。重启电脑进 BIOS/UEFI找到 CPU 设置把 Intel Virtualization TechnologyVT-x或 AMD SVM Mode 打开保存退出。Windows 系统还需要确认以下三项功能已经开启在“控制面板 - 程序 - 启用或关闭 Windows 功能”里勾选“适用于 Linux 的 Windows 子系统”“虚拟机平台”和“Windows 虚拟机监控程序平台”。这三项都开启后重启电脑再启动 Docker Desktop 就不会再报这个错了。failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine是另一类常见问题。它的意思是 Docker 引擎没有正常启动客户端连不上。通常先重启 Docker Desktop如果不行在 PowerShell 里执行wsl --shutdown等几秒后再重新启动 Docker Desktop。这个命令会关闭 WSL 的所有虚拟机Docker Desktop 重启时会重新拉起一个干净的引擎环境。如果是刚升级完 Docker Desktop 或 Windows 系统更新之后出现这个问题基本都能靠这条命令解决。4. 不同镜像源到底谁更快实测结果与选型参考4.1 我这边的一轮简单实测数据为了写这篇内容我专门在 2026 年 9 月 13 日做了一组实测。测试环境是华东地区家庭宽带Windows 11 WSL2Docker Desktop 版本为最新稳定版。镜像选择redis:7.2约 130 MB和nginx:1.27约 110 MB分别从几个可用镜像源拉取记录消耗时间结果如下镜像源拉取 redis:7.2拉取 nginx:1.27整体感受直连 Docker Hub超时/断开超时/断开基本拉不动docker.m.daocloud.io约 8 秒约 6 秒速度最快缓存命中率高docker.1panel.live约 12 秒约 10 秒可用速度中上docker.xuanyuan.me约 20 秒约 15 秒可用偶尔等待docker.1ms.run约 14 秒约 12 秒可用备用首选docker.mirrors.ustc.edu.cn连接失败连接失败在我这边已失效需验证hub-mirror.c.163.com约 25 秒约 18 秒能用但性能明显不如公益源这个数据只是我本地网络的参考不代表所有地区。不过它可以说明一个趋势社区维护的公益源目前可用性好高校镜像站反而不一定都能用因为高校镜像站更多面向校园网对外带宽有限且部分学校已经逐步收缩对 Docker Hub 的镜像服务。4.2 不同人群的选型建议个人开发者和学生优先用docker.m.daocloud.io作为第一个源搭配docker.1panel.live做备选。这两个源在国内社区讨论度最高出问题时修复也比较及时。小团队或公司内部开发环境我还是建议配一个自建的镜像缓存服务比如用 Harbor 或 Docker Registry 做内网拉取。公共镜像源虽然方便但你不知道它什么时间点会出问题团队协作场景下几十个人同时拉同一个镜像一旦公共源限流所有人一起遭殃。内网缓存才是长期解法公共源只是在过渡期和个人的环境里用。如果服务器在境外或者靠近香港地区其实可以不用折腾镜像源直连 Docker Hub 就很快。这个判断很简单你先用docker pull拉一个小镜像如果一分钟内能拉完就不需要配镜像源如果等了两分钟还在转圈再配也不迟。5. 用镜像源完成几个高频实战场景5.1 拉取并运行 MySQL 8.0配好镜像源之后最直观的收益就是拉取数据库这类几十 MB 甚至几个 GB 的镜像变得非常快。以 MySQL 8.0 为例docker pull mysql:8.0拉取完成后运行并设置初始密码docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD你的密码 \ --restartalways \ mysql:8.0再进入容器检查是否正常运行docker exec -it mysql8 mysql -uroot -p这里有几个实际经验想提醒一下第一MYSQL_ROOT_PASSWORD只是初始化密码如果你之后挂载了数据卷这个变量就只在第一次启动时生效第二生产环境一定要加--restartalways不然服务器重启后 MySQL 不会自动拉起第三字符集建议在启动参数中加上--character-set-serverutf8mb4否则默认字符集在中文场景下很容易出现乱码。5.2 用 Docker Compose 搭建 Redis 主从Redis 主从是很常见的场景很多人会在网上找别人写好的 compose 文件结果因为镜像拉不下来一直起不来。现在镜像源配好了可以直接用下面这个文件在目录里保存为docker-compose.ymlservices: redis-master: image: redis:7.2 container_name: redis-master command: redis-server --requirepass redis123 ports: - 6379:6379 restart: always redis-slave: image: redis:7.2 container_name: redis-slave command: redis-server --replicaof redis-master 6379 --masterauth redis123 depends_on: - redis-master restart: always在文件所在目录执行docker compose up -d这就完成了 Redis 主从搭建。验证是否同步成功进入从节点docker exec -it redis-slave redis-cli -a redis123 info replication如果看到role:slave并且master_link_status:up就说明主从关系正常。需要注意Redis 5.0 之后已经不推荐使用slaveof命令建议用replicaof新版镜像里直接用replicaof更稳妥。5.3 拉取 Ollama 镜像部署本地模型服务最近身边的同事都在搞本地 AI 应用Ollama 是部署本地模型的常用方案但ollama/ollama镜像本身也在 Docker Hub 上直连同样拉不动。镜像源配好之后直接拉取docker pull ollama/ollama然后启动docker run -d \ --name ollama \ -v ollama:/root/.ollama \ -p 11434:11434 \ --restartalways \ ollama/ollama这里需要区分两件事Ollama 镜像本身的拉取走的是 Docker 镜像源而进入容器后执行ollama run qwen2.5下载模型文件时走的是模型下载通道和 Docker 镜像源不是同一个体系。如果你拉模型慢需要单独配置模型源的镜像比如在容器内设置HUGGING_FACE_HUB_TOKEN或者使用国内模型镜像站这属于另一个话题。但至少把ollama/ollama容器拉下来这个步骤镜像源能解决绝大部分问题。5.4 Docker 青龙面板拉取与依赖安装加速青龙面板这名字熟悉的人比较多很多朋友会在家里的软路由或 NAS 上部署。拉取镜像docker pull whyour/qinglong:latest或者直接用镜像源地址临时拉取方法是在镜像名前加上镜像源前缀docker pull docker.m.daocloud.io/whyour/qinglong:latest拉完再手动打标签docker tag docker.m.daocloud.io/whyour/qinglong:latest whyour/qinglong:latest这种“加前缀”的临时方案适合那些已经配置好镜像源但某些镜像还是拉不下来的情况相当于强制让它走指定源非常实用。青龙面板跑的脚本经常需要各种 npm 依赖和 Python 依赖有些依赖仓库同样不在国内装依赖慢或者装不上时可以在容器里把 npm 源切换到 npmmirror 镜像把 pip 源切换到清华镜像。这一步和 Docker 镜像源是两套体系但都属于“国内镜像加速”的范畴一起配好才能让整个面板真正顺畅跑起来。6. 配置镜像源之后的常见坑与排查技巧6.1 daemon.json 写错Docker 直接起不来这是最容易被新手踩的坑。daemon.json是一个严格符合 JSON 格式的文件多一个逗号或少一个引号都会导致 Docker 启动失败。如果你改完配置后执行systemctl restart docker发现服务起不来先别急着还原文件用下面这个命令看看日志journalctl -u docker -n 50如果日志里出现unable to configure the Docker daemon with file /etc/docker/daemon.json: invalid character之类的提示基本就是 JSON 格式问题。解决办法很简单把文件放到任意一个 JSON 在线校验工具里或者用 Python 校验python3 -m json.tool /etc/docker/daemon.json没有报错就说明格式没问题再重启 Docker。6.2 配置了镜像源但 docker pull 感觉没走镜像源有一种情况是配置已经生效但 docker pull 确实没有走镜像源常见原因是镜像源不支持多架构Manifest List。比如你在一台 ARM 机器上拉取 x86 架构的镜像Docker 会去镜像源请求多架构索引如果镜像源不支持就会跳过镜像源回落到 Docker Hub结果还是慢。判断方法很简单docker pull时输出里如果有falling back to the local registry或者明显等待很久多为漏斗问题。解决办法是换一个支持多架构的镜像源或者直接用带架构后缀的镜像标签。另一种情况是根本没有重启 Docker。改完/etc/docker/daemon.json必须systemctl restart dockerDocker Desktop 必须 Apply Restart这一步漏了配置永远只停留在文件里。6.3 镜像源返回 401 / 502 / 超时返回 502 或超时基本可以判定这个镜像源当前不可用换源即可。返回 401 反而可能是正常的因为前面说过/v2/接口本身要求认证。但如果你在docker pull阶段看到 401说明镜像源接到了请求但拒绝为这个镜像回源一般是镜像源只开放了白名单镜像或者已经停止回源这时候也只能换源。我个人的习惯是每个季度用开头的curl -I 镜像源/v2/命令把所有备选源检查一遍然后把不可用的从配置里剔除补上新的地址顺便更新到团队文档里。这份列表看起来是静态的实际上每个月都在变不维护等于没配。6.4 容器运行时不同镜像加速配置位置也不同Docker 和 Kubernetes 底层的容器运行时现在已经越来越多样化。如果你用的是纯 Docker 环境配置就在/etc/docker/daemon.json如果你用的是 containerd配置方式完全不同如果用的是 Podman又有自己的一套配置。这篇内容里列的registry-mirrors只对 Docker 生效。很多人在 K8s 节点上改了 docker 的 daemon.json发现 kubelet 拉镜像还是慢就是因为 kubelet 用的是 containerd 或 CRI 运行时需要单独配置/etc/containerd/config.toml。这个不展开太多但要记住改配置之前先确认你的环境到底用的什么运行时。6.5 注意镜像供应链安全最后说一个容易被忽略的点镜像源本质上是“第三方替你拉取和转发镜像”这本身就意味着你会把拉取请求交给第三方处理。所以我只建议从长期维护、口碑透明的镜像源拉取公共镜像不要随便用一些来源不明的个人地址尤其是在生产环境。拉取镜像时可以留意 digest 值比较关键的生产镜像最好通过docker pull后再用docker inspect校验签名和 digest 是否和官方一致。镜像源加速是解决下载速度问题的工具但不应以牺牲供应链安全为代价。7. 最后分享几点我的个人使用体会我实际用了快四年国内镜像源最大的体会是不要相信任何“长期有效”的列表包括我这份。镜像源生态一直处于动态变化中旧地址关闭、新地址出现都是常态。我自己的做法是维护一张小表格把备选源地址、验证日期、当前状态、最近一次拉取结果记下来每个月顺手跑一遍验证命令比每次等到拉不动了再去网上翻帖子高效得多。另一个建议是公共镜像源和自建缓存最好分场景使用。个人电脑、学习环境、临时实验用公共镜像源足够生产环境或几人以上的团队尽早部署一层内网镜像缓存。Harbor 就是不错的选择把外部镜像先同步到内网所有节点从内网拉取既快又可控。公共源解决的是“能不能拉下来”的问题自建缓存解决的是“持续稳定获取”的问题。如果你现在还在被 Docker 镜像下载慢折磨我的建议很简单先按文中方法配上一个主选源和一个备选源跑通docker pull让日常工作先顺畅起来之后再慢慢完善你专属的镜像源维护机制。这个列表会过期但配置方法和排查思路不会掌握了自己动手验证的能力以后遇到任何新镜像源都能很快判断它到底能不能用。
Docker国内镜像源加速配置指南：2026最新可用列表与实操
1. 先聊两句为什么镜像下载这么慢镜像源又是怎么加速的Docker 镜像下载慢几乎是每个用过 Docker 的人都绕不过去的问题。我在公司负责内部开发环境维护时最头疼的就是同事拉一个镜像等了十分钟还在转圈尤其是那种几个 GB 的基础镜像下载到一半直接超时整条流水线都卡住。后来统一配上国内镜像源整个团队的拉取速度肉眼可见地上来了关于“镜像卡住”的工单也少了一大半。这篇内容就是把我截至 2026 年 9 月 13 日重新测过一遍的 Docker 国内镜像源加速列表、各平台配置方法以及实际使用中踩过的坑整理出来个人开发者、学生、运维人员还有在国产 CPU 环境做容器化的朋友都可以参考。Docker 默认从 Docker Hub 拉取镜像而 Docker Hub 的服务节点都在海外国内直连延迟高、容易断流。这不是你网络的问题是物理距离和链路质量的问题。镜像源的原理其实是一台“前置缓存服务”它在海外替你把镜像拉下来然后在国内提供下载。你在客户端把registry-mirrors指向这个地址执行docker pull的时候Docker 会优先请求镜像源镜像源本地没有缓存时再回源去 Docker Hub 拉取拉完缓存下来之后再有相同请求就直接走缓存。所以同一个镜像第一次拉可能稍慢第二次就会快很多。也正因为这样镜像源能不能用、快不快很大程度上取决于这个源本身的带宽、机房位置和当前负载。今天能用的地址下个月可能就 502 了这不是哪个团队故意“不干了”而是公益源长期占用带宽和成本扛不住滥用之后就只能限流或关闭。所以我也一直建议大家镜像源列表要当作“工具库”来维护而不是当成一劳永逸的配置隔一段时间就重新验证一次手头永远留两三个备用地址。2. 2026 年 9 月 13 日验证最新可用 Docker 国内镜像源加速列表2.1 镜像源地址列表按来源分类先上硬货。下表是我在 2026 年 9 月 13 日从华东地区一个普通宽带网络环境实测的结果不同地区、不同运营商表现会有差异但“能用”和“不能用”的判断基本是准确的。格式是我整理列表时常用的“地址 类型 实测情况 备注”四列方便你判断该选谁。镜像源地址类型实测情况2026-09-13备注https://docker.m.daocloud.io社区公益可用速度不错DaoCloud 团队维护社区活跃度较高https://docker.1panel.live社区公益可用速度尚可1Panel 团队维护国内口碑不错https://docker.xuanyuan.me社区公益可用偶尔超时适合做备选不建议放第一位https://docker.1ms.run社区公益可用速度还不错备用优选之一https://docker.mirrors.ustc.edu.cn高校机构部分地区失效建议先验证中科大镜像站带宽有保障https://docker.mirrors.sjtug.sjtu.edu.cn高校机构建议先验证上海交大镜像站https://docker.nju.edu.cn高校机构建议先验证南京大学镜像站https://hub-mirror.c.163.com商业历史部分版本可用速度一般网易开源镜像https://registry.docker-cn.com官方历史已关闭不建议使用早期官方国内加速地址现在基本不可用注意阿里云和腾讯云也有容器镜像服务提供的专属加速地址但那个地址需要登录控制台获取并且每个账号都不一样没法直接列在公共表格里。如果你正在用阿里云直接在“容器镜像服务”控制台里找到“镜像加速器”复制你账号专属的加速地址填到 daemon.json 里即可这类专属源通常比公共源更稳。2.2 怎么快速判断一个镜像源还能不能用判断镜像源是否在线不需要真的去拉一个完整镜像只需要确认它的/v2/接口能不能正常响应。我在公司排查镜像源问题时一般就是一条命令curl -I https://docker.m.daocloud.io/v2/返回HTTP/1.1 401 Unauthorized是正常的因为/v2/端点本身要求认证能返回 401 说明服务在线、响应正常。如果返回403、502、504或者直接超时那这个源大概率已经不能用了。这个方法比docker pull更快几秒钟就能判断完适合批量验证一批镜像源。如果你是想彻底确认“能拉镜像”那就找一个小镜像试拉比如docker pull hello-world或者拉一个体积很小的工具镜像比如docker pull alpine:3.20几十秒内就能看出结果。2.3 选镜像源的三个原则第一不要只配一个源。镜像源本身也会有故障只配一个源等于把风险背在自己身上。我建议配置 2 到 3 个至少保证有一个公益源和一个高校/商业源。第二别把最慢的放第一位。Docker 配置多个 mirror 时会按顺序尝试前面的失败或超时才会轮到后面。如果你把一个经常超时的源放在第一位每次拉镜像都会先等它超时体验会非常糟糕。第三注意区分“软件源”和“镜像源”。很多人会把mirrors.aliyun.com/docker-ce这种地址当成 Docker 镜像加速地址来用这是不对的。docker-ce是安装 Docker 软件本身的软件源不是拉取容器的镜像源。镜像源的路径必须是/v2/接口能正常访问的地址这两者完全不同。3. 镜像源配置实操Docker Desktop 与 Linux 一条龙3.1 Docker Desktop 下配置镜像源Windows 和 macOS 上的 Docker Desktop 配置镜像源比较直观不需要碰命令行。打开 Docker Desktop 之后点击右上角齿轮进入 Settings找到 Docker Engine 这一项你会在右侧看到一个 JSON 格式的配置文件默认长这样{ registry-mirrors: [] }把之前整理好的镜像源地址填进去注意是数组格式地址之间用逗号隔开{ registry-mirrors: [ https://docker.m.daocloud.io, https://docker.1panel.live, https://docker.xuanyuan.me ] }填完之后点击 Apply RestartDocker Desktop 会带着新配置重启。重启完成后打开终端执行docker info输出信息里找到Registry Mirrors这一行如果能看到你配置的地址说明已经生效。需要留意的是新版 Docker Desktop 默认使用 WSL 2 作为后端引擎因此配置会同时作用于 WSL 环境。如果 WSL 里也安装了独立的 Docker那就需要按下面的 Linux 方法单独配置一遍。3.2 Linux 服务器下配置镜像源Linux 服务器上 Docker 的配置文件路径是/etc/docker/daemon.json。如果这个文件不存在自己创建即可。我一般用vim编辑sudo mkdir -p /etc/docker sudo vim /etc/docker/daemon.json填入同样的 JSON 内容{ registry-mirrors: [ https://docker.m.daocloud.io, https://docker.1panel.live ] }保存退出后重载配置并重启 Dockersudo systemctl daemon-reload sudo systemctl restart docker然后同样用docker info确认配置是否生效。这里多说一句很多人在重启 docker 时发现服务起不来十有八九是daemon.json的 JSON 格式写错了比如多逗号、少引号或者用了中文标点。编辑完文件先跑一句docker info验证一下如果报错会直接提示解析失败。3.3 配置后如何确认真的生效有个细节容易被忽略docker info里会显示配置的 mirror 地址但显示出来不代表这个源一定能用。你想验证“docker pull 是否真的走了镜像源”可以先把一个没拉过的镜像拉下来然后观察输出信息。如果拉取速度明显快于直连 Docker Hub说明镜像源在起作用。如果拉取时提示error pulling image configuration或者一直卡在waiting那可能是镜像源有问题需要换一个。Windows 用户还可以在 PowerShell 里执行docker info | Select-String -Pattern Registry Mirrors能打印出你配置的地址就说明生效了。3.4 Docker Desktop 启动失败排查Virtualization / npipe 问题在热词里我看到很多人提到virtualization support not detected和failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine这两个问题我非常熟悉几乎每周都会遇到同事来问。先说virtualization support not detected。这个报错说明 Docker Desktop 没有检测到虚拟化能力。重启电脑进 BIOS/UEFI找到 CPU 设置把 Intel Virtualization TechnologyVT-x或 AMD SVM Mode 打开保存退出。Windows 系统还需要确认以下三项功能已经开启在“控制面板 - 程序 - 启用或关闭 Windows 功能”里勾选“适用于 Linux 的 Windows 子系统”“虚拟机平台”和“Windows 虚拟机监控程序平台”。这三项都开启后重启电脑再启动 Docker Desktop 就不会再报这个错了。failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine是另一类常见问题。它的意思是 Docker 引擎没有正常启动客户端连不上。通常先重启 Docker Desktop如果不行在 PowerShell 里执行wsl --shutdown等几秒后再重新启动 Docker Desktop。这个命令会关闭 WSL 的所有虚拟机Docker Desktop 重启时会重新拉起一个干净的引擎环境。如果是刚升级完 Docker Desktop 或 Windows 系统更新之后出现这个问题基本都能靠这条命令解决。4. 不同镜像源到底谁更快实测结果与选型参考4.1 我这边的一轮简单实测数据为了写这篇内容我专门在 2026 年 9 月 13 日做了一组实测。测试环境是华东地区家庭宽带Windows 11 WSL2Docker Desktop 版本为最新稳定版。镜像选择redis:7.2约 130 MB和nginx:1.27约 110 MB分别从几个可用镜像源拉取记录消耗时间结果如下镜像源拉取 redis:7.2拉取 nginx:1.27整体感受直连 Docker Hub超时/断开超时/断开基本拉不动docker.m.daocloud.io约 8 秒约 6 秒速度最快缓存命中率高docker.1panel.live约 12 秒约 10 秒可用速度中上docker.xuanyuan.me约 20 秒约 15 秒可用偶尔等待docker.1ms.run约 14 秒约 12 秒可用备用首选docker.mirrors.ustc.edu.cn连接失败连接失败在我这边已失效需验证hub-mirror.c.163.com约 25 秒约 18 秒能用但性能明显不如公益源这个数据只是我本地网络的参考不代表所有地区。不过它可以说明一个趋势社区维护的公益源目前可用性好高校镜像站反而不一定都能用因为高校镜像站更多面向校园网对外带宽有限且部分学校已经逐步收缩对 Docker Hub 的镜像服务。4.2 不同人群的选型建议个人开发者和学生优先用docker.m.daocloud.io作为第一个源搭配docker.1panel.live做备选。这两个源在国内社区讨论度最高出问题时修复也比较及时。小团队或公司内部开发环境我还是建议配一个自建的镜像缓存服务比如用 Harbor 或 Docker Registry 做内网拉取。公共镜像源虽然方便但你不知道它什么时间点会出问题团队协作场景下几十个人同时拉同一个镜像一旦公共源限流所有人一起遭殃。内网缓存才是长期解法公共源只是在过渡期和个人的环境里用。如果服务器在境外或者靠近香港地区其实可以不用折腾镜像源直连 Docker Hub 就很快。这个判断很简单你先用docker pull拉一个小镜像如果一分钟内能拉完就不需要配镜像源如果等了两分钟还在转圈再配也不迟。5. 用镜像源完成几个高频实战场景5.1 拉取并运行 MySQL 8.0配好镜像源之后最直观的收益就是拉取数据库这类几十 MB 甚至几个 GB 的镜像变得非常快。以 MySQL 8.0 为例docker pull mysql:8.0拉取完成后运行并设置初始密码docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD你的密码 \ --restartalways \ mysql:8.0再进入容器检查是否正常运行docker exec -it mysql8 mysql -uroot -p这里有几个实际经验想提醒一下第一MYSQL_ROOT_PASSWORD只是初始化密码如果你之后挂载了数据卷这个变量就只在第一次启动时生效第二生产环境一定要加--restartalways不然服务器重启后 MySQL 不会自动拉起第三字符集建议在启动参数中加上--character-set-serverutf8mb4否则默认字符集在中文场景下很容易出现乱码。5.2 用 Docker Compose 搭建 Redis 主从Redis 主从是很常见的场景很多人会在网上找别人写好的 compose 文件结果因为镜像拉不下来一直起不来。现在镜像源配好了可以直接用下面这个文件在目录里保存为docker-compose.ymlservices: redis-master: image: redis:7.2 container_name: redis-master command: redis-server --requirepass redis123 ports: - 6379:6379 restart: always redis-slave: image: redis:7.2 container_name: redis-slave command: redis-server --replicaof redis-master 6379 --masterauth redis123 depends_on: - redis-master restart: always在文件所在目录执行docker compose up -d这就完成了 Redis 主从搭建。验证是否同步成功进入从节点docker exec -it redis-slave redis-cli -a redis123 info replication如果看到role:slave并且master_link_status:up就说明主从关系正常。需要注意Redis 5.0 之后已经不推荐使用slaveof命令建议用replicaof新版镜像里直接用replicaof更稳妥。5.3 拉取 Ollama 镜像部署本地模型服务最近身边的同事都在搞本地 AI 应用Ollama 是部署本地模型的常用方案但ollama/ollama镜像本身也在 Docker Hub 上直连同样拉不动。镜像源配好之后直接拉取docker pull ollama/ollama然后启动docker run -d \ --name ollama \ -v ollama:/root/.ollama \ -p 11434:11434 \ --restartalways \ ollama/ollama这里需要区分两件事Ollama 镜像本身的拉取走的是 Docker 镜像源而进入容器后执行ollama run qwen2.5下载模型文件时走的是模型下载通道和 Docker 镜像源不是同一个体系。如果你拉模型慢需要单独配置模型源的镜像比如在容器内设置HUGGING_FACE_HUB_TOKEN或者使用国内模型镜像站这属于另一个话题。但至少把ollama/ollama容器拉下来这个步骤镜像源能解决绝大部分问题。5.4 Docker 青龙面板拉取与依赖安装加速青龙面板这名字熟悉的人比较多很多朋友会在家里的软路由或 NAS 上部署。拉取镜像docker pull whyour/qinglong:latest或者直接用镜像源地址临时拉取方法是在镜像名前加上镜像源前缀docker pull docker.m.daocloud.io/whyour/qinglong:latest拉完再手动打标签docker tag docker.m.daocloud.io/whyour/qinglong:latest whyour/qinglong:latest这种“加前缀”的临时方案适合那些已经配置好镜像源但某些镜像还是拉不下来的情况相当于强制让它走指定源非常实用。青龙面板跑的脚本经常需要各种 npm 依赖和 Python 依赖有些依赖仓库同样不在国内装依赖慢或者装不上时可以在容器里把 npm 源切换到 npmmirror 镜像把 pip 源切换到清华镜像。这一步和 Docker 镜像源是两套体系但都属于“国内镜像加速”的范畴一起配好才能让整个面板真正顺畅跑起来。6. 配置镜像源之后的常见坑与排查技巧6.1 daemon.json 写错Docker 直接起不来这是最容易被新手踩的坑。daemon.json是一个严格符合 JSON 格式的文件多一个逗号或少一个引号都会导致 Docker 启动失败。如果你改完配置后执行systemctl restart docker发现服务起不来先别急着还原文件用下面这个命令看看日志journalctl -u docker -n 50如果日志里出现unable to configure the Docker daemon with file /etc/docker/daemon.json: invalid character之类的提示基本就是 JSON 格式问题。解决办法很简单把文件放到任意一个 JSON 在线校验工具里或者用 Python 校验python3 -m json.tool /etc/docker/daemon.json没有报错就说明格式没问题再重启 Docker。6.2 配置了镜像源但 docker pull 感觉没走镜像源有一种情况是配置已经生效但 docker pull 确实没有走镜像源常见原因是镜像源不支持多架构Manifest List。比如你在一台 ARM 机器上拉取 x86 架构的镜像Docker 会去镜像源请求多架构索引如果镜像源不支持就会跳过镜像源回落到 Docker Hub结果还是慢。判断方法很简单docker pull时输出里如果有falling back to the local registry或者明显等待很久多为漏斗问题。解决办法是换一个支持多架构的镜像源或者直接用带架构后缀的镜像标签。另一种情况是根本没有重启 Docker。改完/etc/docker/daemon.json必须systemctl restart dockerDocker Desktop 必须 Apply Restart这一步漏了配置永远只停留在文件里。6.3 镜像源返回 401 / 502 / 超时返回 502 或超时基本可以判定这个镜像源当前不可用换源即可。返回 401 反而可能是正常的因为前面说过/v2/接口本身要求认证。但如果你在docker pull阶段看到 401说明镜像源接到了请求但拒绝为这个镜像回源一般是镜像源只开放了白名单镜像或者已经停止回源这时候也只能换源。我个人的习惯是每个季度用开头的curl -I 镜像源/v2/命令把所有备选源检查一遍然后把不可用的从配置里剔除补上新的地址顺便更新到团队文档里。这份列表看起来是静态的实际上每个月都在变不维护等于没配。6.4 容器运行时不同镜像加速配置位置也不同Docker 和 Kubernetes 底层的容器运行时现在已经越来越多样化。如果你用的是纯 Docker 环境配置就在/etc/docker/daemon.json如果你用的是 containerd配置方式完全不同如果用的是 Podman又有自己的一套配置。这篇内容里列的registry-mirrors只对 Docker 生效。很多人在 K8s 节点上改了 docker 的 daemon.json发现 kubelet 拉镜像还是慢就是因为 kubelet 用的是 containerd 或 CRI 运行时需要单独配置/etc/containerd/config.toml。这个不展开太多但要记住改配置之前先确认你的环境到底用的什么运行时。6.5 注意镜像供应链安全最后说一个容易被忽略的点镜像源本质上是“第三方替你拉取和转发镜像”这本身就意味着你会把拉取请求交给第三方处理。所以我只建议从长期维护、口碑透明的镜像源拉取公共镜像不要随便用一些来源不明的个人地址尤其是在生产环境。拉取镜像时可以留意 digest 值比较关键的生产镜像最好通过docker pull后再用docker inspect校验签名和 digest 是否和官方一致。镜像源加速是解决下载速度问题的工具但不应以牺牲供应链安全为代价。7. 最后分享几点我的个人使用体会我实际用了快四年国内镜像源最大的体会是不要相信任何“长期有效”的列表包括我这份。镜像源生态一直处于动态变化中旧地址关闭、新地址出现都是常态。我自己的做法是维护一张小表格把备选源地址、验证日期、当前状态、最近一次拉取结果记下来每个月顺手跑一遍验证命令比每次等到拉不动了再去网上翻帖子高效得多。另一个建议是公共镜像源和自建缓存最好分场景使用。个人电脑、学习环境、临时实验用公共镜像源足够生产环境或几人以上的团队尽早部署一层内网镜像缓存。Harbor 就是不错的选择把外部镜像先同步到内网所有节点从内网拉取既快又可控。公共源解决的是“能不能拉下来”的问题自建缓存解决的是“持续稳定获取”的问题。如果你现在还在被 Docker 镜像下载慢折磨我的建议很简单先按文中方法配上一个主选源和一个备选源跑通docker pull让日常工作先顺畅起来之后再慢慢完善你专属的镜像源维护机制。这个列表会过期但配置方法和排查思路不会掌握了自己动手验证的能力以后遇到任何新镜像源都能很快判断它到底能不能用。