nginx健康监控需分层验证：后端探针响应码须真实反映业务状态（如db失败返回503），配合lua解析响应体；主动检查看/status页up/down及rise/fall计数器；被动检查验证proxy_next_upstream是否触发重试；prometheus指标须与实际故障同步。
验证生产环境中 Nginx 健康监控的状态码，核心不是只看 Nginx 自身返回的 HTTP 状态码（如 200、502），而是要分层确认：谁在返回状态码？返回的是哪一层的健康信号？是否与真实业务可用性一致？
看后端健康探针的实际响应码
主动健康检查（如 nginx_upstream_check_module）发送的 /health 请求，其响应状态码必须由后端服务真实生成，并被 Nginx 正确识别。
- 配置中明确指定 check_http_expect_alive http_2xx，但仅 2xx 不够——需确保后端 /health 接口在数据库连不上、缓存不可用等场景下，主动返回 503 或 500，而非伪装成 200
- 用 curl 模拟探针请求，带上完全相同的 Host 头和请求体：
curl -v -H "Host: api.example.com" http://backend-ip:8080/health
观察真实响应码 + 响应体内容，确认是否含"status":"down"类语义字段 - 若后端返回 200 但 JSON 中
"db": "unreachable"，Nginx 默认仍判为健康；此时需配合 Lua 脚本或 OpenResty 做响应体解析，否则监控存在严重盲区
查 Nginx 主动检查模块的状态页
访问 /status（或 /status/format/json）页面，直接读取节点级健康判定结果，比猜日志更可靠。
- 每个 upstream server 行应显示 up/down 状态，以及 rise/fall 计数器变化 —— 连续失败次数达到 fall=3 后状态应变为 down
- 注意字段 healthcheck（vts 模块）或 check_status（upstream_check）是否为 up，而非仅看 status 字段是否为 200
- 如果某节点显示 down 但 response_code 是 200，说明探针收到了响应，但语义校验失败（如超时、内容不匹配），需回查 check_http_send 和 expect 配置
核对 proxy_next_upstream 触发的真实转发行为
被动健康检查靠 proxy_next_upstream 指令兜底，但它的生效有严格前提，必须验证是否真在起作用。
- 手动让一个后端返回 502（例如临时停掉服务），然后发起请求，抓包或看 access_log，确认 Nginx 是否记录了 upstream: [failed] 并重试下一节点
- 检查配置中是否包含 proxy_next_upstream error timeout http_502 http_503 —— 缺少 http_502 就不会因 502 切走
- 注意：该机制只在响应头未发出前生效。如果后端已返回部分响应体再断连，Nginx 无法重试，此时状态码仍是 502，但不会触发切换
交叉验证 Prometheus 告警中的状态码指标
监控系统里的数字是否可信，取决于采集源是否反映真实判定逻辑。
- 查 nginx_upstream_healthcheck_status{status="down"} 是否随人工模拟故障实时变 1，且持续时间与 fall 阈值一致
- 对比 nginx_upstream_response_code（vts-exporter 提供）中 5xx 分布，是否与下游服务故障时段吻合；若 5xx 高但 upstream 状态仍为 up，说明健康检查粒度太粗
- 告警规则如 count by (upstream) (nginx_upstream_healthcheck_status == 1) ，必须确保该 count 统计的是真正“可承接流量”的节点，而非仅存活的节点
