推送大体积镜像超时源于网络抖动、服务端限流与客户端配置僵化，优化需三管齐下：精简镜像体积（多阶段构建、清理缓存、选用轻量基础镜像）、调优docker守护进程（降并发、增重试）、验证并确保registry支持断点续传及head请求。
推送大体积镜像时网络超时中断，本质是传输过程受网络抖动、服务端限流、客户端配置僵化三重影响。核心不是“重传整个镜像”，而是让每层上传更稳、可跳过、可恢复。
优化镜像体积，从源头降低传输压力
体积过大是超时的底层诱因。单层超过500MB就容易触发 registry 的连接空闲超时或 TLS 握手失败。
- 用多阶段构建（multi-stage build），只把运行时必需的二进制和配置 COPY 到最终镜像
- 构建后清理 apt/yum 缓存、临时文件、调试工具：RUN apt-get clean && rm -rf /var/lib/apt/lists/*
- 优先选用 alpine 或 distroless 基础镜像，比如 node:18-alpine 比 node:18-slim 小 30%～50%
- 避免 ADD 大压缩包，改用 RUN curl + tar -xzf 并立即清理下载文件
调整 Docker 守护进程参数，增强上传容错性
默认并发上传数（3）和无超时保护，在弱网或私有 registry 下极易卡死。需修改 /etc/docker/daemon.json：
-
降低并发数：设
"max-concurrent-uploads": 1，减少 TCP 连接竞争，提升单层成功率 -
启用重试机制：加
"max-download-attempts": 5（虽名 download，但部分版本也影响 push 重试逻辑） - 配合镜像加速器：若推送到私有 registry，确保它本身已配置上游 mirror；若推 Docker Hub，国内用户建议加 registry-mirrors（部分企业版支持反向代理 Hub 流量）
- 修改后执行
sudo systemctl daemon-reload && sudo systemctl restart docker
确认 registry 支持断点续传，避免重复上传整层
Docker 不是全量重传，而是基于 layer digest 跳过已存在的层——但这依赖 registry 正确响应 HEAD 请求。
- 用 curl 手动验证某层是否已存在：
curl -I -H "Authorization: Bearer $TOKEN" https://your-registry/v2/your-repo/blobs/sha256:abc123...
返回200 OK且含Docker-Content-Digestheader，说明可跳过 - 若返回
401 Unauthorized，说明 token 过期，需重新docker login或刷新 bearer token - 若返回
404 Not Found，该层确实未上传，需重传 - 老旧 Harbor 版本可能禁用 HEAD 方法，此时需升级 registry 或启用
storage配置中的delete和head权限
封装带智能重试的推送脚本，规避瞬时故障
单纯手动重试效率低，且无法区分可重试错误（如超时）与不可重试错误（如 401、404）。
- 对
net/http: request canceled、i/o timeout、429 Too Many Requests类错误自动重试 - 对
unauthorized、repository does not exist等直接退出并提示登录或检查镜像名 - 采用指数退避：首次等 3 秒，第二次等 6 秒，第三次等 12 秒
- 示例关键逻辑：
if [[ "$output" =~ "i/o timeout|request canceled|429" ]]; then<br> sleep $((retry_delay * 2**i))<br>else<br> echo "不可重试错误，终止"; exit 1<br>fi
