原生Nginx无主动健康检查，需通过nginx_upstream_check_module模块实现：先按版本匹配patch并正确打补丁，再configure时用--add-module指定路径，upstream中check指令须单行紧贴server后、HTTP类型必配send/expect_alive，status页面需在http块定义并限制访问。
原生 Nginx 不带主动健康检查能力，max_fails + fail_timeout 只是被动容错，不是真正的健康检查。要实现定期探活（比如每 3 秒发一次 HEAD /health），必须用第三方模块 —— 目前最稳定、适配性最好的仍是 nginx_upstream_check_module，需重新编译 Nginx 加载。
确认当前 Nginx 版本并选对 patch 文件
执行 nginx -v 查看版本，再对应下载 patch：
- Nginx 1.20.x → 用
check_1.20.1+.patch - Nginx 1.22.x → 用
check_1.22.0+.patch - Nginx 1.26.x（如 1.26.3）→ 用
check_1.20.1+.patch或 v0.4.0 提供的兼容 patch（截至 2026 年 6 月，v0.4.0 已明确支持 1.26.x）
patch 必须在 Nginx 源码根目录下运行：patch -p1 < /path/to/check_*.patch。路径错或 -p 参数不对，编译时会报 undefined reference to 'ngx_http_upstream_check_init' 类错误。
编译时必须加 --add-module 参数
configure 阶段漏掉模块路径，编译成功但运行时 check 指令会报 unknown directive "check"：
- 确保
--add-module=../nginx_upstream_check_module-master/（路径必须真实存在且为绝对路径或相对于当前 configure 所在目录的相对路径） - 建议同时启用
--with-http_stub_status_module，后续调试可用 - 别忘了基础依赖：
yum install -y gcc pcre-devel openssl-devel zlib-devel patch，缺patch会导致打补丁失败
upstream 块里 check 指令写法有硬约束
check 必须紧贴 server 行之后、同一 upstream 块内，且只能出现一次：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 错误写法：
check interval=3000; check rise=2;（拆成多行且重复） - 正确写法：
check interval=3000 rise=2 fall=3 timeout=1000 type=http;（所有参数在同一行，或用\换行） - HTTP 类型必须配
check_http_send和check_http_expect_alive，否则请求发不出去；Host头要和后端实际域名一致，否则可能被拒绝
示例：
upstream backend {
server 10.0.1.10:8080;
server 10.0.1.11:8080;
check interval=3000 rise=2 fall=3 timeout=1000 type=http;
check_http_send "HEAD /health HTTP/1.1\r\nHost: api.example.com\r\nConnection: close\r\n\r\n";
check_http_expect_alive http_2xx;
}
暴露 check_status 页面并限制访问
没配 location /status { check_status; }，就看不到节点状态；不加 allow/deny，等于把后端存活情况直接暴露在公网：
- 必须在
http块里定义 location，不能放在server块内（否则报unknown directive "check_status"） - 生产环境至少限制 IP：
allow 127.0.0.1; allow 10.0.0.0/8; deny all; - 验证是否生效：
curl http://localhost/status应返回 HTML 表格，含UP/DOWN、Rise/Fall列
如果返回空白或 404，先确认 Nginx 是否重载（nginx -s reload），再检查 error.log 里有没有 check_status handler is not found —— 这说明模块根本没加载成功。
真正麻烦的不是编译或配置，而是 patch 和 configure 的路径一致性、check 指令位置、以及 status 页面的权限控制 —— 这三处出错，整个心跳检测就静默失效，你却看不出任何报错。
