核心是组合被动与主动健康检查：被动用max_fails/fail_timeout摘除故障节点，主动用/health探针验证业务就绪；辅以收紧超时参数、least_conn算法及后端健康接口联动。
直接配置健康检查机制，是解决后端服务“假死”（即进程未退出、端口仍监听，但实际无法正常响应请求）问题的核心手段。Nginx 本身不主动探测应用层可用性，若仅靠基础轮询或权重分发，会持续将请求打到已卡住的后端，导致用户长时间等待甚至超时。
启用主动健康检查（需 Nginx Plus 或开源版配合模块）
标准开源 Nginx（v1.23+）已原生支持 被动健康检查，但要实现真正可靠的“假死”识别，推荐组合使用被动 + 主动策略：
-
被动检查：通过
max_fails和fail_timeout参数，在请求失败（如超时、500/502/503/504）达到阈值后临时摘除节点
示例：server 192.168.1.101:8080 max_fails=3 fail_timeout=30s; -
主动检查（推荐）：使用
nginx-plus的health_check指令，或开源版搭配nginx-upstream-check-module编译安装，定期向后端发送 HTTP 探针（如/health），依据返回状态码和响应内容判断真实可用性 - 探针路径应由后端主动暴露，且必须反映业务就绪状态（例如检查数据库连接、线程池是否阻塞），不能只返回 200 的静态页
合理设置超时与重试机制
避免因单个后端响应迟滞拖垮整体体验，必须收紧代理层超时参数：
-
proxy_connect_timeout 5s;—— 建立连接上限时间 -
proxy_send_timeout 10s;—— 发送请求体的超时（尤其大文件上传） -
proxy_read_timeout 10s;—— 等待后端响应头的超时（关键！防止“假死”节点长期占着连接） -
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;—— 明确哪些情况触发重试 -
proxy_next_upstream_tries 3;—— 最多重试次数（避免无限循环）
选用更适应故障场景的负载算法
轮询在节点性能突变或部分卡顿时容易失衡，可按需切换：
- least_conn：优先转发给当前活跃连接数最少的后端，天然规避已堆积大量慢请求的“假死”节点
- ip_hash：适用于需会话保持、且允许单点故障影响部分用户的场景；但注意它不解决假死，仅限制影响范围
- 避免单独依赖
weight：权重是静态配置，无法响应运行时状态变化
配合后端提供真实健康接口并日志联动
光靠 Nginx 配置不够，需前后端协同：
- 后端服务暴露
/actuator/health（Spring Boot）或自定义/health?full接口，返回包含 DB、Cache、线程池等子项状态的 JSON - Nginx 主动检查该接口，失败则自动剔除；同时将检查结果写入 access_log，便于 ELK 或 Prometheus 抓取分析
- 配置 log_format 记录 upstream_addr 和 upstream_response_time，快速定位是哪个后端响应异常或延迟突增
