nginx原生仅支持被动健康检查，需编译nginx_upstream_check_module实现主动探测；平滑升级依赖usr2/winch信号机制，替换二进制后新旧进程共存再优雅退出。
Nginx 本身不提供主动式后端健康检查能力，但通过合理组合原生模块与第三方扩展，配合平滑升级机制，可实现后端服务故障自动规避 + 前端 Nginx 版本无中断更新。关键在于区分两个独立但协同的“平滑”：后端节点的健康探测平滑切换 和 Nginx 自身二进制的平滑升级。
原生方式实现后端健康检查（被动式）
无需额外编译模块，利用 ngx_http_upstream_module 和 ngx_http_proxy_module 即可启用基础容错：
-
配置失败转移逻辑：在
upstream块中设置max_fails和fail_timeout，例如server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;，表示连续 3 次失败后，该节点在 30 秒内不再被调度。 -
定义重试条件：在
location或server块中使用proxy_next_upstream，如proxy_next_upstream error timeout http_502 http_503;，当遇到连接错误、超时或指定 HTTP 状态码时，自动将请求转发给下一个 upstream 节点。 - 注意局限性：这种机制是“被动”的——只有真实请求触发失败才会标记节点异常；若节点刚宕机而暂无流量，Nginx 不会主动探活，可能造成短暂请求失败。
增强健康检查（主动式，推荐生产环境）
使用 nginx_upstream_check_module（Tengine 内置或独立编译）实现定时心跳检测：
-
启用主动探测：在
upstream块中添加check指令，例如：upstream backend {<br> server 10.0.1.10:8080;<br> server 10.0.1.11:8080;<br> check interval=3 rise=2 fall=5 timeout=1 default_down=false;<br> check_http_send "HEAD /health HTTP/1.0\r\n\r\n";<br> check_http_expect_alive http_2xx http_3xx;<br> } - 效果说明：每 3 秒向每个后端发送一次 HEAD 请求，连续 2 次成功则恢复上线，连续 5 次失败则标记为 down；超时 1 秒即判为不可用。
-
配套页面查看状态：需启用
check_status指令并配置一个 location，便于运维实时监控各节点健康状态。
Nginx 自身平滑升级流程
升级过程不影响正在处理的连接，核心依赖信号机制而非重启：
-
确认旧版本参数：运行
nginx -V，完整记录configure arguments，新版本编译时必须完全复用（含路径、用户、模块等），否则可能导致功能缺失或启动失败。 -
编译新二进制（不安装）：解压新源码，进入目录执行
./configure [原参数]→make（不要make install），生成的新objs/nginx即为目标文件。 -
替换并热启新进程：备份旧
nginx文件，复制新二进制覆盖；执行kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid)，此时新旧 master 及 worker 进程共存。 -
优雅退出旧进程：确认新进程运行正常后，执行
kill -WINCH $(cat /usr/local/nginx/logs/nginx.pid)，旧 worker 逐步关闭；最后可发kill -QUIT终止旧 master。
二者协同保障业务连续性
健康检查确保后端出问题时请求自动绕行，平滑升级确保 Nginx 自身更新时零丢包、零连接中断。两者叠加，才能真正达成“后端可维护、前端可演进”的高可用目标。实际部署中建议：先验证健康检查逻辑生效（如手动停掉一个后端观察流量是否自动切走），再执行 Nginx 升级，避免多点变更同时引入风险。
