Nginx HTTPS上游故障摘除需协同配置max_fails、fail_timeout、proxy_next_upstream及超时参数；内网、跨区、强一致场景分别推荐max_fails=2/3/1组合，并必须启用proxy_next_upstream error timeout http_502 503 504等配套项。
要让 Nginx 在 HTTPS 上游出现故障时快速摘除节点，同时避免误判导致流量震荡，关键不是单独调大或调小 max_fails，而是把它和 fail_timeout、proxy_next_upstream 以及超时参数协同配置，形成一套匹配 HTTPS 后端行为的容错节奏。
理解 HTTPS 上游的失败特征
HTTPS 后端（如反向代理的网关、TLS 终结的 API 服务）比普通 HTTP 更容易因握手耗时、证书验证、TLS 版本协商等问题触发连接级失败；同时，真实业务错误（如 502 Bad Gateway、503 Service Unavailable）也更常见。这些失败不是“慢”，而是“不可达”或“协议层中断”，所以健康感知要更敏锐，但又不能把一次 TLS 握手超时当成永久故障。
- 连接建立阶段失败（SSL handshake timeout、connection refused）默认计入
max_fails - HTTP 状态码如 502/503/504 不会自动计入，必须通过
proxy_next_upstream显式启用 - HTTPS 延迟通常略高于 HTTP，
proxy_connect_timeout和proxy_read_timeout要略宽松，否则未等响应就中断，反而制造虚假失败
推荐的 upstream 配置组合
针对 HTTPS 后端稳定性与敏感度的平衡，建议按场景选用以下三类配置：
-
内网直连 HTTPS 服务（如 K8s Ingress Controller、同机房 TLS 网关）：
max_fails=2 fail_timeout=10s
→ 10 秒内连续 2 次失败（如握手超时 + 502）即摘除，10 秒后自动重试，适合低延迟、高可信链路 -
跨可用区或带 WAF 的 HTTPS 上游（如云厂商 ALB、CDN 回源）：
max_fails=3 fail_timeout=30s
→ 容忍一次网络抖动或 WAF 策略临时拦截，兼顾稳定与响应速度 -
强一致性 HTTPS 接口（如支付回调、证书吊销查询）：
max_fails=1 fail_timeout=10s
→ 单次失败即隔离，但务必配合proxy_next_upstream timeout http_502 http_503和客户端重试逻辑，防止误杀
必须同步配置的配套项
只写 max_fails 几乎无效。以下四项缺一不可：
-
启用对应失败类型重试：在
location块中明确写proxy_next_upstream error timeout http_502 http_503 http_504;
不加http_502，哪怕上游返回满屏 502，max_fails也不会涨 -
控制重试边界：
proxy_next_upstream_tries 3;（最多换 2 台其他节点）proxy_next_upstream_timeout 10s;（整个重试过程不超过 10 秒） -
超时参数要梯度设置：
proxy_connect_timeout 5s;（建连不能太长，否则卡住连接池）proxy_read_timeout 15s;（读响应需比fail_timeout小，比如 fail_timeout=30s 时设为 15–20s） -
禁用无意义重试：
不要加http_404或http_401到proxy_next_upstream，它们是业务正常响应，加入会导致合法请求被反复转发、误判下线
额外建议：叠加主动健康检查提升可靠性
被动检查依赖真实请求，故障发现有滞后。对关键 HTTPS 上游，建议用 OpenResty 或 Nginx Plus 启用主动探测：
- 每 5 秒发一次 HTTPS
HEAD /health请求（证书校验开启） - 设置
fails=2、passes=2、timeout=3s - /health 接口必须真实检测 TLS 连通性 + 后端服务可用性（例如用
curl -k -I https://upstream/health模拟）
主动检查可提前于用户请求发现故障，再结合 max_fails 的被动兜底，实现“快发现 + 安全恢复”的双保险。
