企业官网建设流程全解析

镜像加速这件事，真的是每年都要重新折腾一遍。9月10日我本来只想拉一个 nginx 最新镜像做测试，结果又看到群里有人发 docker pull 卡在 waiting 的截图，干脆把手头能想到的、网络上流传比较广的几十个国内镜像源全部重新实测了一遍，整理成这份 2026 最新可用的 Docker 国内镜像源加速列表。如果你在用 Docker Desktop、Linux 服务器、unraid、群晖，或者最近在折腾 ollama、comfyui 这类 AI 工具镜像，这篇文章应该能帮你省下不少时间。

我先把结论放在前面：目前最稳的三个源，依然是 docker.m.daocloud.io、docker.1panel.live 和 hub.rat.dev。但镜像源这个东西没有“永久可用”的说法，前几年大家都在用的 dockerproxy.com，现在基本已经废了；网易 163、百度等大厂的公共源也早就不更新。所以这篇列表我不敢保证半年后还全有效，但至少截至 9 月 10 日测试的结果，下面这些源是可以直接用的。

1. 镜像加速到底是什么，为什么动不动就失效

1.1 一条 docker pull 命令背后发生了什么

很多人配置镜像加速，就是把 daemon.json 里的 registry-mirrors 填上几个地址，然后重启 Docker。但真正遇到问题的时候，很少有人说得清它到底是怎么工作的。

默认情况下，docker pull 拉的是 Docker Hub 官方仓库，也就是 registry-1.docker.io。国内直连这个地址，链路状况大家应该都有体会，经常是连接超时、TLS 握手卡住、下载到一半 progress 不动。配置 registry-mirrors 之后，Docker daemon 会优先请求你填的镜像源地址。镜像源本质上是一个 Docker Registry v2 的代理服务，你 pull 镜像的时候，它会先看看自己本地缓存里有没有对应层，有就直接返回；没有就从上游 Docker Hub 回源拉取，拉完缓存下来再给你。

这个机制可以理解成你家离超市太远，于是你在楼下开了个小卖部。小卖部定期从超市进货，你买东西直接去楼下就行。问题在于，这个小卖部如果老板不干了、货架空了、或者进货渠道被掐断了，你的购物体验立刻回到原点。

这里有一个很容易踩的误区：加速器只对 Docker Hub 上的镜像生效。如果你拉的是 gcr.io、quay.io、ghcr.io 这些第三方 registry 的镜像，就算在 daemon.json 里填一百个加速源也没用。很多人在配置完加速后，发现某些镜像还是拉不动，就是因为这个原因——它根本不在加速器的服务范围内。

1.2 公共镜像源为什么总在失效

我整理列表的时候统计了一下，近几年失效的公共镜像源大致分三类。

第一类是流量成本扛不住。镜像代理是个很吃带宽和存储的服务，尤其是一些热门镜像，比如 nginx、mysql、python、pytorch，动不动几个 GB 的层，下载量一大，服务器流量费就蹭蹭上涨。很多个人维护的镜像站，早期是凭热情在做，等流量上来之后发现成本远超预期，只能关停或者限流。

第二类是合规和稳定性原因。代理 Docker Hub 涉及到镜像内容的分发，国内对镜像仓库的监管要求一直在收紧，有些服务商为了避免麻烦会主动停止公共加速服务。这是很多人不愿意明说但真实存在的因素。

第三类是维护精力跟不上。镜像加速不像普通网站，挂了之后需要有人持续盯着、更新证书、处理回源异常。很多源一开始响应很快，维护者忙起来之后就不怎么管了，慢慢地接口还在，但实际拉取效率极低，甚至直接超时。

1.3 为什么强烈建议配置多个镜像源

Docker daemon 的 registry-mirrors 配置是可以填多个地址的，形式是一个数组。它的切换逻辑是：Docker 会按顺序尝试访问，第一个源如果不可用或超时，会自动切换下一个。所以配置多个源，本质上是在做冗余。

但切换逻辑并不完美，实际测试下来，有些版本在第一个源超时的时候会等很久，而不是立刻 fallback。这也是为什么我建议把最稳定的源放在第一位，而不是随便填。另外，镜像源之间缓存的数据可能不一致，同一个镜像 tag 在不同源拉下来的 digest 不一定会完全相同，当然正常的镜像源都会严格按 digest 同步，不会给你返回错误内容。

我自己的习惯是维护三个源，一个主源，两个备用源，这样即使某天主源挂了，docker pull 还能自动走备源，不至于完全不能干活。

2. 2026年9月10日实测可用的国内镜像源列表

2.1 当前推荐的一线源

这是这次测试中表现最稳定、回源速度最快的一批，建议优先使用。

注意，以上源我用的是https://docker.m.daocloud.io这种带 https 的完整地址。有的教程里写的是没有协议头的裸域名，这种配置 Docker 不一定认。在 daemon.json 里写 registry-mirrors 时，务必把https://写完整。

2.2 备用源与历史源参考

下面这些源，有的还能用，但存在各种限制；有的已经彻底失效，我把它们列出来主要是帮你避坑，防止自己在网上搜到一堆旧教程照着配置。

这里多说一句，高校镜像站虽然常年被推荐，但它们本质上是给校内师生用的，公网访问往往有权限限制或者流量控制。如果你在校园网环境里，可以优先试试；如果是普通家庭宽带或企业网络，就不要把高校源作为主力了。

2.3 测试源可用性的几条命令

在把某个源配置进 daemon.json 之前，我建议先用下面的命令看一眼它是不是活着。

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://docker.m.daocloud.io/v2/

如果返回200或401，都说明服务活着。401是正常的，因为 Registry v2 协议对匿名访问会要求认证，但它已经证明服务在响应。如果返回000、502、404，基本就可以放弃这个源了。

更直观的测试是直接拉一个很小的镜像，比如 busybox：

docker pull docker.m.daocloud.io/library/busybox:latest

这里我用了一个比较取巧的拉取方式，直接把加速域名当作镜像前缀来用。这样即使 daemon.json 还没有配置 registry-mirrors，也能单独测试某个加速站是不是真的能拉通。

3. 实操：不同环境下配置镜像加速

3.1 Linux 服务器上的标准配置方式

Linux 上配 Docker 镜像加速是最简单的，核心就是修改/etc/docker/daemon.json。

先看一下你这个文件里现在有没有内容：

sudo cat /etc/docker/daemon.json

如果之前没改过，很可能是文件不存在或者只有个{}。那我建议直接写入下面这份配置：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://docker.1panel.live", "https://hub.rat.dev" ] }

如果文件里已经有一些配置，比如>sudo systemctl daemon-reload sudo systemctl restart docker

重启之后验证配置是否生效：

docker info | grep -A5 "Registry Mirrors"

正常会看到你填的三个地址。如果这里还是空的，说明 daemon.json 路径不对，或者 Docker 服务没有真正重启。还有个常见问题是 SELinux 或者 AppArmor 拦截了 Docker 读取配置文件的权限，这种情况下需要检查系统日志。

3.2 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://hub.rat.dev" ] }

然后点击 Apply & Restart，等待 Docker Desktop 重启完成。

这里有两个坑。第一，Docker Desktop 的编辑框会保存你之前设置的其他参数，所以你要做的是在原有 JSON 基础上追加 registry-mirrors，而不是把整个内容删掉换成上面这段。第二，如果你在 Windows 上，Docker Desktop 启动本身就依赖 WSL2 和虚拟化功能，如果这层没通，你连配置界面都进不去。这个问题我在下一节会详细讲。

macOS 上如果之前从没装过 Docker Desktop，注意芯片类型会影响安装包选择，Apple Silicon 和 Intel 的安装包不一样，别下错了。

3.3 unraid 和群晖的配置差异

nas 上用 Docker 的用户越来越多，unraid 和群晖的配置方式跟普通 Linux 不太一样，单独拿出来说。

unraid 的话，在 Web 管理界面进入 Docker 页面，展开高级视图，会看到一个 Registry Mirrors 的配置框。把你需要的加速地址按行填进去，多个地址一行一个，然后点击 Apply。这一步很关键：unraid 会提示需要重启 Docker 服务，所有容器会短暂停止，你要确认当前没有重要的任务在跑。

很多 unraid 用户遇到“配置了镜像加速还不能拉取镜像”的问题，就是因为点了 Apply 没有真正重启 Docker 服务，或者填完地址之后没有保存成功。建议在 unraid 的终端里跑一下：

docker info | grep -A5 "Registry Mirrors"

确认配置真的生效了。另外，unraid 的社区应用市场里很多模板直接填的是 ghcr.io 或 lscr.io 的地址，这些镜像不走 Docker Hub 加速器，你需要手动把仓库地址替换成对应可用的镜像站地址，这部分后面会提到。

群晖的配置路径是：Docker（或 Container Manager）-> 注册表 -> 设置 -> 新增，填入加速源地址。群晖的问题在于界面比较友好，但排查手段少，建议通过 SSH 登录到群晖后台，用 docker info 检查实际生效情况。如果群晖上拉取超时，可以试试把加速源换成 docker.m.daocloud.io，这个源对 NAS 环境兼容性相对好。

3.4 containerd 和 Kubernetes 节点配置

现在很多生产环境用的是 containerd 而不是 Docker daemon，配置方式完全不同。如果你用的是 k8s，需要改的是/etc/containerd/config.toml。

在[plugins."io.containerd.grpc.v1.cri".registry.mirrors]下面，配置 docker.io 的 endpoint。找一下配置文件里有没有类似于：

[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://docker.m.daocloud.io", "https://docker.1panel.live"]

如果没有，就手动加。修改完成后重启 containerd：

sudo systemctl restart containerd

这里有一个很容易搞混的点：containerd 的配置结构和 Docker daemon 完全不一样，别把 daemon.json 的内容直接套过来。另外，有些发行版上 containerd 配置文件的路径可能不同，建议先containerd config default查看一下默认配置结构，再定位到对应层级修改。

3.5 拉取失败时的应急方案：前缀替换和离线迁移

不管配置多完整，总有意外情况。我给你的终极应急方案是：不用 registry-mirrors，直接用加速源的前缀来拉镜像。

比如我要拉 nginx:alpine，正常写的是：

docker pull nginx:alpine

加速失效时，可以改成：

docker pull docker.m.daocloud.io/library/nginx:alpine

拉完之后打回原来的 tag：

docker tag docker.m.daocloud.io/library/nginx:alpine nginx:alpine docker rmi docker.m.daocloud.io/library/nginx:alpine

这个做法的好处是它不依赖 daemon 配置，任何环境下都能用。坏处是每次拉新镜像都要手动改前缀，有点麻烦，而且有的加速源可能不支持非 library 仓库的镜像。

如果你需要在多台机器之间迁移镜像，还有一个离线方案。在一台能正常拉取镜像的机器上：

docker save nginx:alpine -o nginx-alpine.tar

然后把 tar 文件拷贝到目标机器：

docker load -i nginx-alpine.tar

这个方案在内外网隔离、离线部署的场景下特别好用，也是我每次给客户做私有化部署时的标准操作。

4. 常见问题与排查技巧实录

4.1 Docker Desktop 启动失败：virtualization support not detected

很多新手卡在第一步根本不是镜像加速的问题，而是 Docker Desktop 根本起不来。报错信息一般是Docker Desktop failed to start because virtualisation support wasn't detected之类。

这个报错的意思是，Docker Desktop 需要依赖 CPU 虚拟化，但系统层面没有开启或没有正确识别。

解决办法分几步：

1. 重启电脑，进入 BIOS/UEFI，找到 Intel Virtualization Technology（Intel VT-x）或 AMD SVM Mode，确认是 Enabled。
2. Windows 系统上，进入“控制面板 -> 程序 -> 启用或关闭 Windows 功能”，确认“虚拟机平台”和“适用于 Linux 的 Windows 子系统”这两项都勾选了。
3. 如果系统同时开了 Hyper-V，而 Docker Desktop 用的是 WSL2 后端，可能会产生冲突，可以尝试先关闭 Hyper-V，重启后再试。

踩过一次坑之后，我的经验是先确认 BIOS 虚拟化是否开启，再看 Windows 功能，这能解决 90% 的启动问题。还有一部分情况是电脑本身太老，CPU 不支持虚拟化，那就真没办法跑 Docker Desktop，只能用云服务器或者换机器。

4.2 配置了加速器还是拉取失败，怎么排查

如果你确认 registry-mirrors 已经写进配置、docker info 也能看到，但 docker pull 还是卡住，按下面的顺序排查。

先确认你拉的是不是 Docker Hub 镜像。如果 pull 的是gcr.io/xxx或quay.io/xxx，加速器完全不起作用，这是配置层面解决不了的问题，只能通过前缀替换的方式找对应源。

再测试你配置的加速源本身是不是活着。用前面提到过的 curl 命令，或者直接拉一个 busybox 试试。多个源同时失效的概率很低，一般总会有一个能通。

还有一种隐蔽的情况：Docker 版本过旧。老版本的 Docker 在处理多 mirror 切换时 bug 很多，可能第一个源超时就直接报错，不会继续尝试下一个。遇到这种情况，建议把最稳定的源放在第一位，或者升级 Docker 到较新版本。

4.3 镜像层下载到一半卡住或报错

这个问题在拉大镜像时尤其明显，比如 pytorch、comfyui、gitlab-ce 这些几个 GB 的镜像。

现象是下载进度条到某个百分比就不动了，或者报received unexpected HTTP status: 503、blob unknown之类的错误。

这种情况大多数是加速源回源失败，或者它的缓存和上游不一致。解决办法是：

1. 先 Ctrl+C 取消当前拉取。
2. 换一个加速源重试。我一般会从 docker.m.daocloud.io 切到 docker.1panel.live。
3. 如果还不行，看看镜像是否有更小的变体，比如 alpine 版本或者 slim 版本。

docker pull中断后，之前下载的层会以未完成状态保留在本地。虽然 Docker 会断点续传，但某些情况下缓存损坏会导致反复失败。可以执行：

docker system prune

把无用缓存清掉，重新拉取。注意这个命令不会删除正在使用的容器和镜像，但会把悬空镜像和无用的构建缓存清掉，生产环境操作前记得确认一下。

4.4 权限问题：permission denied while trying to connect to the Docker daemon socket

这个报错在 Linux 上太常见了，尤其是刚装完 Docker 用普通用户执行命令的时候。原因是当前用户不在 docker 用户组里。

解决办法：

sudo usermod -aG docker $USER

然后退出当前终端重新登录，或者执行newgrp docker刷新组权限。这里要注意，不要图省事给 /var/run/docker.sock 直接 chmod 777，那会带来严重的安全风险。

4.5 Windows 下的 failed to connect to the docker api 报错

这个报错原文是failed to connect to the docker api at npipe:////./pipe/dockerdesktop-linux。

它不是镜像源的问题，而是 Docker Desktop 的 Linux 引擎没有正常启动。排查顺序是：

1. 看 Docker Desktop 主界面是否处于 Running 状态，如果是 Starting 状态，等待一两分钟。
2. 如果一直 Starting，检查 WSL2 是否有异常。在 PowerShell 里执行wsl --status，确认默认发行版能正常启动。
3. 打开任务管理器，看 Vmmem 进程是否在运行，如果这个进程消失了，说明 WSL2 后端没起来。

通常重启 Docker Desktop 能解决大部分临时问题。如果还不行，执行wsl --shutdown，把 WSL2 整个停掉，重新启动 Docker Desktop。

4.6 unraid 配置了加速还不能拉镜像

这个我前面提过一点，这里展开说。

unraid 的 Docker 页面默认会从 Community Applications 安装模板，这些模板里填写的镜像地址五花八门，很多不是 Docker Hub 官方仓库，而是项目方自建的 registry。比如 linuxserver 系列镜像，仓库名是lscr.io/linuxserver/xxx，这种镜像加速器根本管不到。

解决思路是找到镜像的替代地址。很多项目会在自己的文档里提供多 registry 的拉取方式，优先从官方文档找；如果找不到，就在 unraid 终端里手动用替代前缀拉取，然后重新配置模板指向本地镜像。这个过程比较繁琐，但对 unraid 用户来说是最实用的。

4.7 容器网络导致的服务连接问题

经常有人在 Docker 里装完 mysql、redis 之后，发现宿主机上能连，但其它容器连不上，或者反过来。

这里有一个容易忽略的点：容器内访问宿主机服务，不能用 localhost，要用宿主机在 Docker 网络里的网关 IP。一般默认网桥的网关是 172.17.0.1，可以通过docker network inspect bridge查看。同理，宿主机要访问容器服务，需要使用容器映射出来的端口，而不是容器内部端口。

这个问题在部署达梦数据库、Web 应用和微服务的时候经常遇到。我之前帮同事排查一个容器内应用连不上外部达梦数据库的问题，最后发现就是连接串里写成了 localhost，改成宿主机局域网 IP 后立刻就好了。

4.8 ollama、comfyui 等 AI 工具的镜像加速

最近 ollama 和 comfyui 这类 AI 工具特别火，很多人问它们的镜像源是不是也在加速列表里。

先说 Ollama。Ollama 下载模型走的是它自己的模型注册服务，不是 Docker Hub，所以 Docker 镜像加速对它完全不生效。想加速 Ollama 模型下载，最靠谱的办法是从国内模型平台手动下载 GGUF 格式的模型文件，再用 ollama create 命令本地导入。这样做的好处是模型文件下载走的是国内 CDN，速度快且稳定，缺点是操作步骤比直接 ollama pull 多一点。

ComfyUI 就不一样了。很多 ComfyUI 的 Docker 镜像托管在 Docker Hub 上，镜像动辄几 GB，正好可以用加速源解决。我建议直接拉官方镜像的时候加上加速前缀：

docker pull docker.m.daocloud.io/orgs/comfyui/镜像名:版本

注意 ComfyUI 的镜像不一定在 library 下面，前缀替换时仓库路径要保持完整。如果拉取中途失败，大概率是源被限流，换个备用源重试即可。

4.9 青龙面板等应用依赖安装慢的问题

很多人配置完镜像加速后，发现青龙面板的应用拉下来了，但容器内安装 npm 依赖、apk 依赖还是很慢，以为加速没生效。

这里得说清楚：Docker 镜像加速只负责容器镜像本身的下载。容器启动之后，容器内部的包管理工具（npm、apk、pip、apt）走的还是它们各自的软件源，跟 Docker registry 没有关系。

想解决青龙面板依赖安装慢，需要进入容器，把 npm 源、apk 源换成国内的可访问源。比如 npm 设置：

npm config set registry https://registry.npmmirror.com

apk 源则需要修改/etc/apk/repositories。这是完全独立的一块优化，别和 Docker 镜像加速混在一起。

一些值得长期坚持的习惯

说了这么多，最后分享几个我自己一直在用的小习惯。

我每两个月左右会跑一遍测试命令，看当前用的几个加速源是不是还活着。一旦发现某个源响应变慢或者开始报错，就直接从配置里去掉，换新的源进来。这个过程不超过五分钟，但能避免很多关键时刻掉链子的情况。

另外，daemon.json 的备份很重要。每次修改配置之前，先执行：

sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak

这样就算改坏了也能快速回滚，不用重新回忆原来的配置长什么样。

镜像加速这件事，本质上没有一劳永逸的答案。公共源会因为各种原因失效，专属源虽然稳定但需要账号，个人自建源则要付出维护成本。最适合普通用户的策略，就是配置两三个经过实测的公共源，然后定期检查和更新。如果你按照这份列表配置完还是拉不动，不用怀疑自己，大概率是某个源刚好在维护或者被限流了，换一个重试就行。