nginx集群需通过主动健康检查（如nginx_upstream_check_module）探测后端/health接口并语义化判断状态，结合rise/fall阈值、响应码匹配及日志告警闭环，才能真正感知应用健康。
要让 Nginx 集群在负载均衡的同时，真正“感知”后端应用是否健康，关键不是只转发请求，而是让 Nginx 主动探查每个后端的 /health 或类似状态页，并据此动态剔除异常节点。这需要结合主动健康检查 + 状态页语义判断，而非仅靠连接通断。
启用主动健康检查并指向真实状态接口
Nginx 开源版不支持原生 health_check 指令（该指令属 Nginx Plus），但可通过 max_fails、fail_timeout 配合自定义 location 和 proxy_pass 实现等效效果；更推荐使用开源生态成熟的方案——nginx_upstream_check_module（需编译安装）或直接升级到 Nginx Plus。以下以开源增强方式为例：
- 确保已编译并启用
upstream_check_module（常见于 OpenResty 或部分发行版打包版本） - 在
upstream块中添加检查配置，明确指定探测路径与成功条件：
upstream app_backend {
server 10.0.1.10:8080;
server 10.0.1.11:8080;
check interval=3 rise=2 fall=3 timeout=1 type=http;
check_http_send "GET /health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
-
rise=2表示连续 2 次成功才标记为“恢复健康” -
fall=3表示连续 3 次失败才标记为“宕机” -
check_http_expect_alive可精确匹配返回码，避免将 503、404 等误判为健康
暴露可读的集群健康状态页
仅内部检查不够，运维和告警系统需要统一入口查看全局状态。建议配置一个专用 location，聚合展示各后端实时健康状况：
- 启用
ngx_http_upstream_jdomain_module或使用第三方模块如nginx-module-vts（VTS - Virtual Host Traffic Status） - 或轻量级做法：用 Lua 脚本（OpenResty）调用 upstream check 的共享内存数据，渲染 HTML 表格
- 最简实践（无需额外模块）：复用 Nginx 自带 stub_status，并配合自定义日志格式记录上游响应码
location /status/upstream {
vhost_traffic_status_display;
vhost_traffic_status_display_format html;
allow 127.0.0.1;
allow 10.0.0.0/8;
deny all;
}
访问 http://your-nginx/status/upstream 即可看到每个 server 的 active、max_fails、fails、down 状态及最近响应时间。
联动日志与告警，让状态“可行动”
监控页面是看的，告警才是用的。把健康状态转化为可观测信号：
- 在
error.log中捕获 upstream 失败事件：grep "upstream timed out|no live upstreams" /var/log/nginx/error.log - 配置 access_log 记录 upstream 响应码：
log_format upstream '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" "$upstream_response_time" "$upstream_http_x_backend_status"' - 用 Filebeat + Prometheus + Alertmanager 构建闭环：采集日志中的
$upstream_http_x_backend_status（后端自定义健康头）或解析$upstream_response_time异常毛刺，触发邮件/企微告警
验证状态页逻辑是否被真实执行
很多配置看似正确，但后端状态页返回 200 并不等于服务可用（比如 DB 连接池耗尽时，/health 仍可能返回 200）。务必做三件事：
- 手动 curl 后端
/health，确认它返回的是结构化 JSON 且含"status":"UP"字段（而非固定 200） - 模拟故障：临时 kill 后端进程或阻断其 DB 连接，观察 Nginx 是否在
fall次数后将其标记为down（查nginx -T | grep down或 VTS 页面） - 检查 Nginx error.log 是否出现类似
upstream check failed...http_503的记录，确认检查逻辑已生效
