Docker 容器显示 Up (unhealthy) 时，先用 docker inspect 查看健康探针的命令、退出码和输出。容器主进程仍在运行，但探针已连续失败。确认失败来自探针命令、服务监听还是启动时序，再调整配置。

适用环境

示例面向 Linux 上的 Docker Engine 25.0 及以上版本，要求能访问目标 Docker daemon，且容器已经配置健康检查。本文根据 Docker 官方文档整理，未在目标环境实测。下文的 web 是示例容器名。

查看生效配置和失败记录

docker context show
docker inspect --type container --format '{{json .Config.Healthcheck}}' web
docker inspect --type container --format '{{json .State.Health}}' web

先确认当前连接的 Docker context，再对照 Config.Healthcheck 中的 Test、Timeout 和 Retries，以及 State.Health 中的 Status、FailingStreak 和近期 Log。检查每条日志的时间、ExitCode 和 Output。探针返回 0 表示成功，1 表示失败，2 保留。探针输出可能被截断，必要时与同一时间段的应用日志对照。Docker HEALTHCHECK 官方参考。

在容器内复现同一请求

如果实际探针调用 curl 请求本容器的 8080 端口，且镜像内有 curl，可按实际探针参数重放一次。以下路径和参数只是示例。

docker exec web curl -fsS http://127.0.0.1:8080/health
docker logs --since 10m web
  • 找不到 curl 时，核对镜像是否包含探针使用的程序。
  • 连接被拒绝时，检查应用在容器内监听的地址和端口。宿主机映射端口可能与容器内端口不同。
  • 返回 HTTP 错误时，核对路径、认证要求与依赖状态。手工复现应尽量沿用探针的用户、参数和工作目录。

Docker exec 官方参考。

修复后验证健康状态

如果日志显示探针在应用初始化期间失败，先量出正常启动耗时，再评估 start period。初始化期内一旦探针成功，后续连续失败就会纳入计数。如果探针配置来自 Compose，改动后先核对解析结果，再按部署流程应用配置。用 docker compose config 核对合并后的配置。

在目标容器上重新检查 State.Health，确认状态回到 healthy，并观察后续数轮探针。最后从业务客户端验证实际入口，因为容器内健康端点只覆盖探针检查的范围。Docker 容器健康检查文档。