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