推送镜像至Docker Hub/AWS ECR时部分层反复重试最终失败

该故障核心原因是网络路径上的中间设备篡改了Docker镜像层分块上传的报文内容，和Docker客户端版本、Registry服务端版本无关：

• Docker推送镜像层时采用分块上传机制，每个层上传完成后Registry会对收到的完整内容做SHA256校验，和客户端声明的层哈希做比对，如果不一致就会直接拒绝该层上传，触发客户端重试。
• 网络路径上的运营商透明代理、企业上网行为管理设备、防火墙、家用路由器的HTTP加速模块、广告注入设备都会对未被完全加密识别的HTTP/HTTPS报文做解析篡改，部分二进制内容刚好触发这类设备的篡改逻辑（比如病毒检测误判、内容压缩转码、广告插入、TCP包重组异常），就会导致对应层的校验和永远不匹配。
• 这类篡改是和层内容强绑定的：相同的镜像层二进制内容固定，只要经过同一个中间设备就会被篡改，所以不管重试多少次、把这个层放到哪个衍生镜像里，都会上传失败；不同内容的层不会触发篡改逻辑，就可以正常上传，和观察到的故障现象完全吻合。跨设备（Ubuntu/Mac）、跨Registry（Docker Hub/ECR）故障复现，也排除了客户端、服务端单点故障的可能。

• 本地校验镜像完整性：执行docker save <镜像名:标签> -o test.tar，解压后找到对应失败层ID的layer.tar文件，执行sha256sum layer.tar，确认哈希值和Docker输出的层ID匹配，排除本地镜像损坏问题。
• 切换网络出口测试：连接手机热点等完全独立的网络重新执行推送，如果之前失败的层可以正常上传，即可100%确认是原网络的中间设备篡改问题。

按生效优先级排序：

• 调整Docker daemon配置规避中间设备篡改
  编辑Docker配置文件（默认路径/etc/docker/daemon.json），加入以下配置：

{
  "max-concurrent-uploads": 1,
  "no-http2": true
}

保存后执行systemctl restart docker重启Docker服务，重新推送即可。配置项作用：

• max-concurrent-uploads: 1：关闭并发上传，避免多连接分块时中间设备的TCP包重组异常
• no-http2: true：禁用HTTP/2协议，规避大量老旧中间设备对HTTP/2报文解析错误、随意篡改的问题
• 临时应急方案
  直接切换到无管控的网络出口（比如手机5G热点、独立专线）完成推送，是最快的解决方式，不需要修改任何配置。
• 长期固定网络方案
  如果必须使用原有企业/家庭网络，为Docker配置端到端加密的可信代理，配置方式是在daemon.json中加入代理配置：

{
  "proxies": {
    "https-proxy": "socks5://你的可信代理地址:端口"
  }
}

重启Docker后推送流量会全程走加密隧道，中间设备无法解析篡改报文内容，即可正常上传。

注意：反复重试推送、重建镜像、升级Docker版本都无法解决核心问题，不需要在这类操作上浪费时间。

内容的提问来源于stack exchange，提问作者Joseph Larson