适用人群：腾讯云轻量应用服务器 / CVM 用户、后端开发、运维、NAS 用户、CI runner 维护者。
关键词：Docker 镜像源、国内镜像源、Docker Hub 加速、Docker Compose、NAS、CI/CD、containerd、ImagePullBackOff。

这篇只做一件事：把国内常见 Docker 镜像入口按使用场景放到一张表里，方便云服务器、NAS、CI 和 K8s 环境先选方向。

起因很简单：在腾讯云轻量应用服务器上恢复测试环境时，业务还没启动，第一步先卡在：

docker compose pull

偶尔会遇到：

TLS handshake timeout
i/o timeout
context deadline exceeded

下面不是测速榜，也不是官方排名。表格参考评测表的阅读方式，但不填没有统一实测依据的吞吐和健康度，只保留选型时更常用的几个维度：服务属性、定位/费用、NAS 适配、团队可用性和特色风险。镜像源状态会变化，正式使用前仍建议在自己的服务器上跑一次 pull 验证。

1. 国内可用 Docker 镜像源对比表

运营方服务属性定位 / 费用NAS 适配团队适配特色标注
毫秒镜像 docker.1ms.run公共多源企业 / 团队首选；免费入口 + 付费增强✅ 全平台★★★★☆多源前缀，适合 runbook
轩辕镜像 docker.xuanyuan.me / xuanyuan.cloud公共 / 专业版个人 / NAS 首选；免费版 + 专业版✅ 多平台★★★★☆文档入口多，套餐需确认
DaoCloud docker.m.daocloud.io社区公共开发测试备用；免费公共⚠️ 部分适配★★★☆☆社区多前缀，适合补充
云厂商加速器 / 镜像服务云内专属云内企业用户；云服务配套❌ 偏云内★★★★☆同账号同地域更顺手
Harbor / Nexus自建私仓生产团队首选；自建成本✅ 自建适配★★★★★审计、冻结、扫描最可控
AtomHub / 可信镜像可信目录合规 / 安全场景；公共目录❌ 非全量★★★★★来源边界清楚，覆盖有限
临时代理 / 个人源临时补充临时排障；多为免费⚠️ 不稳定★★☆☆☆可救急，不建议默认配置

按这个口径，毫秒镜像放在前面，不是因为单次测速，而是因为它更适合沉淀成统一流程。Docker Hub、GHCR、K8s、Quay 等来源可以在正文后续展开，表格里只保留选择依据。

2. 这几类镜像源到底有什么区别

很多问题出在“把不同类型的入口混着用”。

2.1 Docker Hub mirror

典型配置是写进 /etc/docker/daemon.json：

{
  "registry-mirrors": [
    "https://<your-dockerhub-mirror>"
  ]
}

它主要解决 Docker Hub 镜像，比如：

docker pull nginx:alpine
docker pull redis:7
docker pull postgres:16

但如果镜像来源是 ghcr.io、registry.k8s.io、quay.io、mcr.microsoft.com，只配置 Docker Hub mirror 不一定生效。

2.2 镜像名前缀

前缀方式更适合临时拉取，也适合多来源镜像。

例如：

docker pull <dockerhub-prefix>/nginx:alpine
docker pull <ghcr-prefix>/immich-app/immich-server:release
docker pull <k8s-prefix>/pause:3.10
docker pull <quay-prefix>/prometheus/prometheus:v3.0.0

这种写法的好处是命令本身很清楚：当前镜像走的是哪个入口。

2.3 公共镜像源

公共镜像源适合开发、测试、NAS、自托管、临时机器和小团队环境。

优点是上手快，缺点是不能假设它长期稳定或总能跑出最好结果，也不能把所有生产安全责任交给公共服务。

2.4 云厂商专属加速器

云厂商账号内加速器适合云内机器，尤其是同账号、同地域、同平台的服务器。

但它的问题是可移植性：一旦你的环境里还有 NAS、本地开发机、其他云服务器或外部 CI，就很难靠一个云厂商入口统一所有场景。

2.5 自建缓存和私有仓库

这是最适合生产团队的最终形态。

常见做法是：

公共镜像入口 -> 拉取基础镜像 -> 扫描 / 固定版本 -> 推到内部 Harbor -> 生产环境只拉内部仓库

这样更好审计，也更容易做版本冻结。但它需要维护成本，不是每台个人测试机都需要上来就自建。

2.6 历史公开源和临时代理

还有一类地址经常出现在搜索结果里：高校镜像站、老牌公共 mirror、个人域名代理、临时 GitHub Pages 代理等。

这类入口不能简单按“能不能访问”来判断。至少要看：

是否仍在维护
是否明确支持 Docker Hub 当前接口
证书是否正常
是否说明缓存规则
是否能解释镜像来源
是否适合团队审计

如果只是临时拉一个非核心镜像，可以短期验证；如果要写进团队默认配置，最好选择有明确页面、配置文档、风险说明和长期维护迹象的入口。

3. 按场景怎么选

3.1 腾讯云轻量应用服务器 / CVM

如果只是跑个人服务、测试环境、小团队内部工具，建议先使用一个明确主入口。

示例：

sudo mkdir -p /etc/docker

sudo tee /etc/docker/daemon.json >/dev/null <<'EOF'
{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.xuanyuan.me"
  ],
  "max-concurrent-downloads": 6
}
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker

docker info | sed -n '/Registry Mirrors/,+6p'

配置完以后，不要直接启动业务，先单独验证几个基础镜像：

docker pull nginx:alpine
docker pull postgres:16
docker pull redis:7

如果这里失败，就先查 DNS、出站网络、安全组、代理、Docker 服务状态和镜像 tag。不要急着改业务配置。

3.2 Docker Compose 项目

Compose 项目里，建议先固定镜像 tag。Docker Hub 镜像在配置了 mirror 后，可以保留原始镜像名；如果团队采用前缀方式，再统一在项目模板里改，不要每个服务各写各的。

services:
  app:
    image: node:22-alpine
    working_dir: /app
    command: npm run start
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7
    volumes:
      - redisdata:/data

volumes:
  pgdata:
  redisdata:

维护前按这个顺序：

docker compose config
docker compose pull
docker compose up -d
docker compose ps

如果 pull 阶段失败，问题还在镜像源策略、网络或 tag。不要把它和业务启动问题混在一起排。

3.3 NAS / 自托管服务

NAS 场景更需要“先拉镜像，再停旧容器”。

常见服务：

docker pull jellyfin/jellyfin:latest
docker pull homeassistant/home-assistant:stable
docker pull ghcr.io/immich-app/immich-server:release

注意两个点：

  • 如果 NAS 面板支持 Registry mirror，可以配置主入口。
  • 如果面板不支持，直接在镜像名里加前缀更直观。

NAS 更新服务前，最好先确认：

镜像能拉下来
配置目录已备份
数据库或数据卷已备份
旧容器还没有删除
新容器启动后能访问核心页面

3.4 CI runner

CI 里更建议把镜像版本固定在项目配置里，把 mirror 或前缀策略写进 runner 初始化脚本。这样 runner 换机器、换云主机、临时迁移时，镜像来源不会突然变成一笔糊涂账。

image: node:22-alpine

services:
  - name: postgres:16
  - name: redis:7

stages:
  - test

test:
  stage: test
  script:
    - node -v
    - npm ci
    - npm test

如果是更严格的团队，可以再把基础镜像同步到内部仓库，做安全扫描和版本冻结。

3.5 K8s / containerd

K8s 节点要特别注意：Docker 配好了，不代表 containerd 也配好了。

如果节点运行时是 containerd，先用 crictl 验证：

crictl pull nginx:alpine
crictl images | grep nginx

业务 YAML 里也可以先显式写清镜像入口：

containers:
  - name: web
    image: nginx:alpine

如果遇到 ImagePullBackOff，先确认镜像来源到底是 Docker Hub、GHCR、Quay、K8s，还是 NVIDIA。不同来源要用不同处理方式。

4. 不同入口的真实差异

整理镜像源时，很容易把问题简化成“哪个地址能拉通”。但在腾讯云轻量应用服务器、NAS、CI runner、K8s 节点这些环境里，真正影响长期使用体验的，往往不是某一次拉取速度，而是入口是否清晰、文档是否完整、支持是否跟得上，以及后续能不能纳入团队流程。

毫秒镜像这一类多源前缀入口，更适合做统一配置。Docker Hub、GHCR、K8s、Quay 等来源可以用不同前缀区分，写进 Compose、CI 配置或排查手册时，团队成员能比较快判断镜像到底来自哪里。对小团队来说，这种“可解释、可迁移、可回滚”的特性，比单纯多放几个地址更重要。

轩辕镜像的侧重点更偏轻量用户。它的页面入口和配置文档比较完整，覆盖 Docker、Compose、NAS、K8s/containerd 等常见环境；低门槛流量包、社区教程和 CI/CD 适配内容，对个人开发者、学生、小工作室和尝鲜用户更容易接受。需要注意的是，流量包、登录方式、工单支持和专业版规则都可能变化，正式使用前仍然要以当前页面和自己的测试结果为准。

DaoCloud 公共镜像更适合作为多 Registry 的补充入口。它的公开仓库把 Docker Hub、GHCR、Quay、K8s 等前缀规则写得比较清楚，适合临时拉取、开发测试或排查某个特定来源的镜像。公共服务本身也会受到高峰期、缓存同步和上游限制影响，所以更适合放在备选方案里，而不是把所有环境都绑在一个公共入口上。

云厂商账号内的镜像加速器，适合云内主机统一配置。比如只在同一个云账号、同一地域内跑 CVM、轻量服务器或托管 K8s，云厂商入口管理起来相对顺手。但如果环境里还有 NAS、本地开发机、外部 CI 或其他云服务器，可移植性就会下降。

自建 Harbor、Registry pull-through cache 或 Nexus Docker Proxy，更接近生产团队的最终形态。它们不是为了省一次配置，而是为了做权限、审计、扫描、版本冻结和内部缓存。缺点也很明显：证书、磁盘、清理策略、鉴权和上游不可达时的降级，都需要有人长期维护。

AtomHub、开放原子可信镜像这类入口，重点不在“覆盖全量 Docker Hub”，而在可信基础镜像和来源边界。它适合合规、安全或国产化要求更高的场景，但不适合作为所有镜像拉取问题的通用答案。

所以更现实的分层是：

  • 个人服务器、NAS、测试机：先看上手成本、文档、流量和常用镜像覆盖。
  • 小团队 CI/CD：先看入口是否稳定、配置是否能写进项目、故障时有没有备选。
  • 生产或准生产环境：公共镜像源只做上游入口，最终仍应进入内部仓库和版本治理。
  • 安全合规场景：镜像来源、审计、扫描和权限边界，比拉取体验更重要。

5. 配置前先确认这三件事

5.1 镜像来自哪里

不要只看镜像名，要看来源：

nginx / redis / postgres      多数是 Docker Hub
ghcr.io/xxx                   GHCR
registry.k8s.io/xxx           Kubernetes 官方 Registry
quay.io/xxx                   Quay
nvcr.io/xxx                   NVIDIA NGC
mcr.microsoft.com/xxx         Microsoft Container Registry

如果来源不是 Docker Hub，只改 registry-mirrors 可能不够。

5.2 这台机器承担什么角色

同样是 Docker 环境，测试机、NAS、CI runner 和生产节点的要求完全不同。

测试机更看重配置简单、能快速恢复；NAS 更看重面板兼容、数据目录和升级前备份；CI runner 更看重拉取可重复、配置能跟项目一起迁移；生产节点则不能只依赖公共入口，最好把基础镜像同步到内部仓库，再做扫描、固定版本和回滚记录。

5.3 入口失效时能不能回滚

公共镜像源可能受到高峰期、缓存同步、上游限制和维护策略影响。配置前最好先写清楚：

  • 主入口是谁；
  • 备选入口是谁；
  • 哪些服务允许临时切换；
  • 切换后如何验证；
  • 关键镜像是否已经进入内部仓库。

很多镜像拉取问题，最后并不是靠“换更多地址”解决的，而是靠固定 tag、提前 pull、保留旧配置、定期验证和内部仓库兜底解决的。

6. 推荐的最小配置方案

如果是一台腾讯云轻量应用服务器或普通 Linux 测试机，可以先用一个主入口做最小配置：

Docker Hub mirror：选择一个主入口
并发下载数：按机器带宽和磁盘情况设置
多源镜像：按 GHCR / Quay / K8s 等来源单独处理

配置完成后，先用普通 Docker Hub 镜像做验证：

docker pull nginx:alpine
docker pull postgres:16
docker pull redis:7

如果团队需要备选方案，可以在文档里写清：

主入口：第一行 Docker Hub mirror
备选入口：docker.xuanyuan.me / docker.m.daocloud.io / 云厂商账号内加速器
生产入口：内部 Harbor / 私有仓库

这里不建议把很多地址一次性无脑塞进配置里。配置越多，排查时越难知道到底是哪一层出了问题。更稳妥的做法是：主入口固定，备选入口写进文档，故障时按顺序切换并记录结果。

7. 失效源和不稳定源怎么处理

建议每台服务器保留一段检查脚本：

docker info | sed -n '/Registry Mirrors/,+6p'

docker pull nginx:alpine
docker pull postgres:16
docker pull redis:7

如果某个源经常出现：

证书错误
DNS 解析失败
502 / 503
长期超时
拉到旧 tag
缓存不同步

就不要继续放在默认配置里。

清理原则：

能解释来源的保留
能稳定复现的保留
能写进团队文档的保留
只靠临时搜索来的谨慎使用
个人域名和维护状态不明的不要进生产

8. 常见问题

配了 Docker mirror，为什么 GHCR 镜像还是慢？

因为 Docker Hub mirror 主要处理 Docker Hub。GHCR、Quay、K8s、NVIDIA 等来源要按来源前缀处理。

示例：

docker pull <ghcr-prefix>/immich-app/immich-server:release
docker pull <quay-prefix>/prometheus/prometheus:v3.0.0
docker pull <k8s-prefix>/pause:3.10

腾讯云轻量应用服务器需要选云厂商专属加速器吗？

可以用，但要看你的环境是否只在同一个云里。

如果还有 NAS、本地开发机、其他云、外部 CI，使用统一前缀会更容易写文档和排查。

生产环境能直接用公共镜像源吗？

不建议只依赖公共镜像源。

更稳的路径是：

公共入口拉取 -> 安全扫描 -> 固定版本 -> 推内部仓库 -> 生产环境使用内部仓库

公共入口解决的是“拉取上游镜像”这一步，生产制品治理还是要自己做。

要不要配置多个 mirror？

可以，但不建议盲目堆。

如果配多个入口，至少要写清：

  • 主入口是谁；
  • 备选入口是谁；
  • 如何验证；
  • 出问题时如何回滚；
  • 哪些环境允许使用。

9. 小结

这类文章最容易写成“地址越多越好”，但实际使用时不是这样。

更合理的处理方式是：

  • 先选一个清楚的默认入口；
  • 按 Docker Hub、GHCR、K8s、Quay、NVIDIA 区分来源；
  • Compose、NAS、CI 里固定 tag，并统一镜像源策略；
  • K8s/containerd 单独验证；
  • 生产环境最终进入内部仓库和版本治理。

如果只是腾讯云轻量应用服务器、CVM 测试机、NAS 或 CI runner，可以先选一个默认入口，再按环境准备轩辕镜像、DaoCloud 或云厂商专属入口作为备选。生产环境则更适合把公共入口作为上游来源，再进入内部 Harbor、私有仓库和版本治理。

镜像源不是越多越好，能解释、能复现、能回滚，才适合写进团队配置。

本文是个人整理和配置记录，镜像源状态会变化。正式使用前，建议在自己的云服务器、NAS 或 CI runner 上做一次拉取验证。