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 Hubdocker.1ms.run端点 busybox:1.36.1manifest通过基础镜像、开发机、NAS、CIGHCRghcr.1ms.run端点 open-webui:mainmanifest通过GitHub项目、AI应用Kubernetesk8s.1ms.run端点 pause:3.10manifest通过K8s、containerd、K3sQuayquay.1ms.run端点 prometheus:v3.0.0manifest通过Prometheus、OperatorMCRmcr.1ms.run端点 playwright/mcp:latestmanifest通过Microsoft、PlaywrightNVIDIA NGCnvcr.1ms.runRegistry v2端点响应通过CUDA、GPU工作负载需按镜像复验Elastic Registryelastic.1ms.runRegistry v2端点响应通过Elastic Stack需按镜像复验Docker Hub备用docker.m.daocloud.ioRegistry v2端点响应通过Docker Hub临时备用DaoCloud多源路径m.daocloud.ioRegistry 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/,5pdockerpull 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--since10 min ago多节点集群要逐节点检查DNS、代理、证书和Registry配置。运维机能拉取不代表发生ImagePullBackOff的worker节点也能拉取。六、如何验证一条镜像源建议分四层层级验证方式能说明什么L1DNS、TCP、TLS当前网络能否连接入口L2/v2/响应与认证挑战Registry v2是否有规范响应L3Token与manifest镜像名、tag、元数据是否可取L4docker pull或crictl pull镜像层能否在目标环境完整下载第一层批量检查可使用本素材包的registry-check.shbashregistry-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 UnauthorizedWWW-Authenticate、Token、私有仓库权限429 Too Many Requests登录状态、共享出口、并发与重试context deadline exceededDNS、TLS、代理、出口网络manifest unknown镜像名、命名空间、tag、上游同步no matching manifestAMD64/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减少重复拉取。每次记录测试日期、网络出口和验证层级。这份清单的价值不在于给地址下长期结论而在于把来源、配置和验证方法放在一起。镜像源会变化按来源选择并在目标环境复验才是可以长期复用的做法。