Nginx中故障探测频率分主动与被动两种：主动检查由interval参数直接控制（如interval=2s），需Nginx Plus或nginx_upstream_check_module；被动检查依赖max_fails/fail_timeout滑动窗口（如30秒内失败3次），靠真实请求触发。
在 Nginx 中，负载均衡器对后端服务器故障的探测频率主要由 health_check（在 location 块中）或上游（upstream）配置中的健康检查参数控制。但需注意：Nginx 开源版本身不支持主动健康检查（active health check），该功能仅在 Nginx Plus（商业版） 中原生提供。开源版通常依赖被动检查（如失败请求触发标记为不可用），或借助第三方模块（如 nginx_upstream_check_module）实现主动探测。
以下分两种情况说明如何定义故障探测响应频率：
主动健康检查（Nginx Plus 或带第三方模块）
当使用支持主动健康检查的环境时，可通过 match、interval、fails、passes 等指令精细控制探测行为：
-
interval=1s：设置健康检查请求发送间隔（如每秒探测一次） -
fails=3：连续失败多少次后将服务器标记为不可用 -
passes=2：连续成功多少次后恢复服务器为可用状态 -
rise=2/fall=3（部分模块语法）：等效于passes/fails
示例（Nginx Plus 风格）：
upstream backend {
zone backend 64k;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
# 主动健康检查
health_check interval=2s fails=2 passes=3 match=status_ok;
}
match status_ok {
status 200;
body ~ "OK";
}⚠️ 注意：
interval是核心控制项，直接决定探测频率；值过小会增加后端压力，过大则故障发现延迟高。建议生产环境设为2s–5s，避免低于1s。
被动健康检查（Nginx 开源版默认方式）
开源版通过 proxy_next_upstream 和 max_fails/fail_timeout 实现故障感知：
-
max_fails=3：在fail_timeout时间窗口内，最多允许 3 次失败请求 -
fail_timeout=30s：失败计数器的重置周期（即“30 秒内失败 3 次就摘除”） -
proxy_next_upstream error timeout http_500 http_502：定义哪些响应触发重试与故障判定
示例：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}
server {
location / {
proxy_pass http://backend;
proxy_next_upstream error timeout http_500 http_502;
proxy_next_upstream_tries 3;
}
}此时，“探测频率”实为用户请求到达的频率 —— 只有真实请求失败才会触发检查逻辑。若流量稀疏，故障识别可能严重滞后。
如何选择与优化
- 若需精确、低延迟故障发现，优先采用 Nginx Plus 或编译启用
nginx_upstream_check_module - 开源环境下，可配合外部工具（如 Consul、Prometheus + Alertmanager + 自动 reload 脚本）实现准主动检查
- 无论哪种方式，
fail_timeout应显著大于interval（主动）或单次请求超时（被动），避免误判 - 所有健康检查都应搭配
backup服务器或降级策略，保障服务连续性
不复杂但容易忽略：健康检查路径（如 /healthz）必须轻量、稳定、不带业务逻辑，否则自身成为瓶颈或误报源。
