Nginx可通过本地动态健康端点（如/healthz）实现精准切流与恢复：脚本定期执行业务检测并控制其HTTP状态码，Nginx用health_check主动探测该端点，结合proxy_next_upstream被动容错及恢复确认机制，完成闭环。
在 Nginx 中，原生的健康检查（如 upstream 的 health_check 指令）仅支持基础 HTTP 状态码探测，无法直接执行自定义逻辑（如 DB 连通性、缓存命中率、下游依赖延迟等）。要实现“精准切流与恢复”，需将外部监控脚本的结果映射为 Nginx 可感知的状态——核心思路是：**用脚本动态更新一个本地健康探针端点（如 /healthz），再让 Nginx 的 health_check 或 proxy_next_upstream 机制基于该端点做决策。**
1. 构建可被 Nginx 探测的动态健康端点
不依赖第三方模块（如 nginx-upstream-check-module），而是用轻量 Web 服务（如 Python + Flask / Bash + socat / 或静态文件）暴露一个本地 HTTP 接口（如 http://127.0.0.1:8080/healthz），其响应内容和状态码由外部脚本实时控制：
- 脚本定期执行业务级检测（例如：curl 后端 API + 校验 JSON 字段、mysql -e "SELECT 1"、检查 Redis PING 延迟）
- 检测通过 → 写入
echo 'ok' > /var/run/nginx-health.status并返回 HTTP 200 - 检测失败 → 写入
echo 'fail' > /var/run/nginx-health.status并返回 HTTP 503（或 4xx） - 建议加简单 TTL 或锁机制，避免脚本并发冲突；可用
systemd-timer或crond控制执行频率（如每 3 秒一次）
2. 在 upstream 中配置基于该端点的主动健康检查
启用 Nginx Plus 或开源版 1.19+（支持 health_check 的增强语法），将健康检查目标指向本地探针：
upstream backend {
server 10.0.1.10:8080;
server 10.0.1.11:8080;
<pre class="brush:php;toolbar:false;"># 主动健康检查：每 2 秒请求本地探针
health_check uri=/healthz interval=2 fails=2 passes=3;}
注意：health_check 默认只作用于 upstream 内部服务器的“连接可达性”，但配合本地探针，就实现了将任意复杂逻辑转化为“是否参与负载”的开关。Nginx 会自动摘除/恢复后端节点。
3. 配合被动检查与 error_page 实现秒级故障转移
主动检查有最小间隔（通常 ≥2s），对突发错误不够敏感。补充被动策略提升响应速度：
- 在 location 中配置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504; - 同时设置
proxy_next_upstream_tries 2;和proxy_next_upstream_timeout 1s; - 搭配
error_page 502 503 504 = @fallback;，在上游全部不可用时跳转到降级页或备用集群
这样，即使某个后端瞬间崩掉（未被主动检查捕获），Nginx 也能在单次请求失败后立即重试另一台，用户几乎无感。
4. 安全闭环：恢复确认 + 人工干预通道
避免“误恢复”导致雪崩。脚本在判定恢复前，应增加验证环节（如连续 3 次成功 + 关键指标达标），并在日志中记录原因：
- 将恢复动作写入 audit 日志（含时间、脚本 PID、检测项、原始输出）
- 提供手动冻结开关：脚本读取
/etc/nginx/health.lock文件存在则跳过自动恢复 - 集成通知：恢复/摘除事件触发企业微信/钉钉机器人告警，附带当前后端列表与健康状态快照
不复杂但容易忽略。关键是把“业务健康”翻译成 Nginx 能懂的 HTTP 信号，再用它驱动原生机制——无需改 Nginx 源码，也不强依赖商业版功能。
