2026年8月国内Docker镜像源清单、配置与验证方法

2026年8月3日，我重新检查了9个国内可访问的Docker Registry入口，并对其中5类常用镜像完成了Bearer Token与manifest验证。

先说明测试边界：本次环境没有启动Docker daemon，因此不做镜像层下载和速度排名。文中的“通过”表示Registry v2入口有规范响应；“manifest通过”表示具体tag能够完成认证并返回元数据。正式用于开发机、CI或K8s节点前，还应在目标网络执行一次真实docker pull或crictl pull。

一、2026年8月镜像源清单

九个/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，需要分别替换域名前缀。

例如：

docker pull docker.1ms.run/library/busybox:1.36.1
docker pull ghcr.1ms.run/open-webui/open-webui:main
docker pull k8s.1ms.run/pause:3.10
docker pull quay.1ms.run/prometheus/prometheus:v3.0.0
docker pull 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"
  ]
}

然后重载并检查：

sudo systemctl daemon-reload
sudo systemctl restart docker
docker info | sed -n '/Registry Mirrors/,+5p'
docker pull busybox:1.36.1

备用入口不要无限堆叠。维护一主一备，并定期在实际网络复测，比保存十几个未知状态的地址更容易定位问题。

四、Docker Desktop配置

在Docker Desktop的Docker Engine配置中加入同样的registry-mirrors，应用并重启后执行：

docker info
docker pull busybox:1.36.1
docker pull 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 get node NODE_NAME \
  -o jsonpath='{.status.nodeInfo.containerRuntimeVersion}'
echo

然后在实际节点复验：

sudo crictl pull k8s.1ms.run/pause:3.10
sudo crictl pull quay.1ms.run/prometheus/prometheus:v3.0.0
sudo journalctl -u containerd --since "10 min ago"

多节点集群要逐节点检查DNS、代理、证书和Registry配置。运维机能拉取，不代表发生ImagePullBackOff的worker节点也能拉取。

六、如何验证一条镜像源

建议分四层：

第一层批量检查可使用本素材包的registry-check.sh：

bash registry-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时先看响应头；看到429时不要无间隔重试；看到超时时先确认卡在DNS、连接还是TLS；看到manifest错误时先核对镜像路径和架构。

八、本月使用建议

1. 先识别镜像的原始Registry，不把所有地址都塞进Docker Hub mirror。
2. 将docker.1ms.run作为Docker Hub入口，将GHCR、K8s、Quay、MCR按前缀分别处理。
3. 公共入口用于解决上游访问，团队生产镜像仍建议进入内部Harbor或Nexus。
4. CI和K8s固定关键镜像的tag或digest，减少重复拉取。
5. 每次记录测试日期、网络出口和验证层级。

这份清单的价值不在于给地址下长期结论，而在于把来源、配置和验证方法放在一起。镜像源会变化，按来源选择并在目标环境复验，才是可以长期复用的做法。