这两天刚好有朋友问我，2026 年了，到底还有哪个 Docker 镜像源能稳定用？这个问题我几乎每个月都会被问一次。今天直接把我整理到 9 月 11 日这一版的国内 Docker 镜像源加速列表放出来，顺手把配置方法、验证方式、日常踩坑全部写清楚，省得大家到处翻旧教程。
先对齐一下场景：你敲下docker pull nginx:latest，进度条半天不动；你在服务器上第一次docker run hello-world，等到超时；你装了 Docker Desktop，刚启动就报virtualization support not detected。这些问题，往小了说是网络慢，往大了说就是镜像源没配好。这篇文章适合所有用 Docker 的人——新手照着配置可以少踩一半坑，老手可以直接对照速查表换掉失效地址，不用再一条条试。
1. 先说清楚：Docker 镜像加速到底在解决什么问题
1.1 拉一个镜像到底慢在哪一步
一条docker pull命令发出去之后，Docker 默认会去 Docker Hub 的官方仓库拉取镜像。Docker Hub 是当前使用最广泛的公共镜像仓库，但它的服务节点主要部署在海外区域，从国内直连时，跨地域访问会造成高延迟、高丢包。镜像文件本身又是由一层一层的 Layer 组成的，每一层都要完整下载，遇到几个 GB 的大镜像，拉取时间会被放大得非常可怕。
这里要澄清一个观点：很多时候并不是你本地宽带慢，也不是 Docker 安装有问题，而是网络路径太长。我拿同一台服务器做过对照测试，配置镜像源之前拉取mysql:8.0，经常等了一分多钟才到下载阶段，甚至直接报net/http: request canceled；配置后再拉，最快的几秒钟就能看到Downloaded newer image。这种差距，谁用谁知道。
1.2 镜像源加速的原理：Registry Mirror
所谓镜像源，专业称呼是Registry Mirror，也就是仓库镜像。它不是把 Docker Hub 整个搬到你的旁边，而是一个只读缓存代理。你在daemon.json里配置好registry-mirrors之后，执行docker pull时，Docker 引擎会优先向镜像源发起请求。如果镜像源里已经有缓存，直接返回缓存结果；如果没有缓存，它会替你去 Docker Hub 拉取，存一份再返回给你。
用一句话概括：你本来需要自己去总仓排队取货，镜像源就是本地分销点，常见的nginx、mysql、redis、ubuntu这些镜像它那里都有“现货”，所以速度差距才会这么大。这也是为什么配置镜像源之后，拉热门镜像基本能做到秒级完成。
1.3 配置入口 daemon.json 是什么
Docker 服务端（dockerd）的配置文件叫daemon.json，默认路径在/etc/docker/daemon.json。里面有很多字段，比如>sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": [ "https://你的ID.mirror.aliyuncs.com", "https://mirror.ccs.tencentyun.com", "https://docker.m.daocloud.io" ] } EOF sudo systemctl daemon-reload sudo systemctl restart docker
命令里的https://你的ID.mirror.aliyuncs.com一定要替换成实际领取到的专属地址，否则 Docker 会去请求一个不存在的域名，加速自然不生效。
还有一个容易被忽略的细节：如果你的daemon.json之前已经存在，比如里面配置了>docker pull mysql:8.0
镜像拉下来之后，运行一个最简单的单机实例：
docker run -d --name mysql8 -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=YourPass123 \ -e MYSQL_DATABASE=test \ mysql:8.0这里解释一下参数：-d表示后台运行，--name指定容器名，-p 3306:3306把宿主机的 3306 端口映射到容器内 3306，-e则是设置环境变量。MySQL 容器首次启动需要初始化数据目录，不会瞬间就绪，可以用docker logs mysql8查看日志，看到ready for connections就说明起来了。
经常有朋友问，为什么数据库数据会丢。因为这里没有挂载数据卷，容器删了数据就没了。生产环境一定要加-v /你的数据目录:/var/lib/mysql，把 MySQL 的数据文件放到宿主机持久化目录里。
3.5 实战：使用 Docker Compose 部署 Redis 主从
镜像源配好之后，主从这种组合部署就会顺手很多。下面是一个可以直接用的 Redis 主从docker-compose.yml。
services: redis-master: image: redis:7.2 container_name: redis-master command: ["redis-server", "--appendonly", "yes"] ports: - "6379:6379" volumes: - redis-master-data:/data redis-slave: image: redis:7.2 container_name: redis-slave command: ["redis-server", "--appendonly", "yes", "--slaveof", "redis-master", "6379"] ports: - "6380:6379" volumes: - redis-slave-data:/data volumes: redis-master-data: redis-slave-data:在文件所在目录执行docker compose up -d，两个容器会加入同一个默认网络，服务名redis-master可以直接被从节点解析到。验证主从是否正常：
docker exec -it redis-slave redis-cli -p 6379 info replication看到master_link_status:up就代表主从链路已经连通。需要提醒的是，这只是一个最基础的主从拓扑，生产环境如果开启了requirepass，主从之间还要同步配置masterauth，否则从节点会一直报同步失败。
4. Docker 日常使用中高频踩坑问题
4.1 配置了镜像源拉取还是很慢怎么办
镜像源不是万能的，配置之后依然很慢的情况我也遇到过。
先确认配置本身有没有生效，用docker info检查 Registry Mirrors。接着检查镜像源地址是否真的可以连通，直接执行：
curl -I https://mirror.ccs.tencentyun.com/v2/如果返回非 200 或直接超时，说明这个镜像源已经不可靠，需要换一个。
还有一种可能：你拉取的镜像太冷门，源里没有缓存，第一次拉取时镜像源能做的只是替你去原始仓库拉，速度并不会快很多。遇到这种情况，除了多等等，也可以用临时前缀方式应急。
docker pull docker.m.daocloud.io/library/mysql:8.0 docker tag docker.m.daocloud.io/library/mysql:8.0 mysql:8.0但这样操作后，后续直接使用mysql:8.0标签也没有问题，只是每次都要手动拼前缀，自动化脚本里会比较麻烦。
4.2 Docker Desktop 启动失败：virtualization support not detected
Windows 上安装 Docker Desktop，最经典的报错就是virtualization support not detected。原因基本都指向同一类：CPU 虚拟化没有开启，或者系统级的虚拟化功能没有启用。
解决步骤按顺序来。第一步，重启电脑进入 BIOS/UEFI，找到Intel Virtualization Technology或AMD-V，改成 Enabled，保存退出。第二步，以管理员身份打开 PowerShell，执行wsl --install，把 WSL2 完整安装，再执行wsl --update。第三步，在 Windows 的“启用或关闭 Windows 功能”里，勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。全部完成后再启动 Docker Desktop。
如果是 Mac，Apple Silicon 芯片和 Intel 芯片的虚拟化机制略有不同。出现类似报错时，先检查 Docker Desktop 是否选择了正确的虚拟化框架，再确认系统 BIOS 里有没有嵌套虚拟化开关。
4.3 常见的 Docker 权限错误
permission denied while trying to connect to the Docker daemon socket这条报错，是我在教学场景里看到最多的问题。原因是当前用户不在docker用户组里，没有权限访问/var/run/docker.sock。
快速解决：
sudo usermod -aG docker $USER newgrp docker执行完重新连接终端或者重新登录一次，再执行docker ps就不会有权限问题了。如果系统提示docker组不存在，先执行sudo groupadd docker。
我不推荐用chmod 777 /var/run/docker.sock来解决，因为这是让所有用户都能控制 Docker，权限放得太宽，安全风险很大。
4.4 我平时常用的 Docker 命令速查
镜像源配置只是第一步，日常管理容器还需要一套顺手的命令。下面是我高频使用的一张速查表。
| 使用场景 | 命令 |
|---|---|
| 拉取镜像 | docker pull 镜像名:标签 |
| 查看本地镜像 | docker images |
| 运行容器 | docker run -d --name demo -p 8080:80 nginx |
| 查看运行中容器 | docker ps |
| 查看所有容器 | docker ps -a |
| 进入容器 | docker exec -it demo bash |
| 查看日志 | docker logs -f demo |
| 删除容器 | docker rm -f demo |
| 删除镜像 | docker rmi 镜像ID |
| 清理悬空资源 | docker system prune -f |
| 查看资源占用 | docker stats |
| 构建镜像 | docker build -t demo:v1 . |
| compose 启动 | docker compose up -d |
| compose 停止 | docker compose down |
参数记不住没关系，但docker ps -a和docker logs -f这两个一定要形成肌肉记忆。排查故障时，90% 的问题都要靠这两条命令定位。
5. 镜像源列表之外的一些实在建议
5.1 专属源优先，公共源当备胎
整理这份列表的过程中，我最大的感受是：公共源确实方便，但把生产环境押在一个社区维护的公共源上，风险太大。我个人的习惯是阿里云专属地址永远是第一选择，它带着账号识别，虽然也有配额和限速，但比公共源稳定太多。公共源只适合临时测试、备用切换，不适合作为唯一依赖。
如果你的使用场景是团队开发或者生产集群，可以考虑自建镜像仓库，比如用 Harbor 做内网分发。这样开发者把镜像推到内网仓库，服务器从内网拉取，速度最快，也不受外部源状态影响。
5.2 配合使用小型基础镜像和定期清理
镜像源加速解决的是“拉得动”的问题，而“拉得快不快”还取决于镜像本身大不大。我见过很多项目，基础镜像选的是完整版系统镜像，动辄几个 GB，换一个alpine版本直接缩到几十 MB。日常开发中，把nginx:latest换成nginx:alpine、把python:3.12换成python:3.12-alpine，效果立竿见影。
另外我会定期执行docker system prune -f，清理掉那些悬空镜像和停止的容器。磁盘空间一紧张，Docker 性能会明显下降，很多人没往这个方向想。
5.3 每个季度整理一次地址
镜像源地址是有生命周期的，今天列出来的地址，可能过几个月就有变化。我的做法是每隔一段时间手动验证一遍常用源，用curl -I探测一下地址是否还能返回有效响应，有异常就更新配置。
如果你在实际使用中发现了更好的镜像源，或者某个源已经失效，也可以在评论区告诉我。这些信息靠一个人维护是不够的，大家一起验证才能让这份列表保持新鲜。这篇就先写到这，希望对正在折腾 Docker 的你有点帮助。