Nginx 不支持直接运行自定义健康检查脚本，需通过外部探针服务（如 Flask/Go 实现的 /healthz 接口）暴露 HTTP 状态码供 nginx 的 health_check 指令调用，依据 200/503 等状态码动态调整 upstream 节点。
nginx 本身不支持直接运行自定义健康检查脚本（比如 Python 或 Shell 脚本），它的 upstream 健康检查仅限于基础 TCP 连通性、HTTP 状态码、响应头/体匹配等。若需检测“复杂逻辑”（如依赖数据库连通性、缓存状态、业务接口返回特定 JSON 字段、服务内部指标达标等），必须借助外部机制间接实现。
用 stub_status + 自定义探针服务暴露健康信号
核心思路：把复杂逻辑封装成一个轻量 HTTP 接口（称为“健康探针服务”），由 nginx 的 health_check 指令定期请求该接口，根据其 HTTP 状态码（如 200 表示健康，503 表示异常）决定后端是否参与负载。
- 在每个后端应用旁部署一个独立的健康探针服务（可用 Python Flask/FastAPI、Go、甚至简单 Bash + netcat + curl 实现）
- 探针服务启动时执行完整校验逻辑（例如：ping DB、查 Redis key、调用 /api/health、解析返回 JSON 中
"ready": true） - 校验通过则返回
HTTP 200 OK，否则返回HTTP 503 Service Unavailable（或 4xx） - nginx upstream 配置中启用
health_check，指向该探针地址（注意：不是业务端口，是探针专用端口，如:8081/healthz）
nginx 配置示例（基于 ngx_http_upstream_module + health_check）
需使用支持主动健康检查的 nginx 版本（官方开源版 1.11.5+，或 OpenResty；部分发行版需编译时启用 --with-http_upstream_health_check_module）：
upstream backend_cluster {
server 10.0.1.10:8080 max_fails=1 fail_timeout=10s;
server 10.0.1.11:8080 max_fails=1 fail_timeout=10s;
<pre class="brush:php;toolbar:false;"># 启用主动健康检查，每 5 秒请求一次 /healthz
health_check interval=5 fails=2 passes=2 uri=/healthz;
# 可选：指定健康检查使用的虚拟主机名（若探针服务校验 Host 头）
# health_check port=8081;}
server { listen 80; location / { proxy_pass https://www.php.cn/link/26a9c7ab6107b61166fbbc7e64756a1f; proxy_set_header Host $host; } }
⚠️ 注意：health_check 默认只检查 HTTP 状态码 2xx 和 3xx 为成功；若探针返回 200 但 body 含 "status":"degraded"，nginx 仍判为健康 —— 所以探针服务必须严格用 HTTP 状态码表达终态。
替代方案：用 consul + nginx-upstream-check-module（适合微服务环境）
当需要更灵活的健康判定（如聚合多个指标、支持 TTL、服务标签路由），可引入服务发现组件：
- 每个后端实例向 Consul 注册，并上报自定义健康检查脚本结果（Consul 支持执行 shell 脚本并按 exit code 判定）
- Nginx 编译时加入 nginx_upstream_check_module（第三方模块）
- 配合 consul-template 或 confd，动态生成 nginx upstream 配置，只包含 Consul 标记为 “passing” 的节点
- 优势：健康逻辑完全解耦，支持超时、重试、多级检查；缺点是架构变重，运维成本上升
不推荐的做法及风险提示
以下方式看似“直接”，但实际不可靠或违反 nginx 设计原则：
- 试图用
lua-resty-healthcheck在 Lua 层调用 os.execute 执行脚本 —— nginx worker 是多进程模型，脚本执行阻塞会拖慢整个 worker，且无超时控制，极易引发雪崩 - 用 cron 定期写文件 + nginx 的
if (-f /tmp/healthy.flag)判断 —— 文件状态不同步、竞态条件严重，无法实时反映服务真实状态 - 在业务接口里混入健康逻辑（如
/api/v1/users?health=1）并让 nginx 直接检查 —— 侵入业务代码、污染监控边界、增加主接口负担
真正健壮的故障转移，关键不在“nginx 能不能跑脚本”，而在于把健康决策权交给专业组件（探针服务或服务发现系统），让 nginx 专注做它最擅长的事：基于明确信号做快速、无状态的流量调度。
