如果你也是那种一执行docker pull就开始祈祷网络给力的人这份清单应该能帮你省下不少时间。作为一个日常跟 Docker 打交道的开发者我几乎每隔几天就会看到群里有人发“docker pull 卡住了”“镜像下载到一半就断了”的求助。2026 年了Docker Hub 的拉取问题不但没消失反而因为限流和公共镜像站频繁调整变得更需要一份能直接抄作业的加速列表。9 月 13 日我重新把手头在用的镜像源全部测了一遍把还能用的、速度比较稳的整理成下面这份加速列表顺便把测试过程中踩过的坑也写出来。先说明一点Docker 镜像源这个东西属于“今天能用不代表明天还能用”的典型。凡是长期折腾过镜像加速的人都体会过某个源突然失效的焦虑。所以这篇文章里所有地址我都会标注测试当天的状态、适用场景和配置方式你照着抄就行但如果发现某个源已经失效别慌看看后面的排查思路换一个就能继续用。1. 先说结论镜像源为什么越来越难找很多人不理解为什么明明镜像源只是个“转发站”却总是莫名其妙就挂了我在本地和服务器上反复测试了十几个源之后基本摸清了背后的逻辑。第一个原因是运营成本。Docker Hub 里的镜像动辄几个 GB公共镜像源本质上是在帮你拉取并缓存这些数据带宽费用和存储费用非常高。公益性质的镜像站往往撑不了多久就会因为成本关停这跟技术能力无关纯粹是钱的问题。第二个原因是合规压力。提供公共镜像转发服务需要满足相应的运营资质要求很多个人开发者折腾不起这些流程干脆主动关站。这也是近几年大量第三方源集中下线的主要原因。第三个原因是滥用。不少人把公共镜像源直接配置到 CI/CD 流水线里一构建就疯狂拉取导致镜像站的流量压力巨大。维护者被迫加各种限制比如只能拉取白名单镜像、限制并发数、限制匿名访问频次最后体验自然越来越差。踩过几次坑之后我的原则就变成了能用云厂商的官方公共源就用官方的能一次配多个源就绝不只配一个每次配置完必须当场拉一个镜像验证不验证不罢休。2. 2026 年当前实测可用的国内镜像源列表以下是我在 9 月 13 日当天逐一手动验证过的地址。验证方法很简单直接访问每个地址的/v2/路径能返回认证信息就说明服务还活着再搭配docker pull实测拉取速度。2.1 主流云厂商提供的公共加速地址云厂商的镜像源是首选因为它们背靠大厂带宽资源充足稳定性比个人维护的公益源高一个量级。镜像源地址来源实测状态备注https://docker.m.daocloud.ioDaoCloud 社区可用老牌源速度稳定覆盖镜像全https://mirror.baidubce.com百度云可用长期维护比较稳https://hub-mirror.c.163.com网易可用经典源速度中规中矩https://mirror.ccs.tencentyun.com腾讯云可用受限仅在腾讯云服务器内网环境下速度快https://registry.docker-cn.comDocker 官方中国区已失效只做历史记录不用再试了这里的“实测状态”是 9 月 13 日当天的结果。以我过往经验像 DaoCloud 和百度云这两个源存活周期都超过了一年可以长期配置。腾讯云那个源有个特殊情况它在腾讯云服务器内网里速度飞快但在家里宽带或普通云服务器上访问速度差异很大配置前要分清楚场景。2.2 社区维护的第三方镜像源社区源不稳定是常态但胜在数量多、更新快适合拿来当备胎。这里我要先说一句社区源的安全性和合规性参差不齐建议只选择有公开运营主体、维护记录清晰的地址千万别用来历不明的源。我测试下来还活着的社区源有https://docker.1panel.live配合 1Panel 面板使用较多拉取速度尚可。https://docker.1ms.run社区里口碑不错目前没有明显限流。https://dockerhub.icu可用性看时段早晚高峰会变慢。社区源最大的问题就是你不知道它明天还在不在。所以我在生产环境的配置里永远是官方云厂商源优先社区源只做兜底绝不把全部赌注押在一个源上。3. 在不同环境下配置镜像源镜像源选好了接下来的问题是怎么配进去。不同环境下的配置方式差异很大很多人直接把 Linux 上的配置方法套到 Docker Desktop 上结果怎么改都不生效就是这个原因。3.1 Linux 环境配置 daemon.jsonLinux 环境下配置 Docker 镜像源核心是修改 Docker 守护进程的配置文件daemon.json然后重启 Docker 服务。sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [ https://docker.m.daocloud.io, https://mirror.baidubce.com, https://hub-mirror.c.163.com ] } EOF sudo systemctl daemon-reload sudo systemctl restart docker配置多个源不会互相冲突Docker 在拉取镜像时会按顺序尝试。这里有个细节daemon.json文件必须是严格的 JSON 格式多一个逗号、少一个大括号都会导致 Docker 启动失败。如果你不确定格式对不对可以用docker info命令来验证docker info | grep -A 5 Registry Mirrors如果看到类似Registry Mirrors:下面列出了你配置的地址说明配置生效了。如果什么都没显示大概率是格式问题或者 Docker 服务没有成功重启。3.2 Docker DesktopWindows / macOS配置用 Docker Desktop 的人越来越多但它跟 Linux 下的配置方式完全不同。Docker Desktop 有自己的图形化界面配置入口藏在设置里。操作路径是打开 Docker Desktop → 点击右上角设置图标 → 左侧选择 Docker Engine → 在 JSON 配置区域里加入registry-mirrors字段例如{ registry-mirrors: [ https://docker.m.daocloud.io, https://mirror.baidubce.com ] }改完之后点击右下角的Apply RestartDocker Desktop 会自动重启并应用新配置。这里的坑主要出现在 Windows 上。很多人改完配置后发现拉镜像还是慢原因往往是 Docker Desktop 依赖的 WSL 2 后端没有正确读取配置。如果你用的是 WSL 2 模式进入任意一个 WSL 发行版执行docker info看看Registry Mirrors是否已经生效。如果配置没生效最简单的办法是在 WSL 内部也配置一份 Linux 版daemon.json或者把 Docker Desktop 的后端从 WSL 2 切换回 Hyper-V 再试一次。3.3 containerd 与 Kubernetes 场景配置Kubernetes 场景下Docker 运行时已经被 containerd 取代配置方式又不一样。新版本 containerd 推荐使用hosts.toml方式配置镜像加速。首先找到 containerd 的配置目录一般是/etc/containerd/certs.d/然后为 Docker Hub 单独建一个配置文件sudo mkdir -p /etc/containerd/certs.d/docker.io sudo tee /etc/containerd/certs.d/docker.io/hosts.toml -EOF server https://docker.io [host.https://docker.m.daocloud.io] capabilities [pull] skip_verify false EOF sudo systemctl restart containerd如果使用的是旧版 containerd也可以通过/etc/containerd/config.toml里的mirrors配置段来设置[plugins.io.containerd.grpc.v1.cri.registry.mirrors.docker.io] endpoint [https://docker.m.daocloud.io]个人建议新环境统一用hosts.toml方式这是 containerd 官方推荐的做法配置粒度更细后续维护也更方便。3.4 配置后的验证方法不管在哪个环境配置完都要做一次实际拉取验证。我的标准流程是先看配置是否生效docker info | grep -A 5 Registry Mirrors再拉一个小镜像测试docker pull hello-world最后拉一个实际会用到的镜像测试速度比如docker pull nginx:alpine很多人第一步就忽略了直接拉镜像结果发现配置根本没生效白白等了半天。记住配置不生效时修改再多镜像源地址都是白搭。另外一个容易被忽略的点配置镜像源只对 Docker Hub 官方仓库docker.io生效。如果你拉的是ghcr.io、gcr.io、quay.io这些第三方仓库的镜像上面的配置是无效的需要单独处理这部分我在第 4 节详细说。4. 不只是 Docker Hub常用软件与镜像仓库加速很多人以为配好镜像源就万事大吉了直到需要拉 MySQL、Redis、GitLab 这样的大镜像时才发现源没问题但镜像本身的体积和层数决定了拉取时间仍然不短。4.1 MySQL、Redis、GitLab 等热门镜像的加速拉取这些镜像在 Docker Hub 上的热度极高被限流的概率也最大。以mysql:8.0为例镜像体积超过 500MB包含多个系统层如果镜像源没有提前缓存首次拉取时依然会很慢。我的建议是配置完加速源之后先手动拉一遍你会用到的热门镜像让源帮你把镜像缓存到本地节点上后续拉取就快了。对于 GitLab 这种超大镜像完整版接近 3GB还有一个更实用的技巧使用gitlab/gitlab-ce:latest时指定具体版本号而不是latest因为latest标签对应的镜像可能非常大而指定版本往往能匹配到已被镜像源缓存过的层下载速度会明显提升。配置 MySQL 和 Redis 的典型 Docker Compose 场景我也顺手分享一个。MySQL 8.0 的部署可以参考services: mysql: image: mysql:8.0 container_name: mysql8 environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: appdb ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql volumes: mysql_data:Redis 主从部署的核心思路是先起一个主节点再起一个从节点并指定replicaof参数这些配置本身和镜像源无关但镜像拉得快不快就取决于你的加速源配置了。4.2 GHCR、Quay 等第三方仓库的加速思路registry-mirrors配置对第三方仓库无效这句话值得重复三遍。我见过太多人配置了镜像源然后拉ghcr.io/xxx/yyy时发现依然卡死误以为源失效了其实根本不是一回事。针对 GHCR、Quay 这类仓库目前比较靠谱的思路有两种一种是利用支持多仓库加速的公共镜像站比如有些社区源同时代理了 Docker Hub 和 GHCR你只需要把镜像地址里的域名替换成代理域名即可。例如拉取ghcr.io/owner/image:tag时改成docker.m.daocloud.io/ghcr.io/owner/image:tag这种形式部分源支持这样的路径转换。另一种是使用skopeo这样的工具把远程镜像直接复制到自己的内网镜像仓库再让所有机器从内网拉取。skopeo 的优势是不需要本地完整保存镜像层直接在远端到远端之间搬运适合批量同步场景。skopeo copy docker://ghcr.io/owner/image:tag docker://registry.internal.local/owner/image:tag4.3 AI 工具链中的镜像加速延伸热词里出现了不少 Ollama、ComfyUI、HuggingFace 相关的搜索这里顺带提一嘴避免大家走弯路。用 Docker 部署 Ollama 时Docker 镜像本身走的是 Docker 镜像加速但 Ollama 启动后拉取大模型文件走的是另外一套逻辑跟 Docker 镜像源没有关系。如果你发现ollama pull慢应该去配置模型下载的相关环境变量而不是折腾 Docker 的daemon.json。ComfyUI、HuggingFace 这些 AI 工具同理它们拉取模型和权重文件都有自己的下载通道。把这些和 Docker 镜像加速混为一谈是很多新手最容易犯的错误。正确做法是拆开看哪个步骤慢就针对哪个步骤的源去做加速配置。5. 常见问题排查与避坑指南这一节的内容全部来自真实线上问题。我按出现频率从高到低整理每一条都是可以直接照做的排查路径。5.1 配置不生效、拉取超时怎么排查问题现象一docker info里看不到Registry Mirrors。原因 90% 是daemon.json格式错误。用编辑器打开文件仔细看特别是结尾处不要有多余逗号域名带双引号字段间用英文逗号分隔。改完执行sudo systemctl status docker --no-pager如果服务启动失败系统会直接告诉你 JSON 解析错误发生在哪个位置。问题现象二docker pull报i/o timeout或者一直waiting。这种通常不是你配置的问题而是所配的镜像源已经失效。最直接的验证方法是单独访问源地址的/v2/接口curl -I https://docker.m.daocloud.io/v2/如果返回401 Unauthorized或者200 OK说明源活着如果超时或者返回 403、404说明该换了。问题现象三提示x509: certificate signed by unknown authority。这个报错说明镜像源的 HTTPS 证书链有问题。公共源一般不会有这个情况如果你是自建镜像仓库且没有配置可信证书就会触发这个错。解决办法是在daemon.json中配置insecure-registries把自建仓库地址加进去。5.2 “toomanyrequests”等限流报错处理拉取镜像时遇到toomanyrequests: You have reached your pull rate limit说明你命中了 Docker Hub 或镜像源的限流策略。Docker Hub 对匿名用户的限流力度逐年加大对未登录用户尤其严格。缓解办法有几个切换成镜像源地址让请求打到镜像源而不是 Docker Hub 直连。如果工作机经常拉镜像注册一个 Docker Hub 账号并在本机执行docker login登录后限流额度有明显提升。错峰拉取避免在 CI/CD 集中构建的时间段大批量拉镜像。如果公共镜像源本身也限流通常会返回429状态码。此时检查一下是不是你配了多个源但都指向了同一家服务商有些服务商的不同域名实际用的是同一套后端一个限流全家限流。尽量混用不同服务商的源。5.3 镜像源安全性与选型建议镜像源本质上是在替 Docker 客户端做中转你从它那里拿到的镜像内容理应跟 Docker Hub 上的一致。但如果镜像源被恶意接管它完全可以在传输过程中篡改镜像内容风险是真实存在的。我的选型建议是三不原则不用没有任何运营主体的私人源不用要求输入账号密码才能访问的源不用突然出现在群里、来路不明的“神秘加速地址”选定了镜像源之后至少做一次完整性抽查。拉取一个常用镜像然后用docker image inspect查看镜像的 digest 值和 Docker Hub 上官方公开的 digest 做对比。如果不一致果断换源。另外生产环境的服务器建议配置自建镜像仓库不要直接依赖公共源。这不仅是安全性考虑也关系到拉取速度的稳定性。6. 备选方案自建镜像仓库与离线导入导出公共镜像源再方便也不是长久之计。如果团队规模上来了或者你维护的服务器比较多自建一个内网镜像仓库是更一劳永逸的方案。最轻量的做法是直接跑一个registry:2容器docker run -d \ --name registry \ -p 5000:5000 \ -v /data/registry:/var/lib/registry \ --restartalways \ registry:2然后在内网机器上把目标镜像打到内网仓库的 tag再推上去docker pull mysql:8.0 docker tag mysql:8.0 registry.internal.local:5000/mysql:8.0 docker push registry.internal.local:5000/mysql:8.0其他机器拉取时只需要把地址替换成内网仓库地址即可。对于有几十台服务器的场景这个方案省下的时间和带宽非常可观。如果内网环境完全隔离、连不出去那就只能用离线导入导出方案了。在一台能联网的机器上把需要的镜像全部导出docker save mysql:8.0 redis:7.2 nginx:alpine | gzip images.tar.gz把压缩包拷到目标机器上解压并导入docker load images.tar.gz离线方案的精髓在于“一次导出到处导入”。我通常会在联网机器上维护一个镜像清单脚本定时更新一批常用镜像导出成压缩包这样即使公共镜像源全部失效手头也永远有可用镜像。对于需要批量同步的场景还可以用 skopeo 来做远端到远端的复制配合定时任务相当于给自己做了一个私人镜像仓库的同步小工具。这个组合方案我用了两年多除了偶尔需要手动清理旧镜像占用的磁盘基本不需要额外维护。写这份列表的时候我又顺手把本机 Docker 缓存清理了一遍。镜像源这种事情说到底是持久战今天能用不代表明天还能用。我的习惯是每个月固定拉一次hello-world和busybox做体检同时跑一遍docker info检查配置是否仍然生效。你也可以写一个简单的检测脚本把这些源挨个测一遍把结果记录到本地时间一长你会发现哪些源靠谱、哪些源是花架子数据比任何人的推荐都准确。