Nginx集群健康检查需区分被动响应与主动探测：proxy_next_upstream依赖请求失败触发摘除，适合低敏场景；nginx_upstream_check_module支持定时HTTP/TCP探活，需配置check指令、健康端点及状态页监控闭环。
Nginx 集群的健康检查不能只看“能不能连上”，得区分被动响应和主动探测两种逻辑，否则容易漏判、误判或延迟发现故障。
用 proxy_next_upstream 实现基础被动检查
这是开源 Nginx 原生支持的方式，无需编译模块，适合流量稳定、对故障发现延迟容忍度较高的场景。它依赖真实请求失败来触发节点摘除。
- 在 upstream 中为每个后端明确配置 max_fails 和 fail_timeout：
— max_fails=3 表示连续 3 次失败才标记为不可用
— fail_timeout=30s 表示该节点将被屏蔽 30 秒，之后自动试探恢复 - 在 location 中启用 proxy_next_upstream，定义哪些情况算“失败”并重试：
— error timeout http_500 http_502 http_503 http_504 是常用组合
— 避免加入 http_404 或 invalid_header，除非业务确认这些一定代表后端异常 - 注意：这个机制不发心跳，没请求就不会检查；节点刚启动但应用未就绪时，流量仍会打过去
用 nginx_upstream_check_module 实现主动探测
要真正实现“定时探活”，必须使用这个开源增强模块（常见于 OpenResty 或手动编译版本），它支持 HTTP/TCP 级别的周期性检查。
- 编译安装模块后，在 upstream 块中添加 check 指令：
— check interval=3 rise=2 fall=5 timeout=1 type=http
— check_http_send "GET /health HTTP/1.0\r\n\r\n" 发送轻量请求
— check_http_expect_alive http_2xx http_3xx 只把 2xx/3xx 当健康，排除 503 等临时错误 - 关键细节：
— rise=2 防止偶发抖动导致误恢复，fall=5 避免单次丢包就下线
— 探测路径建议用专用接口（如 /actuator/health 或 /ready），不走业务链路
— 必须配 default_down=true，防止 Nginx 启动时把未就绪节点当健康节点用
适配防火墙与网络策略
很多“假死”不是后端真挂了，而是健康检查被中间设备拦截。
- 先定位拦截层：是 iptables 丢包？安全组限速？还是 WAF 拦截了 /health 路径？
- 若无法改防火墙，可调整探测行为：
— 改用 type=tcp 检查端口连通性，绕过路径和头校验
— 把 interval 放宽到 10–30 秒，降低探针频率
— 去掉 check_http_expect_alive http_503，避免 GC 导致的短暂 503 被误判 - 后端应暴露独立健康端点，并确保该路径在防火墙白名单中显式放行
暴露状态页并接入监控闭环
光有检查还不够，得让运维能看见、能告警、能联动。
- 单独配置 location /upstream_status，并启用 healthcheck_status 指令，暴露实时节点状态
- 将该状态页接入 Prometheus + Grafana 或 Zabbix，设置 fail_count 上升、status 为 down 等阈值告警
- 建议搭配 systemd 服务健康检查（如 ExecStartPost 执行 curl -f http://localhost/upstream_status），实现配置级自愈保障
