Nginx通过被动监测与有限主动检查实现后端健康探测：开源版依赖nginx_upstream_check_module等第三方模块，Nginx Plus支持内置health_check指令；被动检查基于max_fails/fail_timeout在转发中异步标记故障节点。
Nginx 本身不主动“探测”后端服务器的健康状态，而是通过被动监测与有限的主动检查机制来判断后端是否可用。所谓“利用异步事件驱动优化后端服务器探测”，实际是指借助 Nginx 的异步非阻塞 I/O 模型，在 upstream 负载均衡场景中高效处理失败连接、超时、错误响应等信号，并结合 health_check（需 stream 或 http 模块支持）或第三方模块（如 nginx_upstream_check_module）实现轻量、低开销的健康检查。
基于内置 health_check 的主动探测（HTTP/Stream）
Nginx Plus（商业版）原生支持 health_check 指令，可在 upstream 块中配置周期性 HTTP 请求探测后端。该机制由事件循环统一调度，不阻塞工作进程：
- 使用
match块定义成功条件（如状态码 200 + 响应体含 "ok"） - 探测请求独立于客户端请求生命周期，由 master/worker 协同触发
- 默认每 5 秒发一次 HEAD 或 GET，可调
interval、fails、passes - 注意：仅限 Nginx Plus；开源版需自行编译第三方模块
开源版常用方案：nginx_upstream_check_module
这是一个广泛使用的补丁模块，为开源 Nginx 添加 TCP/HTTP 层主动健康检查能力，其核心正是复用 Nginx 的 event loop：
- 检查任务注册到 epoll/kqueue 事件队列，超时或就绪时回调处理，无额外线程
- 支持
check interval=3 rise=2 fall=3 timeout=1 type=http等精细控制 - 需配合
check_http_send和check_http_expect_alive定义探测行为 - 状态页可通过
location /status暴露（如check_status），实时查看各 server 的 up/down 状态
被动健康检查：更轻量、更贴近真实请求流
无需额外探测请求，Nginx 在转发过程中自然收集故障信号，异步标记节点不可用：
-
max_fails=3 fail_timeout=30s：连续 3 次 connect timeout / read timeout / 5xx 响应即摘除节点 30 秒 - 所有失败判定都发生在事件回调中（如 recv() 返回 -1 且 errno=ECONNREFUSED）
- 恢复机制也是异步的：fail_timeout 到期后，下一次请求会尝试连接，成功则自动恢复
- 适合对探测开销敏感或后端本身禁止闲时探测的场景（如数据库代理、旧系统）
关键调优建议
真正发挥异步优势，需避免反模式：
- 不要将
health_check的interval设得过短（如 100ms），易引发探测风暴，反而增加后端压力 - 慎用
proxy_next_upstream error timeout invalid_header http_500过度重试，可能掩盖真实问题并延长用户等待 - 确保
worker_processes auto且worker_connections足够，否则事件队列积压会导致探测延迟 - 对于长连接后端（如 gRPC），优先用
keepalive+ 被动检查，减少主动探测必要性
