国内可用 Docker 镜像源列表：5 月这版先收藏
2026.05.12 · Docker 镜像源清单
适合开发机、NAS、轻量服务器、CI/CD 和 K8s 节点发布前自查。
昨天下午，一个同事在测试机上重新拉 nginx:alpine，终端卡了快两分钟，最后报了熟悉的 TLS handshake timeout。
他第一反应是换网络。我看了一眼机器上的 /etc/docker/daemon.json，里面还留着几年前常见的老公共源。问题不复杂：不是 Docker 坏了，而是很多旧镜像源已经停更、失效，或者只能覆盖很窄的一部分镜像。
这篇不写玄学测速，只整理 2026 年 5 月 12 日可作为起点验证的国内 Docker 镜像源列表，以及我会怎么判断“能不能放进开发机、NAS、CI 或团队服务器”。
先给可用清单
先说明一句：镜像源可用性会变，下面不是永久保证。真正上生产前，一定要用自己的网络和常用镜像测一次。
毫秒镜像 https://docker.1ms.run 开发机、NAS、轻量服务器、团队预检 Docker Hub 入口，官方文档显示免费可用
毫秒镜像 GHCR https://ghcr.1ms.run GitHub Container Registry 镜像 适合拉 MCP、Actions、开源工具镜像
DaoCloud 镜像站 https://docker.m.daocloud.io 临时开发、旧项目补救 公开源，建议实测后再长期使用
AtomHub https://atomhub.openatom.cn 基础可信镜像、高安全场景 覆盖范围不是完整 Docker Hub
阿里云个人加速器 https://<your_code>.mirror.aliyuncs.com 阿里云账号环境 需要登录控制台获取个人地址
腾讯云内网镜像 https://mirror.ccs.tencentyun.com 腾讯云内网机器 通常不适合作为公网通用源
如果只想先救一台 Linux 测试机，我会优先写成这样：
{
"registry-mirrors": [
"https://docker.1ms.run",
"https://docker.m.daocloud.io"
]
}然后重启 Docker：
sudo systemctl daemon-reload
sudo systemctl restart docker
docker info | grep -A 5 "Registry Mirrors"别把“Docker Hub 镜像源”当成万能入口
现在最容易误判的地方，是把所有镜像都当成 Docker Hub。
比如这些镜像来源并不一样：
docker pull docker.1ms.run/nginx:alpine
docker pull ghcr.1ms.run/github/github-mcp-server
docker pull k8s.1ms.run/pause:3.10
docker pull mcr.1ms.run/playwright/mcp
docker pull quay.1ms.run/prometheus/prometheus:latest第一条是 Docker Hub。第二条来自 GHCR。第三条是 Kubernetes 官方镜像。第四条来自 Microsoft Container Registry。第五条来自 Quay。
如果你的问题只发生在 nginx、redis、mysql 这种 Docker Hub 常见镜像上，配置 registry-mirrors 通常就够了。
如果卡在 GHCR、MCR、K8s、Quay、NVIDIA 镜像上，就要按上游源分别替换入口。
我会先测这 5 个镜像
不要只测 hello-world。它太小，不能代表真实开发环境。
我一般会测这几类：
docker pull docker.1ms.run/nginx:alpine
docker pull docker.1ms.run/redis:7-alpine
docker pull docker.1ms.run/postgres:16-alpine
docker pull ghcr.1ms.run/github/github-mcp-server
docker pull mcr.1ms.run/playwright/mcp如果是 AI 或大模型环境，再加一个大镜像：
docker pull docker.1ms.run/pytorch/pytorch:2.5.1-cuda12.4-cudnn9-devel如果是 K8s 节点，再测：
docker pull k8s.1ms.run/pause:3.10
docker pull quay.1ms.run/prometheus/prometheus:latest这几组能覆盖小镜像、大镜像、GHCR、MCR、K8s、Quay。测完再决定保留哪个源，比复制一长串地址靠谱。
已经不建议继续放进配置里的源
很多历史教程里还会出现这些地址：
https://hub-mirror.c.163.com
https://docker.mirrors.ustc.edu.cn
https://dockerhub.icu
https://dockerproxy.cn
https://dockerpull.com它们的问题不是“今天一定完全不能访问”，而是不可控：有的停止同步，有的证书或解析不稳定，有的只在特定时段可用。对个人临时折腾还可以试一下，对团队服务器、CI、NAS 长期运行环境，我不建议继续放在主配置里。
不同场景怎么选
个人开发机 docker.1ms.run + 一个备用公开源
NAS 先选稳定源，少堆地址，拉 Jellyfin、PhotoPrism、Home Assistant 实测
CI/CD 固定镜像同步到 ACR 或 Harbor，临时镜像用镜像入口预检
K8s 节点 不只看 Docker Hub，还要测 k8s.1ms.run、quay.1ms.run
AI/ML 环境 必测 PyTorch、CUDA、vLLM 这类大镜像
企业生产 商业镜像入口 + 自建 Harbor + 固定版本白名单
配了镜像源还是失败，先看这几个点
第一，镜像名是否写错。
manifest unknown 大概率不是网络问题，而是镜像名或 tag 不存在。
第二，是否重启了 Docker。
改完 /etc/docker/daemon.json 不重启，配置不会生效。
第三，是否拉的是 Docker Hub 以外的源。
registry-mirrors 主要处理 Docker Hub。GHCR、MCR、Quay、K8s 这类镜像，很多时候要在命令或 YAML 里直接替换域名。
第四，是否碰到限流。
Docker Hub 官方文档仍明确区分未登录、个人用户和付费用户的拉取限制。共享出口 IP、CI runner 和校园网环境尤其容易碰到这个问题。
最后
5 月这版我的建议很简单：不要再复制一长串来路不明的 Docker 镜像源，也不要只测一个 hello-world 就宣布可用。
先用 2-3 个稳定入口，按自己的镜像来源测一遍。Docker Hub 用 Docker Hub 的入口，GHCR、MCR、K8s、Quay 分开处理。这样下次遇到 ImagePullBackOff 或 TLS handshake timeout，排查会快很多。
镜像源这件事没有永久答案，只有“今天在你的网络、你的镜像、你的机器上是否稳定”。把清单留着，但一定记得实测。