Nginx健康检查诊断需先区分机制：主动检查（需nginx_upstream_check_module或nginx-plus的health_check）、被动检查（依赖max_fails/fail_timeout）及手动down标记；再通过/status接口或error日志提取实时节点状态，定位down因探针失败、状态累积或配置未重载。
在 Nginx（特别是使用 nginx-plus 或开源版配合自定义逻辑）做上游集群负载时，健康检查异常常导致请求失败、502/503、流量倾斜。一键诊断脚本的核心目标是：快速确认哪些 upstream 节点被标记为 unhealthy，并定位原因（如主动探针失败、被动状态累积、手动 down 掉等）。
确认 Nginx 是否启用健康检查及类型
先区分你用的是哪种健康检查机制：
-
主动健康检查（recommended）：需在
upstream块中显式配置health_check（nginx-plus）或使用nginx_upstream_check_module（开源第三方模块） -
被动健康检查（默认内置）：依赖
max_fails+fail_timeout，无需额外模块，但诊断信息少 -
手动标记：通过
upstream_confAPI 或配置文件中写死down，容易遗漏
检查配置是否存在类似以下片段：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
# nginx-plus 才支持：
# health_check interval=5 fails=2 passes=2 uri=/health;
}提取实时节点状态（关键一步）
诊断脚本必须能读取当前生效的节点状态。不同方式对应不同采集方法：
-
nginx-plus 用户：直接调用
/statusAPI（需开启status_zone和stub_status）：curl -s "http://localhost/status?format=json" | jq '.upstreams.backend.servers' -
开源 Nginx + upstream_check_module：访问自定义检查页面（如
/status或/status/format/json），返回含status字段（up/down/unchecked）的 JSON -
纯被动检查（无模块）：Nginx 自身不暴露运行时节点状态，只能间接判断——查 error log 中近期
no live upstreams或connect() failed，再结合max_fails值推断
编写一键诊断脚本（Shell 示例）
以下是一个轻量、可直接运行的 Bash 脚本框架（适配 nginx-plus 或 check_module）：
#!/bin/bash UPSTREAM_NAME="backend" STATUS_URL="http://localhost/status?format=json" TIMEOUT=3 <h1>检查是否能连通状态接口</h1><p>if ! status_json=$(curl -s --max-time $TIMEOUT "$STATUS_URL" 2>/dev/null); then echo "❌ 状态接口不可达，请确认 nginx-plus license 或 upstream_check_module 是否启用" exit 1 fi</p><h1>提取该 upstream 下所有 server 状态</h1><p>down_nodes=$(echo "$status_json" | jq -r ".upstreams[\"$UPSTREAM_NAME\"].servers[] | select(.state == \"down\") | \"(.address) (.health_checks.last_passed // \"N/A\")\"")</p><p>if [ -z "$down_nodes" ]; then echo "✅ 所有节点健康" else echo "⚠️ 下线节点（IP + 最后一次通过检查时间）：" echo "$down_nodes" | while IFS= read -r line; do [[ -n "$line" ]] && echo " $line" done fi</p><h1>补充：检查最近 1 分钟 error.log 中的连接失败</h1><p>echo -e "\n? 近期错误线索（last 60s）：" journalctl -u nginx --since "1 minute ago" 2>/dev/null | grep -E "(connect|timeout|refused|no live)" | tail -5 | sed 's/^/ /'
保存为 nginx-health-diag.sh，赋予执行权限即可运行。建议搭配 jq 使用（Ubuntu/Debian 安装：apt install jq；CentOS：yum install jq）。
常见误判与验证技巧
-
“Down” 不等于服务挂了：可能是健康检查路径（如
/health）返回非 2xx、超时、SSL 验证失败，先手工 curl 对应节点的检查地址 -
时间不同步影响判断：Nginx 主动检查依赖系统时间，若节点时间偏差大，
last_passed可能显示异常早的时间 -
fail_timeout 未过期仍在“临时摘除”中：即使后端已恢复，Nginx 仍会在
fail_timeout时间内拒绝发流量，需等待或手动up -
配置热重载未生效：改完配置忘记
nginx -s reload，脚本看到的仍是旧状态
不复杂但容易忽略。
