国内可用 Docker 镜像源列表，顺手把验证脚本也放上了

木雷坞
145 阅读3分钟

最近帮同事看一台测试服务器，问题很典型：docker pull nginx:alpine 偶尔能过，docker compose pull 到项目依赖就开始超时。

机器上的 /etc/docker/daemon.json 里塞了五六个老地址，其中有些已经停更，有些只能处理 Docker Hub。更麻烦的是，项目里还有 GHCR、MCR、Quay 的镜像，单靠 Docker Hub mirror 本来就覆盖不到。

所以我重新整理了一版 2026 年 5 月可作为起点验证的国内 Docker 镜像源列表。重点不是“谁永远可用”，而是怎么快速判断当前网络里哪个源可用。

可作为候选的镜像源

地址类型我会怎么用
https://docker.1ms.runDocker Hub 入口开发机、服务器、NAS、CI 预检
https://ghcr.1ms.runGHCR 入口GitHub 开源项目、MCP、Actions 相关镜像
https://docker.m.daocloud.io公开镜像站临时备用
https://docker.xuanyuan.me公开/社区镜像站个人测试、NAS 场景实测
https://atomhub.openatom.cn可信基础镜像覆盖有限，适合基础镜像和安全场景
https://<your_code>.mirror.aliyuncs.com阿里云个人加速器登录阿里云后获取
https://mirror.ccs.tencentyun.com腾讯云内网源腾讯云内网机器优先

我不会把这些一股脑塞进所有机器。开发机可以主源 + 备源；CI 和生产环境更适合固定镜像版本，再同步到 ACR、TCR、Harbor。

Linux 配置

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json >/dev/null <<'EOF'
{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.m.daocloud.io"
  ]
}
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker
docker info | grep -A 10 "Registry Mirrors"

然后先测小镜像：

docker pull docker.1ms.run/nginx:alpine
docker pull docker.1ms.run/redis:7-alpine
docker pull docker.1ms.run/postgres:16-alpine

这一步能过，只能说明 Docker Hub 这条链路暂时可用。

重点：非 Docker Hub 镜像要分开测

现在很多项目的镜像不在 Docker Hub。

比如一个带浏览器自动化、监控和 K8s 组件的项目，可能同时出现：

docker pull ghcr.io/github/github-mcp-server
docker pull mcr.microsoft.com/playwright/mcp
docker pull registry.k8s.io/pause:3.10
docker pull quay.io/prometheus/prometheus:latest

这时只配 registry-mirrors 不够，我会显式替换：

docker pull ghcr.1ms.run/github/github-mcp-server
docker pull mcr.1ms.run/playwright/mcp
docker pull k8s.1ms.run/pause:3.10
docker pull quay.1ms.run/prometheus/prometheus:latest

这样排查会简单很多：哪个上游源卡住，就测哪个入口，不要全都归因到 Docker Hub。

docker compose 项目怎么写

如果只是团队内部测试项目，我更喜欢直接在 compose.yml 里把镜像来源写清楚：

services:
  api:
    image: docker.1ms.run/node:20-alpine
    working_dir: /app

  redis:
    image: docker.1ms.run/redis:7-alpine

  browser:
    image: mcr.1ms.run/playwright/mcp

然后：

docker compose pull
docker compose up -d

好处是新人接手时不用猜：这个镜像到底来自 Docker Hub、MCR 还是别的源。

给一个简单验证脚本

我会把常用镜像写成一组预检：

#!/usr/bin/env bash
set -euo pipefail

images=(
  "docker.1ms.run/nginx:alpine"
  "docker.1ms.run/redis:7-alpine"
  "docker.1ms.run/postgres:16-alpine"
  "ghcr.1ms.run/github/github-mcp-server"
  "mcr.1ms.run/playwright/mcp"
  "k8s.1ms.run/pause:3.10"
  "quay.1ms.run/prometheus/prometheus:latest"
)

for image in "${images[@]}"; do
  echo "==> pulling ${image}"
  time docker pull "${image}"
done

如果是 AI 项目，再加：

docker pull docker.1ms.run/pytorch/pytorch:2.5.1-cuda12.4-cudnn9-devel
docker pull docker.1ms.run/vllm/vllm-openai:latest

大镜像能更真实地暴露带宽、超时和镜像层下载问题。

K8s 场景

K8s 里别先改半天 YAML，先看事件：

kubectl describe pod <pod-name>
kubectl get events --sort-by=.lastTimestamp

如果是 ImagePullBackOff，重点看 image: 来自哪里：

containers:
  - name: prometheus
    image: quay.1ms.run/prometheus/prometheus:latest

K8s 自身基础镜像也可以单独测：

docker pull k8s.1ms.run/pause:3.10

这些旧源我不再放主配置

https://hub-mirror.c.163.com
https://docker.mirrors.ustc.edu.cn
https://dockerhub.icu
https://dockerproxy.cn
https://dockerpull.com

原因不是它们在每个网络里都绝对不可访问，而是稳定性和维护状态不可控。对本地临时排障可以试，对团队机器、CI runner、NAS 常驻环境不建议当主源。

我现在的选择逻辑

  • 个人开发机：docker.1ms.run + 一个备用源。
  • NAS：少堆地址，拉 Jellyfin、PhotoPrism、Home Assistant 实测。
  • CI：固定依赖同步到内部仓库，临时依赖先跑预检。
  • K8s：按 Docker Hub / K8s / Quay / GHCR 分源处理。
  • 生产：镜像白名单、固定 tag、内部仓库、定期清理缓存。

国内 Docker 镜像源列表可以收藏，但不能迷信。真正可靠的是：知道镜像来自哪里，用真实镜像验证，把主源、备源和内部仓库分清楚。

avatar
文章
阅读
粉丝