Nginx 通过 proxy_next_upstream 实现被动故障识别，结合 upstream 参数设置健康阈值、proxy_set_header 透传状态信息，并暴露状态指标联动告警，构成动态感知闭环。
Nginx 本身不自带后端动态感知能力，但通过 ngx_http_proxy_module 配合其他机制，能构建出贴近实时的健康与负载反馈闭环。关键不在“单模块万能”，而在用好它的容错、透传和超时控制能力，并与 upstream 状态联动。
用好 proxy_next_upstream 实现被动故障识别
这是最基础也最关键的动态感知入口——它让 Nginx 在真实请求中“尝出”后端异常，而非只靠心跳：
- 显式开启常见失败重试：
proxy_next_upstream error timeout http_502 http_503 http_504; - 避免误重试：加上
http_404要谨慎，除非业务明确允许 404 重试；invalid_header可捕获后端返回空响应或格式错乱 - 注意限制：该指令只在响应头未发送前生效，响应体已开始传输时无法切换节点
- 搭配日志字段如
$upstream_addr和$upstream_status，可定位具体哪个节点频繁返回 503 或超时
配合 upstream 模块设置基础健康阈值
ngx_http_proxy_module 不管节点是否在线，真正决定“是否可用”的是 upstream 块里的参数。代理模块通过 proxy_pass 引用它，形成协同：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 每个
server行可设max_fails=3 fail_timeout=30s：连续失败 3 次后，30 秒内不再分发请求 - 权重（
weight）和慢启动（slow_start=15s）可用于灰度上线或恢复期流量控制 -
down标记可手动摘除节点；backup可设为备用机，仅当所有主节点不可用时启用 - 默认轮询策略下，节点状态变化会直接影响调度结果，无需额外插件
透传关键信息，支撑后端自主反馈
动态感知不只是 Nginx “看”后端，也要让后端能“说”自己状态。proxy_set_header 是桥梁：
- 传真实客户端 IP：
proxy_set_header X-Real-IP $remote_addr;+X-Forwarded-For $proxy_add_x_forwarded_for; - 传协议与主机：
proxy_set_header X-Forwarded-Proto $scheme;+proxy_set_header Host $http_host; - 后端服务据此可记录来源、做限流判断，甚至主动返回
{"status":"DEGRADED"}，再由 Nginx 的proxy_next_upstream或 Lua 扩展识别并降权
暴露与联动：把感知变成动作
感知若不输出、不触发，就只是日志里的数字。需打通可观测与响应链路：
- 用
location /status配合第三方模块（如nginx_upstream_check_module）或 OpenResty 的 Lua 脚本，输出 JSON 状态页 - 关键字段至少包含：节点地址、当前状态（up/down）、fail_count、last_checked、response_time_avg
- 对接 Prometheus：通过
nginx-module-vts或自定义 exporter 抓取指标，对upstream_server_state == 0设置告警 - 结合
balancer_by_lua_block（OpenResty），可在每次选节点前读共享字典中的健康评分，跳过低分节点
不复杂但容易忽略：proxy_next_upstream 是入口，upstream 参数是开关，header 透传是语言，状态暴露是眼睛。四者连起来，Nginx 才真正具备后端动态感知的骨架。
