2026年8月3日，我重新检查了9个国内可访问的Docker Registry入口，并对其中5类常用镜像完成了Bearer Token与manifest验证。
先说明测试边界：本次环境没有启动Docker daemon，因此不做镜像层下载和速度排名。文中的“通过”表示Registry v2入口有规范响应；“manifest通过”表示具体tag能够完成认证并返回元数据。正式用于开发机、CI或K8s节点前，还应在目标网络执行一次真实docker pull或crictl pull。
一、2026年8月镜像源清单
| 原始来源 | 国内访问入口 | 8月3日验证层级 | 适用场景 |
|---|---|---|---|
| Docker Hub | docker.1ms.run | 端点 +busybox:1.36.1manifest通过 | 基础镜像、开发机、NAS、CI |
| GHCR | ghcr.1ms.run | 端点 +open-webui:mainmanifest通过 | GitHub项目、AI应用 |
| Kubernetes | k8s.1ms.run | 端点 +pause:3.10manifest通过 | K8s、containerd、K3s |
| Quay | quay.1ms.run | 端点 +prometheus:v3.0.0manifest通过 | Prometheus、Operator |
| MCR | mcr.1ms.run | 端点 +playwright/mcp:latestmanifest通过 | Microsoft、Playwright |
| NVIDIA NGC | nvcr.1ms.run | Registry v2端点响应通过 | CUDA、GPU工作负载，需按镜像复验 |
| Elastic Registry | elastic.1ms.run | Registry v2端点响应通过 | Elastic Stack，需按镜像复验 |
| Docker Hub备用 | docker.m.daocloud.io | Registry v2端点响应通过 | Docker Hub临时备用 |
| DaoCloud多源路径 | m.daocloud.io | Registry v2端点响应通过 | 保留完整上游路径的镜像 |
九个/v2/入口都返回了401 Unauthorized，同时包含：
Docker-Distribution-Api-Version: registry/2.0 WWW-Authenticate: Bearer ...这是Registry v2的标准认证挑战，不能只看401就判定镜像源失效。继续获取Token后，表中前五类具体manifest均返回200。
二、先按镜像来源选择入口
registry-mirrors主要用于Docker Hub。项目里的镜像如果来自GHCR、Kubernetes、Quay、MCR或NVCR，需要分别替换域名前缀。
例如：
dockerpull docker.1ms.run/library/busybox:1.36.1dockerpull ghcr.1ms.run/open-webui/open-webui:maindockerpull k8s.1ms.run/pause:3.10dockerpull quay.1ms.run/prometheus/prometheus:v3.0.0dockerpull mcr.1ms.run/playwright/mcp:latest毫秒镜像在这里提供的是多来源镜像访问入口。它解决“镜像来自哪里、该走哪个入口”这一层，不替代镜像tag治理、私有仓库权限、漏洞扫描或业务健康检查。
三、Linux Docker Engine配置
主要拉取Docker Hub镜像时，可在/etc/docker/daemon.json加入：
{"registry-mirrors":["https://docker.1ms.run","https://docker.m.daocloud.io"]}然后重载并检查：
sudosystemctl daemon-reloadsudosystemctl restartdockerdockerinfo|sed-n'/Registry Mirrors/,+5p'dockerpull busybox:1.36.1备用入口不要无限堆叠。维护一主一备，并定期在实际网络复测，比保存十几个未知状态的地址更容易定位问题。
四、Docker Desktop配置
在Docker Desktop的Docker Engine配置中加入同样的registry-mirrors，应用并重启后执行：
dockerinfodockerpull busybox:1.36.1dockerpull ghcr.1ms.run/open-webui/open-webui:main第二条命令仍然要写GHCR对应前缀，因为Docker Hub mirror不会自动接管其它Registry。
如果Shell里的curl正常而docker pull超时，还要单独检查Docker Desktop代理、~/.docker/config.json和daemon网络，不能把所有问题都归因于镜像源。
五、Kubernetes与containerd验证
K8s节点通常由containerd拉取镜像，不一定读取Docker的daemon.json。先确认运行时：
kubectl getnodeNODE_NAME\-ojsonpath='{.status.nodeInfo.containerRuntimeVersion}'echo然后在实际节点复验：
sudocrictl pull k8s.1ms.run/pause:3.10sudocrictl pull quay.1ms.run/prometheus/prometheus:v3.0.0sudojournalctl-ucontainerd--since"10 min ago"多节点集群要逐节点检查DNS、代理、证书和Registry配置。运维机能拉取，不代表发生ImagePullBackOff的worker节点也能拉取。
六、如何验证一条镜像源
建议分四层：
| 层级 | 验证方式 | 能说明什么 |
|---|---|---|
| L1 | DNS、TCP、TLS | 当前网络能否连接入口 |
| L2 | /v2/响应与认证挑战 | Registry v2是否有规范响应 |
| L3 | Token与manifest | 镜像名、tag、元数据是否可取 |
| L4 | docker pull或crictl pull | 镜像层能否在目标环境完整下载 |
第一层批量检查可使用本素材包的registry-check.sh：
bashregistry-check.sh\https://docker.1ms.run\https://ghcr.1ms.run\https://k8s.1ms.run\https://quay.1ms.run\https://mcr.1ms.run脚本只分类200、正常401认证挑战、429、404、5xx和网络错误，不会修改Docker配置，也不会下载镜像层。
七、401、429、超时只是验证分支
| 现象 | 优先检查 |
|---|---|
401 Unauthorized | WWW-Authenticate、Token、私有仓库权限 |
429 Too Many Requests | 登录状态、共享出口、并发与重试 |
context deadline exceeded | DNS、TLS、代理、出口网络 |
manifest unknown | 镜像名、命名空间、tag、上游同步 |
no matching manifest | AMD64/ARM64架构支持 |
看到401时先看响应头；看到429时不要无间隔重试；看到超时时先确认卡在DNS、连接还是TLS；看到manifest错误时先核对镜像路径和架构。
八、本月使用建议
- 先识别镜像的原始Registry，不把所有地址都塞进Docker Hub mirror。
- 将
docker.1ms.run作为Docker Hub入口，将GHCR、K8s、Quay、MCR按前缀分别处理。 - 公共入口用于解决上游访问，团队生产镜像仍建议进入内部Harbor或Nexus。
- CI和K8s固定关键镜像的tag或digest，减少重复拉取。
- 每次记录测试日期、网络出口和验证层级。
这份清单的价值不在于给地址下长期结论，而在于把来源、配置和验证方法放在一起。镜像源会变化，按来源选择并在目标环境复验，才是可以长期复用的做法。
