Docker Push 报错“dial tcp: i/o timeout”是网络层超时，需逐层排查TCP/TLS连接、DNS、代理及registry可达性，而非单纯调高超时；重点验证curl测HTTPS健康、config.json域名匹配、证书信任及insecure-registries配置。
DockerPush 报错 “dial tcp: i/o timeout” 怎么办
这是最典型的网络层超时，不是镜像或配置问题，而是 Docker CLI 无法在默认时限内连上远程 registry 的 443 端口。常见于公司内网、代理环境、DNS 不稳或 registry 响应慢的场景。
关键不是重试，而是确认连接路径是否通、超时是否可调：
-
docker login成功 ≠docker push能通——login 可能走缓存或短连接，push 是长上传，更敏感 - 用
curl -v https://your-registry.com/v2/手动测 registry HTTPS 健康状态，看是否卡在 TCP 握手或 TLS 握手 - Docker 客户端本身不提供全局 socket 超时配置项，但可通过
DOCKER_CLI_TIMEOUT环境变量延长 CLI 命令整体等待上限（仅对部分版本有效，Docker 24.0+ 开始支持） - 真正起作用的是系统级设置：Linux 下调整
/etc/docker/daemon.json中的default-ulimits或宿主机的net.ipv4.tcp_fin_timeout影响不大，重点查net.core.somaxconn和 DNS 缓存
registry 返回 “no basic auth credentials” 却已 login
看似认证失败，实则是凭据未正确关联到目标 registry 域名。Docker 的 auth 配置按完整域名（含端口）匹配，docker login my-registry.internal:5000 和 docker push my-registry.internal:5000/app:v1 必须完全一致——少个端口、多一个 https:// 前缀都会导致凭据失效。
- 检查
~/.docker/config.json中auths字段下的 key 是否与 push 目标 registry 完全一致（包括协议、端口、大小写） - 私有 registry 若用自签名证书，必须把证书加到宿主机信任链，并在 daemon.json 中配置
"insecure-registries": ["my-registry.internal:5000"]（仅限测试环境） - 使用
docker-credential-pass等外部凭据助手时，确保其二进制在$PATH且可执行，否则docker login表面成功，实际凭据未落盘
push 卡在 “pushing” 阶段不动，几小时没反应
这不是超时，是底层上传流被阻塞。Docker 默认用分块上传（blob + manifest），一旦某一层上传开始，就不再响应 Ctrl+C，且无进度粒度反馈。
- 用
docker events --filter event=push在另一终端监听，确认是否真卡住，还是只是慢（尤其小带宽上传大镜像层时） - 禁用并发上传可降低出错概率：
DOCKER_CLI_EXPERIMENTAL=enabled docker push --max-concurrent-uploads 1 your-registry/app:v1 - 镜像含大量小文件层（如未优化的
COPY . /app）会显著拖慢上传速度，建议用docker build --squash（旧版）或docker buildx build --squash合并层 - 某些 registry（如 Harbor 2.0+）对 manifest 大小有限制，默认 5MB，超限会静默失败——用
docker manifest inspect查看生成的 manifest JSON 大小
CI 环境下 Push 随机失败，本地却稳定
根本差异在于网络稳定性与资源隔离。CI runner 通常复用宿主机网络命名空间，但可能受限于共享出口 IP、NAT 超时、DNS 轮询抖动或临时磁盘满（影响 layer 缓存压缩）。
- 不要依赖
docker login输出判断成功——CI 中 stdout 可能被截断，改用docker info | grep -q "your-registry"或检查~/.docker/config.json是否写入对应 auth - 在 push 前加健康检查：
timeout 10s bash -c 'until docker registry ping -d your-registry.internal; do sleep 2; done' - 避免在 CI 中用
docker build+docker push两步分离——build 缓存可能丢失，导致重复构建再推送；改用docker buildx build --push一气呵成，减少中间态依赖 - 某些云 CI（如 GitLab Runner）默认启用
privileged: false，会导致 overlay2 驱动性能下降甚至上传中断，需显式开 privileged 或换 vfs 驱动（仅限调试）
socket 超时背后往往不是时间设得不够长，而是连接路径上某个环节在静默丢包、DNS 回退或 TLS 版本协商失败——盯着错误信息里的 host 和 port，一层层 ping、curl、openssl s_client 比调 timeout 参数管用得多。
