default-timeout字段用于设置Docker守护进程默认操作超时时间，单位支持s/ms等，如"600s"表示10分钟，影响docker stop、wait、build（非BuildKit）、pull部分HTTP请求等，修改后需重启docker服务生效。
可以在 /etc/docker/daemon.json 中通过 default-timeout 字段设置 docker 守护进程的默认操作超时时间，单位支持 s（秒）、ms（毫秒）等后缀，最常用的是秒级配置。
直接配置 default-timeout
该参数控制 Docker 客户端向守护进程发起请求（如 docker build、docker pull、docker stop 等）时，守护进程等待底层操作完成的最长时限。超时后会主动中断并返回错误，避免卡死。
- 编辑或新建
/etc/docker/daemon.json，加入以下内容：
{
"default-timeout": "600s"
}
-
"600s"表示默认超时为 10 分钟；也可写成"300"（不带单位默认为秒）或"120000ms" - 保存后执行
sudo systemctl restart docker生效 - 该值对所有未显式指定
--timeout的命令生效，例如docker stop默认就按此值等待容器停止
哪些操作受 default-timeout 影响
不是所有命令都走这个超时逻辑，主要覆盖以下场景：
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
-
docker stop：等待容器内主进程退出的时间上限 -
docker wait：等待容器状态变更的最大时长 -
docker build（非 BuildKit 模式）：单步指令执行或网络拉取环节的阻塞等待 -
docker pull中部分底层 HTTP 请求的连接与响应等待（但镜像层下载本身还受max-concurrent-downloads和网络栈影响）
注意点和常见误区
default-timeout 是守护进程级全局默认值，不能按镜像、容器或用户做差异化设置。它不替代网络层超时（如 TCP keepalive），也不控制 BuildKit 构建中的缓存拉取超时（BuildKit 使用独立的 buildkitd.toml 配置）。
- 若某次
docker pull仍频繁报net/http: TLS handshake timeout，说明问题在 DNS 解析或首次 HTTPS 握手阶段，此时需配合registry-mirrors或调大dns配置 - 若构建中某层下载卡住不动，更可能是并发数或镜像源问题，可额外设置：
"max-concurrent-downloads": 10 - 该字段自 Docker 1.12+ 起稳定支持，无需开启 experimental 模式
