Docker客户端无日志级别配置，仅支持-D/--debug输出HTTP请求响应；日志级别（debug/info等）仅作用于守护进程dockerd，通过daemon.json配置并影响journalctl输出。
docker 客户端（docker 命令）本身不产生运行时日志，也不支持配置日志级别（如 --log-level=debug 对客户端无效）。你看到的 --log-level 参数仅作用于 docker 守护进程（dockerd），而非客户端。
所以严格来说：
客户端没有日志级别可配 —— 它不会向 syslog、文件或 stdout/stderr 持续输出调试信息；它只是向守护进程发起 API 请求，并把响应结果格式化后打印到终端。
但有两类“输出控制”常被误认为是“客户端日志级别”，实际如下：
1. 客户端命令的调试模式（-D 或 --debug）
这是唯一影响客户端行为的“详细输出”开关： - 加 `-D` 或 `--debug` 后，客户端会打印完整的 HTTP 请求头、请求体、响应头和响应体（含 API 调用路径、状态码、原始 JSON） - 仅用于临时排障，不持久，不写入文件，不依赖 daemon.json - 示例： `docker -D ps``docker --debug info`2. 守护进程日志级别（影响你看到的“系统级日志”，但非客户端本身）
当你执行 `docker logs`、`docker ps` 等命令时，客户端只是转发请求。真正打日志的是 `dockerd`。它的日志级别决定： - `journalctl -u docker.service` 中能看到多少细节（如连接建立、驱动加载、容器启动步骤） - 是否记录网络插件调用、存储驱动操作、健康检查触发等底层事件配置方式（只对 dockerd 生效）：
- 编辑
/etc/docker/daemon.json，添加：{"log-level": "debug"}
支持值：debug、info、warn、error、fatal - 重启守护进程：
sudo systemctl restart docker - 验证：
sudo journalctl -u docker.service --since "1 hour ago" | head -20
3. 客户端错误提示的“详细程度”由服务端返回决定
比如： - 运行一个失败的容器，`docker run` 输出的错误文本长度，取决于 `dockerd` 返回的错误消息是否包含堆栈或上下文（由守护进程内部逻辑和日志级别间接影响） - 但客户端不做额外日志分级处理，也不会因设置某参数就“多打几行 debug”4. 实际建议：别试图调客户端日志，聚焦两端
- 排查命令失败？优先用 `-D` 看请求/响应流 - 怀疑守护进程异常？调高 `log-level` 并查 `journalctl` - 容器内应用日志混乱？那是应用自身要配置（如 Nginx 的 `error_log /dev/stderr warn;`），和 Docker 客户端完全无关不复杂但容易忽略：客户端只是个薄命令行外壳，真正的日志行为全在守护进程和容器应用里。
