nginx 健康检查必须基于 spring boot actuator 的 /actuator/health 接口并解析响应体中的 status 字段（严格匹配 "up"），而非仅依赖 http 状态码；需通过 upstream_check_module 配置主动探测、关闭鉴权、暴露统一健康视图，并联动依赖状态与日志分析。
Java 应用部署在 Nginx 负载均衡后，光靠端口通、进程在跑远远不够。真正要让 Nginx “看懂” Java 服务是否健康，必须把 Spring Boot 的 /actuator/health 这类语义化状态页变成 Nginx 健康检查的唯一依据——不是只看连得上，而是看它“说自己好不好”。
对接 Java 应用的标准健康接口
Spring Boot 项目默认开启 Actuator，/actuator/health 返回 JSON，如 {"status":"UP","components":{"db":{"status":"UP"}}}。Nginx 需主动调用这个路径，并解析响应内容，而非仅判断 HTTP 状态码。
- 避免只依赖
http_2xx：有些应用在数据库挂掉时仍返回 200 +{"status":"DOWN"}，必须校验 body 内容 - 若用 OpenResty，可用 Lua 脚本提取
status字段，严格匹配"UP"才算健康 - 生产环境建议启用
show-details=when_authorized并配好权限，确保 Nginx 探测请求能拿到完整结构
用 upstream_check_module 主动探测并精准判定
Nginx 开源版不支持原生 health_check，但通过编译 nginx_upstream_check_module（常见于 OpenResty 或 Tengine）可实现稳定主动检查：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 在
upstream块中配置：check interval=5 rise=2 fall=3 timeout=2 type=http;check_http_send "GET /actuator/health HTTP/1.1\r\nHost: localhost\r\n\r\n";check_http_expect_alive http_2xx; -
rise=2防止刚启动就误判为健康；fall=3避免单次抖动触发剔除；timeout=2严控探测耗时，不拖慢主请求 - 务必关闭后端对健康接口的鉴权或放行 Nginx 源 IP，否则探测永远失败
暴露可读、可集成的集群健康视图
运维和监控系统需要统一入口查看全局状态，不能靠翻日志或手动 curl。
- 配一个专用
location /status，启用check_status指令，返回 HTML 或 JSON 格式，含每个节点 IP、端口、当前状态（up/down）、失败次数、最后检查时间 - 该页面可被 Prometheus 定期抓取，配合 Alertmanager 实现“节点 down 超过 30 秒”自动告警
- 若已用 VTS（vhost_traffic_status）模块，
/status还能同时展示 QPS、延迟、错误率等维度，补全健康画像
联动日志与下游依赖验证
Java 应用的健康不只是自身 Web 层，还包括数据库、Redis、消息队列等关键依赖。
- 确保
/actuator/health启用了db、redis等组件健康检查，且设置show-details级别允许 Nginx 获取嵌套状态 - 在 Nginx access_log 中加入
$upstream_addr $upstream_status $upstream_response_time，便于快速定位是哪个节点开始返回 503 或响应超时 - 当某节点频繁出现
upstream_status=503但/actuator/health显示 UP，说明健康接口未真实反映业务能力，需推动 Java 团队优化探测逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
