nginx原生仅支持被动健康检查，通过proxy_next_upstream配合max_fails和fail_timeout实现故障节点自动摘除与恢复，但无主动心跳探测能力，依赖真实请求反馈，存在发现延迟和业务就绪态盲区。
Nginx 原生不提供主动心跳探测，但通过 upstream 和 proxy_pass 的配合，就能实现简单可靠的基础健康检查——核心是让 Nginx 在真实请求中“感知异常”，并自动规避故障节点。
被动健康检查：靠请求失败触发摘除
这是最常用、无需额外模块的方式，适合大多数中小规模生产环境。它不发独立探针，而是利用每次代理请求的反馈来动态标记后端状态。
-
max_fails控制连续失败次数阈值（默认为 1），超过即标记该节点为 down -
fail_timeout定义被标记为不可用后的屏蔽时长（默认 10 秒），超时后会尝试恢复 - 必须配合
proxy_next_upstream显式启用失败重试逻辑，否则即使后端返回 502，Nginx 也不会切换
典型配置示例：
upstream app_servers {
server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
server 10.0.1.12:8080 backup;
}
server {
location / {
proxy_pass http://app_servers;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
}
}
关键细节说明：
-
proxy_next_upstream中不要包含http_404或invalid_header，除非业务确认这些一定代表后端异常 -
proxy_next_upstream_tries限制最多重试次数，避免反复打到同一组故障节点 -
backup节点仅在所有主节点都不可用时才启用，适合做灾备兜底
这个机制的局限性要清楚：
- 没有请求就不会检查，新上线的服务若未及时收到流量，Nginx 不会主动探测
- 故障发现依赖真实请求超时或错误响应，存在延迟（比如
proxy_read_timeout设为 60 秒，就得等满 60 秒才知道失败） - 无法区分“进程存活但业务卡死”和“彻底宕机”，对就绪态（ready）无感知
如果需要更及时、更精准的状态判断，就得引入主动探测模块，比如 nginx_upstream_check_module，但它需要编译安装，不属于开箱即用范畴。
