Nginx 原生不支持 upstream 健康探测，需通过第三方模块 nginx_upstream_check_module 实现主动检测与自动剔除；该模块以周期性 HTTP/TCP 探测标记节点状态，配合 round_robin 等负载策略完成平滑切换，并提供 /status 页面实时监控。
在 Nginx 中原生不支持对 upstream 后端健康状态的主动探测与自动剔除，需借助第三方模块 nginx_upstream_check_module（常称 Upstream-Check）实现后端节点的自动故障检测与平滑下线。该模块通过周期性发送探测请求（如 HTTP HEAD/GET 或 TCP 连接），根据响应状态动态标记节点为 up 或 down，配合 Nginx 内置的负载均衡策略，即可实现无感知的流量切换。
编译安装 Upstream-Check 模块
该模块未被官方集成，需在编译 Nginx 时手动添加：
- 确认当前 Nginx 版本（如 1.24.0），下载对应版本的 nginx_upstream_check_module 补丁或 fork 版本（推荐使用
yaoweibin维护的稳定分支） - 解压 Nginx 源码，打补丁：
patch -p1 - 重新 configure 并启用模块：
--add-module=/path/to/nginx_upstream_check_module，再执行make && make install - 验证是否加载成功：
nginx -V 2>&1 | grep -o 'check'应输出check
配置 upstream 健康检查参数
在 http 或 stream 块中定义 upstream，并添加 check 指令：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
check interval=3 rise=2 fall=5 timeout=1 type=http;
check_http_send "HEAD /health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
关键参数说明：
-
interval=3：每 3 秒探测一次 -
rise=2：连续 2 次成功则恢复节点为可用 -
fall=5：连续 5 次失败则标记为不可用（自动从负载池中剔除） -
type=http：使用 HTTP 探测（也支持tcp、ssl_hello等） -
check_http_send：自定义探测请求（建议用轻量 HEAD） -
check_http_expect_alive：指定哪些 HTTP 状态码视为“存活”
配合 Nginx 负载策略实现平滑切换
Upstream-Check 本身只负责状态标记，真正路由决策仍由 Nginx 的 upstream 机制完成。需注意以下几点以保障平滑性：
- 确保 upstream 中各节点未显式设置
down或backup，否则 check 状态不会覆盖手动标记 - 推荐使用默认的
round_robin或least_conn策略，它们天然支持动态节点列表变化 - 若使用
ip_hash，需注意：当某节点 down 后，原绑定该节点的客户端请求会自动 fallback 到其他可用节点，但 hash key 不变，后续恢复时可能重新分配——这是预期行为，无需额外处理 - 可搭配
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;增强容错（尤其在 check 探测间隙内发生瞬时故障时）
查看健康状态与调试技巧
模块提供内置状态页，便于实时监控：
- 在 server 块中添加 location：
location /status { check_status; } - 访问
http://your-nginx-ip/status可看到表格形式的状态页，含 IP、Port、Rise/Fall、Status、Check Type 等列 - Status 显示
up/down/no status；若长期显示no status，常见原因是探测路径返回非 2xx/3xx、超时、或服务器未监听对应端口 - 开启 Nginx debug 日志（
error_log /var/log/nginx/error.log debug;）可捕获 check 模块的详细探测日志，用于排查连接拒绝、SSL 握手失败等问题
