严格超时熔断保护需连接、读写、重试三类超时协同控制，并配合健康状态自动剔除；分层设置proxy_connect_timeout（2–5s）、proxy_send_timeout（8–15s）、proxy_read_timeout（10–60s）；启用proxy_next_upstream与max_fails/fail_timeout实现故障隔离；通过keepalive和http/1.1长连接防误判；辅以limit_req限流作前置防线。
严格超时熔断保护不是靠单个参数实现的，而是通过连接、读写、重试三类超时协同控制，并配合健康状态自动剔除，让 Nginx 主动“放手”而非被动等待。
设置分层超时，避免请求卡死
超时必须按阶段拆解，不能只设一个 proxy_read_timeout 应付所有情况：
- proxy_connect_timeout 2–5s：仅控制 TCP 连接建立时间。后端进程僵死、端口未监听、防火墙拦截时，这个超时能快速失败，不浪费连接资源
- proxy_send_timeout 8–15s：限制向后端发送完整请求体（如大文件上传、JSON body）的时间。比 read_timeout 略短，防止请求发一半就卡住
- proxy_read_timeout 10–60s：等待后端返回响应头+响应体的总时长。需按接口实际耗时设定，例如报表导出可设为 300s，登录接口建议 ≤10s
启用重试与故障自动剔除
超时只是“发现慢”，真正实现熔断要靠重试触发节点隔离：
- 在 upstream 中配置 max_fails=3 fail_timeout=30s：某台后端连续 3 次因超时或错误被标记为 down，30 秒内不再转发请求
- 在 location 中必须加上 proxy_next_upstream error timeout http_500 http_502 http_503 http_504：只要触发任一条件，立刻尝试下一个节点，不等当前连接彻底超时
- backup 节点建议显式声明，确保主集群全失效时仍有兜底能力
防止假性故障干扰熔断判断
高频短连接容易引发 TIME_WAIT 暴涨或连接拒绝，导致误判为后端故障：
- upstream 块中添加 keepalive 32，复用空闲连接，降低建连压力
- location 中启用 HTTP/1.1 长连接：proxy_http_version 1.1 和 proxy_set_header Connection ""
- 避免使用默认的 http/1.0 或未清空 Connection 头，否则每次请求都新建 TCP 连接
补充限流作为前置防线
超时熔断是事后响应，限流是事前压制，两者结合才够“严格”：
- 用 limit_req_zone $uri zone=api_limit:10m rate=20r/s 对高危路径（如 /pay、/order）单独限速
- 搭配 burst=10 nodelay 允许短暂突发，但超出即返 503，避免流量洪峰直接打垮后端
- 可结合 error_page 503 /503.html 返回友好降级页，或 proxy_pass 到静态服务
