Nginx集群后端请求超时需分阶段控制：proxy_connect_timeout（建连，1–8秒）、proxy_send_timeout（发请求体，30–60秒）、proxy_read_timeout（等响应，略大于P95耗时）必须独立配置；配合proxy_next_upstream error timeout等触发重试与节点摘除，并通过location差异化设置及上下游超时协同实现稳定兜底。
在 Nginx 集群中，后端请求超时不是靠“等完再处理”，而是靠分阶段控制 + 事件驱动响应 + 故障转移协同来实现稳定兜底。关键不在于把 timeout 设多大，而在于每个阶段超时行为是否清晰、可预期、不拖垮 worker。
分阶段设置超时参数，避免混用
不同阶段的超时必须独立配置，否则会掩盖真实瓶颈或引发误判：
- proxy_connect_timeout：只管建连，内网建议 1–3 秒，跨公网可设 5–8 秒；超时直接返回 502，不进重试计数
-
proxy_send_timeout：控制发请求体（如大文件、长 JSON）的空闲等待，一般设 30–60 秒；超时即断连，不自动重试，除非显式配了
proxy_next_upstream ... error - proxy_read_timeout：最常触发的超时，从发完请求开始计时，等待后端首字节及后续响应；应略大于后端 P95 耗时（例如 P95 是 8s，设为 12–15s），流式接口（SSE/导出）需单独提升至 300s 或更高
让超时真正触发故障转移
光设 timeout 不等于高可用，必须配合重试与节点状态管理：
- 启用 proxy_next_upstream error timeout http_500 http_502 http_503 http_504，确保超时和典型错误都能触发换节点
- 用 proxy_next_upstream_tries 3 限制最多重试 2 次（首次 + 2 次重试），防雪崩；搭配 proxy_next_upstream_timeout 10s 控制整轮重试总耗时（含首次）
- upstream 中配 max_fails=2 fail_timeout=30s，连续两次超时即摘除节点，30 秒后自动恢复探测；
fail_timeout建议 ≥ 2×proxy_read_timeout，避免偶发抖动误摘
路径级差异化配置，不搞一刀切
同一集群常承载多种业务，统一 timeout 容易导致短接口被拖慢、长任务被误杀：
- 对高频 API（如 /login、/search），location 中设
proxy_read_timeout 10s - 对明确长耗时路径（如 /api/export、/ai/inference），单独 location 并设
proxy_read_timeout 300s - 配套调整
proxy_send_timeout和send_timeout，确保它们 ≥ 对应路径的proxy_read_timeout，防止中途切断
配套后端与连接复用，形成闭环
超时策略生效的前提是上下游协同：
- 后端自身超时（如 Tomcat 的
connectionTimeout、Spring Boot 的server.tomcat.connection-timeout）必须 小于 Nginx 的proxy_read_timeout，否则后端先断，Nginx 还在等 - upstream 块启用
keepalive 32，并在 proxy_pass 前加proxy_http_version 1.1和proxy_set_header Connection ''，让连接可复用，减少建连开销 - 日志中开启
$upstream_response_time，结合监控看真实耗时分布，验证 timeout 是否合理、重试是否触发
