前几天还有人在知乎问："docker有好使的源吗？现在怎么好多源都不行了？"其中一条回答只有几个字：“花几块钱开个VIP，还是挺好用的”。知乎
你看，现在搜"Docker镜像源"，排在前面的"2026年8月最新可用列表"，点进去很多是某家商业镜像服务的软文——通篇都在劝你注册专业版、充值流量。真正的问题是：这些列表里推荐的免费源，有一半今天已经连不上了。
我今天把手头能找到的14个常见镜像源挨个测了一遍（完整走了一遍registry的token认证流程，不是只ping一下域名），结果有点残酷：9个已经失联，只有5个还能正常匿名拉取。更关键的是，这份清单的保质期可能只有几周——所以这篇不光给你今天的实测结果，还给你一个10秒自查的方法，和三条不同人群的路。
先看今天（8月25日）的实测结果
先交代测试方法：对每个源请求`/v2/`接口，拿到认证挑战后走匿名token流程，再实际拉取alpine镜像的manifest。能走完这套流程的，才算"能拉"。测试出口是单一网络，你家宽带可能略有出入，但大方向不会差太多。
还能用的（5个）：
`docker.1panel.live`：完全开放，匿名直拉，今天实测最顺的一个
`docker.m.daocloud.io`：实测能拉。但注意，社区反馈它现在上了白名单限制，不是所有镜像都能加速。知乎
`docker.1ms.run`：实测能拉，老牌公益源，限流时快时慢，也有老用户说目前国内加速用它的最好。知乎
`docker.xuanyuan.me`：实测能拉。这家的免费版能用，但搜它相关内容时留个心眼（后面细说）
`hub.rat.dev`：响应是302跳转，属于转发型，能用但稳定性一般
已经失联的（9个）： `dockerpull.com`、`dockerproxy.cn`、`docker.1panelproxy.com`、`docker.unsee.tech`、`hub.uuuadc.com`、`docker.awsl9527.cn`、`docker.1024.ninja`、`dhub.qwerty.xin`（全部连接超时），以及`docker.ketches.cn`（502）。
有意思的是，2024年不少镜像站已经下架时，还有人在知乎信誓旦旦，说`docker.1panelproxy.com`这个还能。知乎现在它也凉了。这就是镜像源现状的缩影：没有哪个公益源是永恒的。
对照一下：Docker官方的`registry-1.docker.io`从国内网络直连同样不通，这正是所有故事的起点。
为什么源会一个接一个地死
简单捋一下时间线，帮你理解这不是偶发故障：
2024年6月前后，Docker Hub在国内的直连开始大面积受阻。知乎那时候大家的第一反应是改`/etc/docker/daemon.json`，填几个`registry-mirrors`，问题就解决了——因为当时公益源还遍地都是。
但公益镜像源是个天生不可持续的生意：带宽是真金白银，上游Docker Hub有匿名拉取限流，还要面对内容合规的压力。所以从2024年下半年开始，源开始批量关停，到2026年，连"抄旧教程"这条路都基本断了。知乎现在还能活着的源，要么是厂商为自己的产品引流（比如1Panel、轩辕），要么是大厂开源布道顺手维持的（比如DaoCloud），要么纯属个人用爱发电——哪一种都不是给你做永久承诺的。
想明白这一点，结论就清楚了：别把任何一个源当成永久答案，要么学会自己验证，要么自建。
三个坑，比源挂了更坑人
坑一：`registry-mirrors`只管Docker Hub。 你在daemon.json里配的镜像加速，只对`docker.io`生效。知乎如果你要拉`ghcr.io`（GitHub容器仓库）、`registry.k8s.io`的镜像，镜像加速配置完全不生效，得用域名替换或者containerd的hosts.toml另配一套。很多人CI流水线里拉ghcr超时，折腾半天镜像源，其实是方向错了。
坑二：NAS里"搜不到"不等于"源挂了"。 在飞牛NAS上，"镜像列表刷不出来"已经是个常见问题。知乎飞牛、群晖的图形界面搜镜像，走的是Docker Hub的搜索API，大部分镜像源只做了拉取代理、没做搜索代理——所以会出现"列表刷不出来，但直接输全名能拉"的情况。在NAS上玩Docker，记住一条：别依赖搜索，直接输完整镜像名，比如`xiaoyaliu/alist`，能拉就说明源是活的。
坑三：高排名的"哪个源好用"回答里，有不少软文。 我查资料时发现，知乎上"为什么国内的docker镜像源都pull不下来东西了"这类问题下的高赞回答，就是某家商业镜像服务的软文——前半段制造焦虑，后半段介绍自家平台，最后直接给出结论：免费版太拥挤，直接上专业版，省时省力。知乎这类内容不是不能看，但它给你的清单天然偏向自家服务，别当成中立测评。
三条路，按你的情况选
路线A：轻度用户，换源+会自查就够了。
如果你只是偶尔在本机拉几个镜像，把今天实测还活着的源填进`registry-mirrors`（Docker Desktop在Settings → Docker Engine里改），重启生效。关键是学会这个10秒自查命令，以后看到任何"最新可用源"帖子，先自己验一下：
```
curl -sI https://源地址/v2/ | head -1
```
返回401或200，说明服务活着；返回000、超时或502，直接放弃，别浪费时间去改配置。
路线B：NAS/家庭实验室用户，自建缓存才是正解。
如果你家里是飞牛、群晖这类NAS，上面常年跑着十几个容器，与其到处求源，不如在自己的NAS上部署一个拉取缓存（pull-through cache）。开源项目`cp0204/dkturbo`就是专门干这个的，一份docker-compose.yml，飞牛传到docker文件夹、用Compose建项目启动，群晖走Container Manager的"项目"，十几分钟搞定。知乎
它的好处不止是"能拉"：镜像拉到NAS本地后会缓存，家里所有设备第二次拉同一个镜像走的是局域网速度；而且源失效的冲击被挡在了你的缓存层，上游换一个源只改一处配置。按教程作者实测，在飞牛上拉`xiaoyaliu/alist`镜像，大概20秒就完成了下载。知乎自建唯一的成本是NAS自己的出口得能连上一个上游源——好消息是，这个要求比"所有设备都能连上源"低得多。
路线C：生产环境，别在公益源上赌运气。
公司项目、K8s集群，请直接上云厂商容器镜像服务（阿里云、腾讯云都有个人/企业版）或者自建Harbor。知乎生产环境用公益源的风险不只是慢，还有镜像被下架、仓库被关停、拉取无SLA。这一步没有免费的捷径，花钱买确定性就是最值得的投入。
接下来值得盯什么
这类源的消亡和新生是持续过程，给你三个观察信号：一是看还在维护的源的GitHub仓库最近一次更新时间，停更超过几个月的，心里要有数；二是拉取时如果开始频繁出现429或401，说明那个源在限流，离失效不远了；三是每次大版本节点（比如bitnami把全套镜像从Docker Hub搬走这类托管政策调整），都会引发一轮源的地震。
工具是死的，验证方法是活的。把那条10秒的curl命令收藏好，比收藏任何一份"最新可用清单"都管用。
