docker pull 默认并发数是3，控制同时下载的layer数量而非单layer内部分块；调高需结合registry限流、磁盘I/O和TLS开销综合评估，推荐设为5–20。
直接改 max-concurrent-downloads 是最有效的方式，但必须理解它作用在哪、为什么不能只靠调高数值——它控制的是「同时发起多少个 layer 下载请求」，不是单个 layer 内部的分块并发，也不是镜像整体下载速度的万能开关。
并发数默认只有 3，是多数慢拉取的根源
docker pull 默认只并发下载 3 个 layer。哪怕你带宽有 500MB/s，只要 registry 允许、磁盘不拖后腿，实际吞吐也常卡在 30–50MB/s。这不是网络问题，是客户端主动限流。尤其在内网高速环境或私有 Harbor 部署中，这个值几乎必然成为瓶颈。
- 该参数由 dockerd 守护进程控制，不是
docker pull命令行选项 - 影响范围是所有后续 pull 操作，全局生效
- 20.10+ 版本才真正支持动态识别该配置；19.03 及更早版本即使写入 daemon.json 也无效
正确修改并发配置的方法
编辑 /etc/docker/daemon.json，加入或修改：
{"max-concurrent-downloads": 10}推荐值为 5–20。设超过 50 意义不大，反而可能触发 registry 端限流或本地 TLS 握手堆积。
- 保存后执行
sudo systemctl restart docker - 验证是否生效：
docker info | grep "Max Concurrent Downloads" - 若提示 unknown configuration key，说明 dockerd 版本过低，需升级
别忽略 registry 侧的限流压制
就算你把并发设成 100，如果 registry 自身做了 QPS 限制，实际请求数仍会被截断，甚至返回大量 429 Too Many Requests。
- Harbor 默认匿名请求限 5 QPS，登录后升至 50；需检查
harbor.yml中rate_limits配置 - AWS ECR 按 IP 统计，1000 请求/分钟（≈16 RPS），多台 Worker 共用出口 IP 时极易撞限
- 遇到
error pulling image configuration: unknown blob或日志频繁出现 429，优先查 registry 监控，而非调 client 并发
--platform 参数会间接改变并发行为
加 --platform linux/arm64 后，Docker 会重新解析 manifest list，可能命中不同架构的子 manifest，导致下载的 layer 集合变化——有的 layer 原本不拉，现在要拉；有的 layer 大小差异显著，从而改变实际并发请求的目标数量和负载分布。
- 例如拉
alpine:latest不加平台，通常只下当前主机架构 layer - 加平台后可能触发跨架构基础镜像拉取，layer 数量增加，但单个并发连接数不变，总耗时反而上升
- 批量部署前建议统一平台标识，并预热对应架构镜像到各节点
