nginx_upstream_check_module 是非官方健康检查模块，需源码编译并匹配Nginx版本，配置check指令于upstream块内，通过interval/rise/fall等参数控制探测与剔除逻辑，并手动配置/status页面。
nginx_upstream_check_module 不是官方模块，得自己编译
官方 Nginx 的 upstream 块本身不带健康检查功能，proxy_next_upstream 只能被动重试，不会主动标记节点为不可用。真要自动剔除挂掉的后端，必须用第三方模块 nginx_upstream_check_module，但它不在源码里，得在编译时显式添加。
常见错误是直接装系统包（如 apt install nginx）然后照网上配置写 check 指令——结果 Nginx 启动报错：unknown directive "check"。这是因为发行版预编译的二进制没集成该模块。
- 必须从源码编译，且 configure 时加
--add-module=/path/to/nginx_upstream_check_module - 注意匹配 Nginx 版本：模块有分支适配不同 Nginx 大版本（如 1.16–1.20 用 master 分支，1.21+ 推荐用
dev分支） - OpenResty 用户可跳过这步——它默认已内置该模块（对应指令为
check）
check 指令参数决定探测行为和剔除逻辑
check 必须写在 upstream 块内，不是 server 块里。它的参数直接控制“怎么探”“探几次失败就踢”“多久再试”，稍配错就会导致节点被误踢或长期不恢复。
典型配置示例：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
check interval=3 rise=2 fall=5 timeout=1 max_fails=3 fall=5;
}
-
interval=3：每 3 秒发一次探测请求 -
rise=2：连续 2 次成功，就把节点从“失败”状态恢复为“可用” -
fall=5：连续 5 次失败，才标记该节点为 down 并剔除流量 -
max_fails=3和fail=5是两套机制：前者是传统proxy_next_upstream的计数，后者才是check模块的独立判断——建议只用fall/rise，避免混淆 -
timeout=1很关键：探测超时设太长（比如 5 秒），节点假死时会卡住整个健康检查队列
探测路径和返回码必须和后端真实健康接口对齐
模块默认用 HTTP GET 请求 /，期望返回 2xx 或 3xx。但多数服务的根路径不暴露健康状态，直接用会导致所有节点被误判为 down。
- 必须用
check_http_send自定义请求头和路径，例如：check_http_send "GET /health HTTP/1.0\r\n\r\n"; - 用
check_http_expect_alive明确指定哪些状态码算“活”，例如：check_http_expect_alive http_2xx http_3xx;（注意不能写成200，必须用模块定义的宏） - 后端
/health接口务必轻量：不能查 DB、不能依赖其他服务，否则探测本身会成为瓶颈或误报源 - 如果后端用非标准端口（如 8081）提供健康检查，
server行得写成server 192.168.1.10:8081，且check不支持为探测单独指定端口
状态页需手动配置 location，且路径权限要放开
模块提供 /status 页面看各节点实时状态，但这个 location 不是自动注册的，得自己加，否则访问 404。
- 在
server块里加：location /status { check_status; allow 127.0.0.1; allow 10.0.0.0/8; deny all; } -
check_status指令无参数，但必须单独成行；位置必须在location内，不能放在upstream或http块里 - 如果不配
allow，默认只允许本地访问；线上环境常漏加，导致运维没法远程看状态 - 页面返回的是纯文本，没有 JSON API；想对接监控需自行解析或改用 OpenResty 的
lua-resty-healthcheck库
真正难的不是加几行配置，而是让探测节奏、超时、恢复条件跟后端故障恢复时间窗匹配——比如后端重启要 8 秒，但你设了 fall=3 + interval=2，等于 6 秒就踢了，还没等它起来就先断流。这种细节不压测根本发现不了。
