健康检查频繁报红主因是探针配置与服务启动节奏不匹配，需重点排查探针命令可靠性、参数合理性（timeout/start-period/interval协同）、容器环境干扰（资源、依赖、网络）。
健康检查频繁报红，通常不是服务真挂了，而是探针配置和实际运行节奏不匹配。重点查三块：探针命令本身是否可靠、参数设置是否合理、容器环境是否存在干扰。
先确认探针命令在容器内能否稳定执行
很多报红源于命令在容器内部根本跑不通——比如绑定到 127.0.0.1 而非 0.0.0.0，或健康端点路径错误、权限不足、缺少 curl 工具等。
- 进容器手动执行一次健康检查命令（如
curl -f http://localhost:8080/health），观察是否返回 200、耗时多少、有无超时或连接拒绝 - 检查应用是否监听在
0.0.0.0（而非仅127.0.0.1），否则容器内网络命名空间下可能无法访问 - 确认镜像中已安装必要工具（如 curl、netcat），或改用更轻量的方式（如
nc -z localhost 8080）
重点核对 timeout、start-period 和 interval 的配合关系
这三个参数协同决定探针是否“误杀”。常见问题是 timeout 太短 + start-period 没设 + interval 太密，导致服务还没启动完就被反复判定失败。
-
--timeout 必须大于健康端点真实响应时间（建议留 2–3 倍余量，例如实测 2s 就设
--timeout=6s） -
--start-period 对 Java/Spring Boot 等慢启动服务至关重要，应覆盖完整初始化时间（常见设为
60s或120s） -
--interval 不宜过短（如
5s），避免密集探测加重负载；生产环境推荐15–30s
用 inspect 查看真实失败记录和退出码
docker inspect 是最直接的诊断入口，能暴露每次检查的时间、结果和原始日志，比看状态更准。
- 运行
docker inspect --format='{{json .State.Health}}' - 关注
Log数组里的每条记录：ExitCode为 1 表示失败，Output可能含 curl 超时提示或 connection refused - 若连续多条失败且
Start时间非常接近，说明start-period未生效或设得太小
排除环境干扰：资源、依赖与网络隔离
即使命令和参数都对，宿主机资源紧张或依赖未就绪也会传导为探针失败。
- 检查容器是否被限 CPU/memory，导致健康端点响应延迟（
docker stats观察实时使用率） - 确认依赖服务（如数据库）已就绪——健康端点若校验 DB 连接，而 DB 容器还在 starting，必然报红
- 避免在探针中调用外部地址（如第三方 API），应只检查本地进程状态或关键内部依赖
