最直接有效的办法是换用稳定、覆盖全的镜像加速服务，如毫秒镜像（1ms.run）已支持 registry.gitlab.com、ghcr.io 等多源同步，实测将拉取时间从47分钟降至2分钟，并需配合 pull_policy: if_not_present、精准缓存配置及本地 registry 缓存代理。
最直接有效的办法是换用稳定、覆盖全的镜像加速服务。很多团队卡在“慢”上，其实不是配置问题，而是镜像源本身不可靠——拉取超时、只加速部分域名、对 registry.gitlab.com 或 ghcr.io 无支持，这些都会让流水线反复卡在 pull 阶段。
换一个真正可用的镜像加速源
别只盯着 Docker Hub 的 mirror，要确认它是否支持你实际用到的所有镜像源：registry.gitlab.com、ghcr.io、registry.k8s.io、quay.io 等。比如毫秒镜像（1ms.run）截至 2026 年 4 月已明确支持多源同步，实测将单次镜像拉取从 47 分钟压到 2 分钟。操作只需两步：
- 修改所有
.gitlab-ci.yml中的image和services地址，把docker.io/node:18换成docker.1ms.run/node:18 - 在 Runner 所在服务器的
/etc/docker/daemon.json里补充该加速地址为全局 mirror（即使 CI 用的是 dind，底层仍走宿主机 Docker）
避免每次作业都重拉基础镜像
GitLab Runner 默认策略是每次作业都 pull 最新镜像，哪怕本地已有。必须显式指定不强制拉取：
- 在
.gitlab-ci.yml的 job 级别加pull_policy: if_not_present - 对 shared runner，建议运维统一在
config.toml中设置pull_policy = "if_not_present"，避免被单个 pipeline 覆盖 - 配合定期预热：用 cron 脚本在低峰期
docker pull常用镜像（如 node:18-alpine、maven:3.9-jdk17），确保首次构建不卡
减少无效缓存干扰镜像拉取效率
缓存配置不当会拖慢整个作业启动流程。常见错误是把 untracked: true 和 paths: ["."] 一起用，导致上传几百 MB 的临时文件、IDE 配置、日志，反而让 cache upload/download 成瓶颈：
- 禁用
untracked: true，改用明确路径：cache: { key: "$CI_COMMIT_REF_SLUG", paths: ["node_modules/", ".m2/"] } - 缓存 key 加入哈希因子，例如
key: "$CI_COMMIT_REF_SLUG-$CI_PROJECT_ID-$(sha256sum package-lock.json | cut -c1-8)"，避免 lock 文件变更后缓存污染 - 对 Java 项目，
.m2/repository是重点缓存目录；Node 项目则聚焦node_modules和~/.npm
用本地 Registry 缓存代理（适合中大型团队）
如果每天构建频次高（>30 次）、镜像源固定，搭一个轻量 Registry 缓存是最彻底的解法：
- 用官方
registry:2镜像启动，配置proxy.cache.enabled=true和proxy.remoteurl=https://registry.gitlab.com - 把 Runner 的 Docker daemon 配置指向这个本地地址（如
http://10.0.1.100:5000），后续所有拉取自动命中缓存 - 搭配 TTL 策略和磁盘清理脚本，防止缓存无限膨胀
