最直接有效的解决方案是登录 docker hub 账户并注入 ci 环境变量，将每 6 小时拉取配额从 200 层提升至 5000 层；同时配合预拉取常用镜像、固定版本 tag、启用 overlayfs 存储驱动与共享缓存、部署 registry proxy 缓存代理及临时切换国内镜像源等策略，系统性降低重复请求与限流风险。
拉取公共镜像频发触发限流，核心不是“怎么重试”，而是避免重复触达配额。关键在减少实际向 Docker Hub 发起的层拉取请求，同时提升单次拉取成功率和复用率。
登录账户并注入 CI 环境变量
未认证时每 6 小时仅限 200 层，登录后升至 5000 层——这是最直接、成本最低的提额方式。
- 在 GitLab CI 或 GitHub Actions 中，配置 DOCKERHUB_USERNAME 和 DOCKERHUB_TOKEN（非密码，用 Personal Access Token）
- 流水线开头执行：
echo "$DOCKERHUB_TOKEN" | docker login -u "$DOCKERHUB_USERNAME" --password-stdin - 注意：Token 需开启
read:packages权限；避免硬编码，始终通过 secret 注入
预拉取 + 固定 tag + 共享存储驱动
高频失败常因每个 job 都从零拉取相同镜像，比如 node:18-slim，哪怕只差一个 layer hash，也算一次新拉取。
- 自建 Runner 宿主机启动时，统一执行
docker pull node:18.19.0-slim nginx:1.25.4-alpine等常用镜像 - CI 配置中禁用
latest，全部改用带完整版本号的 tag（如python:3.11.9-slim），确保 layer 可复用 - 启用 overlayfs 存储驱动，并在
.gitlab-ci.yml中设置cache: { policy: pull-push }，让 runner 间共享已解压层
部署轻量级镜像代理缓存
把多节点并发请求收敛为单点出口，彻底绕过 IP 维度限流，适合中大型团队长期使用。
- 用官方 registry:2 搭建 proxy cache：
proxy: { remoteurl: "https://registry-1.docker.io" } - 所有 job 改为拉取
your-cache.example.com/library/node:18.19.0-slim，首次请求会透传并缓存，后续全走本地 - 配合 GitLab 内置 Container Registry，将高频基础镜像提前同步进去，CI 直接拉
$CI_REGISTRY/node:18.19.0-slim，完全脱离 Docker Hub
临时兜底：切换国内可信镜像源
当代理未就绪或突发限流时，快速降级到稳定加速源，避免流水线大面积中断。
- 修改 Runner 宿主机的
/etc/docker/daemon.json，加入国内镜像站（如 Docker 官方中国 CDN："https://registry.docker-cn.com"） - 若企业网络屏蔽外部镜像站，可临时改用华为云、中科大或网易的镜像源（需验证同步时效性）
- 注意：部分镜像源不保证 100% 同步，生产环境建议仅用于紧急恢复，不替代长期策略
