Docker Desktop 怎样为容器查看健康检查状态

如果 Docker Desktop 里一个容器显示 running，并不代表应用已经可以接收请求。健康检查是镜像或启动参数里定义的探针，容器还会额外拥有 starting、healthy 或 unhealthy 状态。查看时要先在 Containers 视图定位容器，再进入详情看健康信息。

本文使用 Docker Desktop 的桌面 Dashboard，不操作真实容器，也不把配图当作截图。Docker Desktop 官方地址：https://www.docker.com/products/docker-desktop/；Containers 文档：https://docs.docker.com/desktop/use-desktop/container/。

最短路径是：打开 Containers → 搜索容器 → 打开容器详情 → 查看健康状态；如果状态是 unhealthy，再到 Logs 和 Inspect 找探针失败线索。只看列表中的运行状态，无法判断应用健康。

1. 先准备一个真正带健康检查的容器

Docker Desktop 只能展示 Docker Engine 已计算出的健康状态。先确认镜像里有 HEALTHCHECK，或创建容器时传入 --health-cmd 等参数；没有探针的容器通常只有运行、停止等生命周期状态，不会凭空出现健康结论。

下面是一个只用于说明配置关系的 Dockerfile 示例。探针访问容器内的本地 HTTP 服务，命令退出码为 0 才算通过；请根据自己的镜像确认 wget 或其他探针工具确实存在。

FROM nginx:alpine

# 给容器留出启动时间，避免刚启动时的失败被立即算入重试次数
HEALTHCHECK --interval=10s --timeout=3s --start-period=15s --retries=3 \
  CMD wget -q -O /dev/null http://127.0.0.1/ || exit 1

# 保持前台运行，让容器主进程持续提供服务
CMD ["nginx", "-g", "daemon off;"]

将文件构建成镜像并运行后，探针会按 interval 周期执行；超出 timeout 算一次失败，连续达到 retries 次才会变成 unhealthy。因此第一次打开页面看到 starting，不一定是配置错误。

2. 进入 Containers 视图定位目标容器

打开 Docker Desktop Dashboard，在左侧导航点击 Containers。这个视图会列出运行中和已停止的容器，也可能把 Compose 应用作为可展开的项目分组显示。

在列表上方的 Search 输入容器名或 Compose 项目名。若目标容器已经停止，先关闭 Only show running containers 过滤；如果是 Compose 项目，展开项目行再选择具体服务容器，而不是只看项目总行。

可以继续的可见状态是：搜索结果只剩目标容器，名称、镜像和端口信息与预期一致。不要把 Images 里的镜像行当成已经运行的容器；健康状态属于容器实例。

3. 打开详情查看 running 与健康状态

点击目标容器名称或行，进入容器详情。先看顶部的生命周期状态，再看同一页面中的健康状态区域、状态徽标或检查信息。不同 Docker Desktop 版本的布局和文案可能略有变化，但判断逻辑不变：running 说明主进程仍在运行，healthy 才表示最近一次健康检查成功，unhealthy 表示连续失败达到阈值。

如果页面一直停在 starting，先对照 start-period 和探针执行周期等待一个完整检查窗口；如果很快变成 unhealthy，不要只重启容器，继续查看下一步的输出。健康检查不会自动修复应用，也不会替代日志排查。

4. 在详情页定位 unhealthy 的原因

在容器详情中打开 Logs，先看应用是否已经监听探针访问的端口，再打开 Inspect 查看镜像、端口映射及容器配置。官方 Containers 视图还可能提供 Bind mounts、Debug、Files 和 Stats 等标签，但本题只需要 Logs 与 Inspect。

常见线索可以按下面顺序判断：

需要更细的状态时，可以在 Docker Desktop 的容器终端或外部命令行读取同一份 Engine 信息。下面的命令只是可选核对方式，不是本文界面操作的替代品：

# 只读取目标容器当前的健康状态
docker inspect --format='{{.State.Health.Status}}' demo-health

# 查看最近一次检查记录和探针输出
docker inspect --format='{{json .State.Health}}' demo-health

探针输出应保持简短；Docker 会保存检查命令写到标准输出或错误输出的部分内容，便于定位失败。不要把 docker inspect 显示的敏感环境变量、凭据或私有路径复制到工单和文章中。

5. 修复后重建容器再核对

如果确认是 Dockerfile 中探针命令、端口或启动等待时间不合适，修改配置后重新构建镜像并重新创建容器。已经创建的容器不会因为你只改了本地 Dockerfile 就自动换成新探针；Compose 项目也要按项目流程重新创建对应服务。

修复后的判断顺序仍然是：回到 Containers → 搜索新容器 → 打开详情 → 等待 starting 结束 → 确认 healthy。如果又变成 unhealthy，保留 Logs 和 Inspect 中的失败信息，优先修正实际探针命令，而不是盲目调大 retries。

为什么容器是 running，却没有 healthy？

running 是主进程的生命周期状态；只有镜像或创建参数声明了健康检查，Docker 才会计算健康状态。两者不是同一个字段。

starting 要等多久？

取决于 start-period、interval 和探针本身耗时。启动期失败不一定会计入最终重试次数，先按配置等待一个检查周期。

Docker Desktop 找不到健康信息怎么办？

先确认选的是容器而不是镜像或 Compose 项目，再检查镜像是否包含 HEALTHCHECK，或创建时是否传入了健康参数；之后在详情页的 Logs、Inspect 中核对。

记住这条操作路径即可：Containers 负责找对象，详情页负责看状态，Logs 与 Inspect 负责解释状态，修复后必须重新创建容器再观察。