企业官网建设流程全解析

如果你最近在折腾 Docker，不管是装 Docker Desktop、拉镜像跑 MySQL、Redis、GitLab，还是用 Ollama 跑本地模型，大概率都会撞上同一个问题：docker pull卡在waiting，或者直接报timeout。

我这份 2026 年 9 月 13 日更新的 Docker 国内镜像源加速列表，就是干这个用的。里面的地址都是我近期实际拉取镜像验证过的，不是网上随便抄的“老黄历”。本文会把这些地址、配置方法、验证命令、踩坑记录一起整理出来，方便你直接照抄。

需要说明一点，下面说的“镜像加速”，指的是通过国内可访问的公共镜像仓库做镜像拉取加速，减少访问境外仓库时的网络延迟，这是 Docker 官方也提供的标准配置方式。本文不涉及任何非正常手段，只讲在合规网络环境下怎么把 Docker 用顺。

1. 现状与思路：为什么需要一份“可用”的加速列表

1.1 2026 年了，docker pull 为什么还是个老大难

很多新手会觉得，Docker 装好之后就能随便拉镜像，其实不是这样。Docker Hub 本身是国外的公共镜像仓库，默认情况下，你执行docker pull nginx:latest时，Docker 会直接访问 Docker Hub 官方服务器。

问题就出在物理距离和网络链路上。跨境的公共网络连接本身就不稳定，尤其是高峰时段，丢包和延迟会非常明显。我实测拉一个不到 100MB 的镜像，直接连 Docker Hub，经常要 5 分钟以上，中间还可能断掉重试。如果是几百 MB 甚至 GB 级别的镜像，比如 GitLab、MySQL 8、常用 AI 模型运行环境，那基本等于不可用。

这就是“镜像加速器”存在的理由。它的原理不复杂：你在国内搭建一个 Docker Hub 的镜像缓存节点，或者直接托管常用的公共镜像，用户把 Docker 的registry-mirrors指向这个节点，拉镜像时 Docker 会从这个国内节点下载，速度自然快几个数量级。Docker 官方在daemon.json里预留了registry-mirrors这个配置项，同时支持配多个地址，拉不到会自动切换。

1.2 “可用”二字的价值：列表不是抄来的，是试出来的

网上搜“Docker 国内镜像源”，能搜出一大堆列表，但很多已经不能用了。原因很简单：公共镜像加速服务是纯公益性质的，运营方需要承担带宽、存储、维护成本。一旦某个地址长时间没人维护，或者访问量太大扛不住，就会失效。我前阵子帮一个朋友排查 Docker 拉镜像失败，他照着 2023 年的一篇老文章配了三个加速地址，结果三个全是死链。

这份列表的更新日期是 2026 年 9 月 13 日，每一个地址我是怎么验证的？很简单，逐个配置到daemon.json里，然后docker pull一个不是特别冷门的镜像，比如alpine:3.19和nginx:stable，看能不能在合理时间内拉下来。能拉下来、速度快的，保留；拉不下来的，直接剔掉。这个验证流程看着土，但最靠谱。

2. 我实测整理的加速地址与配置方法

2.1 当前实测可用的镜像加速地址

下面是我验证过、在 2026 年 9 月 13 日还能正常工作的加速地址。表格里写的“说明”是实测下来的体感，不是官方文档的描述：

还有一个比较特殊的方向，就是一些云平台自带的加速器，比如阿里云、腾讯云的个人加速地址。这两家的地址不是通用的，需要你登录容器镜像服务控制台，在“镜像加速器”页面里查看你专属的地址，格式一般是https://xxxx.mirror.aliyuncs.com。这类地址因为带宽大，稳定性极高，我个人建议优先配置。

配置的时候，不要在daemon.json里只填一个地址。Docker 对registry-mirrors支持多地址列表，拉镜像时如果一个地址失败会自动尝试下一个。我一般会配 3 到 4 个，一个云厂商专属地址打底，加上两个公共地址冗余。

2.2 配置 Docker Engine（daemon.json）的标准姿势

不管你是 Windows、macOS 还是 Linux，Docker 的加速配置最终都会落在daemon.json文件上，Linux 默认路径是/etc/docker/daemon.json。如果这个文件不存在，直接新建一个就行。

下面是我在自己服务器上用的配置示例：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.net", "https://docker.nju.edu.cn", "https://docker.xuanyuan.me" ], "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } }

注意，daemon.json本身是标准的 JSON 格式，如果格式写错，Docker 服务会直接启动失败。我之前见过有人把注解写进 JSON，或者引号用了中文字符，导致整个 Docker 起不来。改完文件一定要用命令验证一下格式：

cat /etc/docker/daemon.json | python3 -m json.tool

这个命令如果输出正常的格式化 JSON，说明语法没问题。如果报错，python3 -m json.tool会精确指出哪一行有问题。

改完配置后，重启 Docker 让配置生效：

sudo systemctl daemon-reload sudo systemctl restart docker

注意顺序：先daemon-reload再restart docker。绕过一步，有时配置不会生效。

2.3 Docker Desktop 图形化配置路径

用 Docker Desktop 的同学不用去手动编辑daemon.json，直接操作界面就行。打开 Docker Desktop，进入Settings，在左侧菜单找到Docker Engine，你会看到一个编辑框，里面就是daemon.json的内容，默认只有一行{}或者一点点基础配置。

把下面的内容复制进去：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.net", "https://docker.nju.edu.cn" ] }

点击Apply & Restart，Docker Desktop 会用新配置重启。这里有个体验细节：如果 Docker Desktop 当前没启动，改配置前要先把 Docker Desktop 打开；如果改完配置后一直转圈重启不了，可以点击右下角 Docker 图标，选择Restart，一般能恢复。

macOS 的 Docker Desktop 路径完全一样，Windows 上也是一样的界面，不用区分系统。不过在 Windows 上如果你用的是 WSL 2 后端，里面如果自己装了 Docker Engine（比如 WSL 的 Ubuntu 发行版里单独装的 docker-ce），那是另一套配置，需要回到 2.2 节的方法去改/etc/docker/daemon.json。

3. 配置后的验证与常用操作技巧

3.1 如何确认加速源真正生效

配置完不代表加速就一定生效了，必须验证。最简单的验证方法是执行：

docker info

在输出的信息里，能看到Registry Mirrors这一项。它会列出你配置的所有加速地址，如果这一项是空的，说明配置没生效。如果列出了地址，但后面还有一长串描述，比如https://docker.m.daocloud.io/，那是正常的。

接下来用实际拉取来验证速度。我习惯用alpine:3.19做测试，因为这个镜像很小，只有几 MB：

docker pull alpine:3.19

拉取成功后，看一下输出的耗时。如果从国内加速源拉取，几 MB 的镜像应该几秒钟就完成。再试一个稍微大一点的：

docker pull nginx:stable

这个镜像大概几十 MB，如果配置生效，速度应该在 1 到 2 分钟内完成，超时就是配置有问题。如果你能把 Docker Hub 官方源和加速源都试一遍，对比会非常明显。我实测同一个镜像，官方源可能 5 分钟还在waiting，加速源 30 秒就拉完了。

3.2 常用 Docker 命令与镜像管理

加速源配置好之后，日常用得最多的还是那一套基础命令。这里我把高频命令梳理一下，给新手一个参考：

• docker search nginx：搜索镜像。注意，这个命令走的是 Docker Hub 的搜索接口，加速源对搜索结果影响不大。
• docker pull nginx:latest：拉取镜像，这是我们最常用到加速源的地方。
• docker images：查看本机已有镜像。
• docker rmi nginx:latest：删除镜像。
• docker run -d --name nginx-test -p 8080:80 nginx:latest：后台运行容器，并把本机 8080 端口映射到容器的 80 端口。
• docker ps：查看正在运行的容器。
• docker ps -a：查看所有容器，包括已停止的。
• docker logs -f nginx-test：查看容器日志，排错时最有用。
• docker exec -it nginx-test bash：进入容器内部操作。

说到批量操作，如果你要迁移环境，一次性拉很多镜像，可以用一个很简短的 shell 循环：

for img in nginx:stable mysql:8.0 redis:7.2 gitlab/gitlab-ce:17.0.0; do docker pull "$img" done

这比手动一条一条拉省事，而且配合多加速地址，即使某个镜像在第一个源上拉不到，Docker 会自动切换下一个源。

3.3 定制化场景：Ollama、GitLab、MySQL、Redis

现在很多人的需求不只是拉官方基础镜像，还有二次镜像的服务。比如最近很火的 Ollama，很多人想在国内网络环境下拉取模型运行环境镜像。Ollama 的官方镜像在 Docker Hub 上，正确配置好加速源后，docker pull ollama/ollama就能顺利完成。

还有几个我实际部署过的场景可以分享一下：

部署 MySQL 8.0

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=your_password \ -e MYSQL_DATABASE=test_db \ -v mysql_data:/var/lib/mysql \ mysql:8.0

这里我建议把数据目录挂载到 volume 里，不然容器一删，数据全没了。另外第一次启动时拉取mysql:8.0依赖加速源，配置好加速后大概几分钟就能完成。

部署 Redis 主从

先用docker pull redis:7.2拉好镜像，然后写一个简单的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", "--slaveof", "redis-master", "6379"] depends_on: - redis-master volumes: redis-master-data:

注意新版 Redis 的配置方式，slaveof命令在新版里已经被replicaof替代了，不过 Redis 7.2 还兼容老的slaveof。

部署 GitLab

GitLab 镜像比较大，好几个 GB，如果没有加速源几乎拉不下来。配置好加速后，执行：

docker run -d \ --name gitlab \ -p 8022:22 \ -p 8080:80 \ --restart always \ -v gitlab_config:/etc/gitlab \ -v gitlab_logs:/var/log/gitlab \ -v gitlab_data:/var/opt/gitlab \ gitlab/gitlab-ce:17.0.0

拉 GitLab 镜像时要有耐心，即使有加速源，几 GB 的镜像也要靠带宽和运气。我建议在拉之前先确认磁盘空间，用df -h看下，剩余空间至少要 20GB，不然拉一半可能缓存被清掉。

4. 常见问题与排查实录

4.1 docker pull 提示 timeout 或 TLS handshake timeout

这是最常见的报错，现象是在docker pull后长时间停在waiting，最后报错net/http: TLS handshake timeout或者dial tcp: lookup ...: i/o timeout。

这个问题的排查思路是“先定位是哪个地址的问题，再替换”。步骤是：

1. 检查当前daemon.json里配置的地址。
2. 逐个用curl测试地址是否通：

curl -sI https://docker.m.daocloud.io/v2/

如果返回200 OK或者401 Unauthorized，说明地址是通的。如果 curl 卡住或超时，说明这个地址当前状态不好，换一个。

3. 把失效的地址从daemon.json里移除，加上新的可用地址，重启 Docker。

有个容易忽略的点：Docker 的registry-mirrors配置是“按顺序尝试”的，如果第一个地址挂了，Docker 会等第一个地址超时后再试第二个。所以不要把明显不通的地址排在第一位，否则每次拉镜像都要先尴尬地等半天。

还有一种情况是服务商限速。公共加速源有时会对大流量下载做限制，表现就是前几十 MB 下载飞快，后续变慢甚至卡住。遇到这种情况，我一般的处理方法是等一会儿再试，或者干脆换一个源。

4.2 Docker Desktop 启动失败：虚拟化支持问题

Windows 上 Docker Desktop 最经典的问题就是启动时提示：Docker Desktop failed to start because virtualization support wasn't detected，或者在 Linux 容器模式下启动到一半退出。

这个报错的意思是 Docker Desktop 需要虚拟化技术支持。排查顺序如下：

1. 进任务管理器，在“性能”选项卡看 CPU 的虚拟化是否开启。
2. 到 BIOS/UEFI 里确认Intel VT-x或AMD-V已经开启。
3. 确保 Windows 的“Hyper-V”和“适用于 Linux 的 Windows 子系统”两个功能都启用。

启用方式是：控制面板 -> 程序和功能 -> 启用或关闭 Windows 功能，勾选Hyper-V和适用于 Linux 的 Windows 子系统。改完需要重启电脑。

如果你用的不是 Windows 专业版，而是家庭版，Hyper-V 功能可能默认没有，需要手动用 DISM 命令安装：

dism.exe /online /enable-feature /featurename:Microsoft-Hyper-V-All /all /norestart dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

装完重启，再启动 Docker Desktop 一般就能进。

4.3 镜像源失效后的快速处理

公共镜像源不稳定是常态，任何一份列表都有过期的一天。我这里分享一个我自己的处理方法。

前提是不要在一棵树上吊死。我的daemon.json里常年配置多个地址，即使某一个失效，其他地址会自动顶上，不会影响日常工作。

另外，我建议定期做一次“健康检查”。具体做法是：每个季度末，手动执行一遍docker pull测试，然后根据结果更新daemon.json。这种习惯比临时抓瞎强很多。如果有自动化学习的需求，还可以写一个简单的监控脚本，定期探测各加速地址的响应时间，把结果写进一个 HTML 报告里，方便查看：

import json import time import urllib.request mirrors = [ "https://docker.m.daocloud.io", "https://dockerproxy.net", "https://docker.nju.edu.cn", "https://docker.xuanyuan.me" ] for mirror in mirrors: try: start = time.time() req = urllib.request.Request(mirror + "/v2/", method="GET") urllib.request.urlopen(req, timeout=5) latency = int((time.time() - start) * 1000) print(f"{mirror} 可用 延迟 {latency}ms") except Exception as e: print(f"{mirror} 不可用 {e}")

这个脚本的逻辑很简单：探测每个地址的/v2/路径，能响应就算可用，顺便统计延迟。我把这个脚本放在 crontab 里每周跑一次，结果一目了然。

4.4 权限问题：docker 命令报 permission denied

Linux 上首次装完 Docker 后，执行docker ps可能会遇到：

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

原因是当前用户不在docker用户组里。解决方法是：

sudo usermod -aG docker $USER newgrp docker

newgrp docker是让当前终端会话立即生效，不然后要重新登录才能用。注意，把用户加入 docker 组等同于赋予该用户 root 级别的系统权限，因为 docker 组用户可以控制宿主机上的容器，生产环境要谨慎。

4.5 常见问题速查表

5. 从“能用”到“好用”的经验沉淀

镜像加速配置本身不复杂，真正影响体验的是细节。我这里分享几点我折腾下来的经验。

第一，加速地址不是越多越好。有人喜欢把能找的地址全填进去，结果一个地址超时，Docker 要等它超时后才尝试下一个，反而拖慢了整体速度。我的习惯是 3 到 4 个就够了，优先把最稳的放前面。

第二，不同场景可以配不同源。比如我在校园网环境下会用docker.nju.edu.cn作为第一优先，因为教育网的链路质量好；在普通家庭宽带下，就用云厂商的专属地址打底。这个结论不是固定的，建议你自己多试几个组合。

第三，如果公司内部有自建的 Harbor 或 Nexus 仓库，可以把公司仓库地址也加到registry-mirrors里。这样拉取公司内部镜像时不再多绕一道外网，速度提升会非常明显。

最后，再说一个容易忽略的小细节：daemon.json里还支持配max-concurrent-downloads，默认是 3，如果网络很好、带宽充足，可以把它调大：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.net" ], "max-concurrent-downloads": 6 }

这个参数控制的是同时下载的镜像层数。带宽够大的时候，从 3 调到 6，拉取大型镜像的体感速度会有明显提升。不过要注意，这个调大之后占用带宽也更高，如果你还要用网络做别的事，不一定划算。

以上这些经验，都是我在实际安装 Docker、配置加速、部署各种服务的过程中一点点攒下来的。有些问题网上也能查到，但查到的答案往往只给命令，不讲为什么，导致很多人依葫芦画瓢还是踩坑。希望这份列表和配置过程能帮你少走点弯路。