daemon.json 不能配置拉取超时和重试，因其由 Docker 客户端控制，daemon 仅负责底层管理；可行方案是升级 CLI 用 --timeout 和 --max-retries、配 registry-mirrors 加速、设 max-concurrent-downloads 限流。
docker 的 daemon.json 文件本身不支持直接配置镜像拉取的重试次数和超时时间。这些参数由 docker 客户端（docker pull）控制，而非 daemon 服务端，因此无法通过 daemon.json 设置。
为什么 daemon.json 不能配拉取超时和重试？
Docker daemon 负责容器运行、镜像存储、网络等底层管理，而镜像拉取（docker pull）是一个客户端发起的、带网络交互的操作，其重试逻辑、超时控制、HTTP 连接行为均由 CLI 或 SDK 在调用 registry API 时实现。daemon 只响应已缓存或已下载完成的镜像请求，并不参与拉取过程中的网络策略决策。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
实际可行的替代方案
-
使用 --timeout 和 --max-retries（Docker CLI v24.0+）：较新版本 Docker（≥24.0）在
docker pull中新增了原生命令行参数：docker pull --timeout 300s --max-retries 5 nginx:alpine
其中--timeout单位支持s/m，--max-retries默认为 3，最大可设为 10。 -
通过环境变量临时生效（部分场景）：某些构建工具（如 BuildKit）会读取
DOCKER_CLI_TIMEOUT或REGISTRY_AUTH_TOKEN_TIMEOUT，但这些不通用，且不适用于标准pull。无全局生效的环境变量控制拉取重试/超时。 -
配置 registry 的 HTTP 客户端行为（高级）：若使用自建 registry，可在其后端（如 Nginx、Traefik）设置上游连接超时、重试；或通过
~/.docker/config.json配置认证和镜像源别名，间接影响拉取路径和稳定性，但不改变重试逻辑。
daemon.json 能配什么相关参数？
虽然不能设重试与超时，但可通过以下配置提升拉取稳定性：
-
registry-mirrors：添加国内镜像加速器（如阿里云、腾讯云），显著降低超时概率； -
max-concurrent-downloads：限制并发下载层数（默认 3），避免带宽打满导致个别层超时； -
insecure-registries：若用 HTTP 自建 registry，需显式声明，否则拉取会因 TLS 拒绝而“假超时”； -
features启用 BuildKit（"buildkit": true）：新版 BuildKit 的拉取器有更健壮的断点续传和错误恢复能力，间接减少失败重试需求。
小结：该配哪？怎么配？
不要在 daemon.json 里找 pull-timeout 或 retry-count——它们不存在。真正要做的只有三件事：
• 升级 Docker CLI 到 24.0+，用 --timeout 和 --max-retries 显式控制单次拉取；
• 在 daemon.json 中配好 registry-mirrors 和 max-concurrent-downloads 提升整体成功率；
• 对于 CI/CD 等自动化场景，用 shell 脚本封装重试逻辑（如 until docker pull ...; do sleep 2; done），更灵活可靠。
