docker拉取基础镜像超时主因是网络策略与docker行为不匹配，需配置国内镜像加速器、强制登录复用凭证。
CI/CD流水线中Docker拉取基础镜像超时，核心症结往往不是“网络差”，而是“网络策略与Docker行为不匹配”。国内环境直连Docker Hub受限于跨境链路、限流机制和DNS解析延迟，叠加CI环境高频并发拉取，极易触发超时或限流。解决关键在于：绕开公共网络瓶颈、绑定用户配额、减少重复请求。
配置可信国内镜像加速器
这是最直接有效的手段。Docker默认走 registry-1.docker.io（美国节点），国内平均延迟常超200ms且不稳定。必须显式配置国内加速源：
- 推荐使用阿里云、腾讯云或中科大镜像站（如 https://docker.mirrors.ustc.edu.cn），这些服务有CDN节点和稳定带宽
- 修改CI runner所在主机的 /etc/docker/daemon.json：
{ "registry-mirrors": ["https://docker.mirrors.ustc.edu.cn"] } - 重启Docker服务（sudo systemctl restart docker），并在流水线首步验证：
docker info | grep "Registry Mirrors" 确认生效
强制登录Docker Hub账户并复用凭证
匿名拉取受严格限流（每IP每6小时仅200层），而CI环境多节点共用出口IP，极易踩坑。已认证账户限额提升至2000层/6小时，且配额绑定账户而非IP：
- 在CI流程中提前执行 echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin
- 将 $DOCKER_USERNAME 和加密后的 $DOCKER_PASSWORD 配置为CI平台的Secret变量
- 避免使用 python:3.11-slim
预缓存常用基础镜像
CI每次从零拉取是最大浪费。可在runner初始化阶段批量缓存高频镜像，后续构建直接复用本地层：
- 在runner宿主机或CI job开头添加：
docker pull ubuntu:22.04 && docker pull python:3.11-slim && docker pull node:20-alpine - 若使用GitLab CI，可配合 before_script 或自定义基础镜像；GitHub Actions建议用 setup-docker-buildx + cache action
- 搭配 docker image prune -f 定期清理旧镜像，防磁盘占满
调优Docker客户端超时与DNS
默认超时时间（30秒）对弱网CI节点偏短，DNS解析慢也会拖垮整个拉取链路：
- 在 /etc/docker/daemon.json 中增加超时配置：
"max-concurrent-downloads": 10, "max-download-attempts": 5 - 统一指定可靠DNS（如8.8.8.8或114.114.114.114），避免系统DNS污染：
"dns": ["8.8.8.8", "114.114.114.114"] - CI job中加诊断命令：
timeout 10s curl -I https://docker.mirrors.ustc.edu.cn/v2/ 2>/dev/null || echo "加速器不可达"
