Nginx健康探测超时需区分被动与主动探测：被动探测依赖proxy_connect_timeout（3–5s）、proxy_send_timeout（≤10s）、proxy_read_timeout（略大于后端最慢响应，≤15s）及max_fails/fail_timeout（如3/30s）；主动探测需nginx_upstream_check_module，配置timeout（1000–3000ms）、interval（3000ms）、rise/fall（2/5）等参数，且须避免网络拦截、健康接口依赖外部服务及多worker状态不一致等问题。
被动探测的超时控制：靠 proxy_*_timeout + max_fails/fail_timeout
这是开源 Nginx 原生支持的方式，不发独立心跳，所有超时都绑定在用户请求链路上。
- proxy_connect_timeout：与后端建立 TCP 连接的超时。设太长（如默认 60s）会导致“卡住”；建议设为 3–5 秒，避免连接失败阻塞太久
- proxy_send_timeout：向后端发送完整请求的超时。适用于大 Body 场景；一般设 10 秒内 即可
- proxy_read_timeout：等待后端返回响应头/首字节的超时。关键参数！应略大于后端最慢正常响应时间，但不超过 15 秒，否则会拖慢故障发现
- max_fails=3 fail_timeout=30s：不是单次超时，而是统计窗口。表示「30 秒内连续失败 3 次」才摘除节点。fail_timeout 同时定义屏蔽时长和统计周期
- proxy_next_upstream timeout error http_502 http_503 http_504：只有这些情况才触发重试。别加 http_404 或 http_500，除非业务确认它们一定代表后端异常
主动探测的超时控制：用 nginx_upstream_check_module 的 check 参数
需要手动编译该模块（或使用 OpenResty/Tengine）。它独立于业务请求，走自己的探测循环。
- timeout=1000：单次 HTTP/TCP 探测的超时，单位毫秒。建议设 1000–3000ms，太短易误判，太长拉低探测频率
- interval=3000：两次探测间隔，单位毫秒。3 秒是常用平衡点；低于 2 秒可能引发多 worker 冲突，高于 10 秒则故障发现延迟明显
- rise=2 fall=5：防抖设计。连续 2 次成功才恢复，连续 5 次失败才下线，避免网络抖动或 GC 瞬间 503 导致误摘
- type=http 时，务必配 check_http_send 和 check_http_expect_alive；推荐用 HEAD /health 而非 GET，省带宽、减后端压力
- default_down=true 必须开启，防止 Nginx 启动瞬间把未就绪节点当健康节点用
超时相关常见陷阱
- 防火墙或 WAF 拦截了
/health路径，导致主动探测全失败——先检查网络路径是否通，再调参数 - 后端健康接口本身有依赖（如 DB 连不上就返回 503），但你又配置了
check_http_expect_alive http_2xx，结果误判——应让健康端点只检查自身进程状态，不连外部依赖 - 多个 worker 进程各自探测，状态不共享，导致同一节点在不同 worker 视角下状态不一致——这是设计行为，不是 bug；若需统一视图，得靠外部监控收敛
- 把
proxy_read_timeout设成 60 秒，而业务平均响应只要 200ms，等于给故障留了整整一分钟才发现——超时值必须贴合实际业务水位
