生产环境Nginx代理超时必须分段控制：proxy_connect_timeout管建连（同机房3–5秒）、proxy_send_timeout管发请求（10–30秒）、proxy_read_timeout管响应间隔（业务耗时2–3倍，≥15秒），并按location优先级配置、配合健康检查与重试机制。
生产环境 Nginx 代理超时配置不能靠“统一设大值”来保命，必须按请求生命周期分段控制、按网络拓扑分级设定、按协议类型精准匹配，否则不是压垮后端，就是提前掐断合法慢请求。
分清三段超时职责，别全扔给 proxy_read_timeout
Nginx 代理一次请求实际走过三段独立路径，每段有专属超时参数：
- proxy_connect_timeout：只管 TCP 建连（SYN → SYN-ACK），不涉及业务逻辑。同机房设 3–5 秒，跨可用区 5–8 秒，混合云可到 10–15 秒；超过 20 秒需查链路或后端启动问题。
- proxy_send_timeout：Nginx 把完整请求发给后端后，等后端确认收完的时间。大文件上传、长请求体场景下设 10–30 秒；若后端冷启慢（如 Spring Boot 首次加载），此值也需同步放宽。
- proxy_read_timeout：不是“总响应耗时”，而是“两次读操作间隔”。它决定长连接空闲多久断开，也兜底 WebSocket 心跳、流式响应、慢查询。应设为业务最长耗时的 2–3 倍，最低不低于 15 秒；对小时级导出接口，可设至 3600 秒，但必须配套健康检查与重试机制。
配在对的地方，作用域优先级必须理清
超时参数生效取决于配置位置，优先级从高到低是：location > server > http。常见失效原因：
- 在 http 块设了 proxy_read_timeout 30s，但实际请求命中某个 location，而该 location 没写 proxy_* 超时，就继承默认 60 秒；
- 用了 fastcgi_pass（PHP 场景），proxy_* 全部无效，必须改用 fastcgi_read_timeout，并同步调 PHP-FPM 的 max_execution_time 和 request_terminate_timeout；
- gRPC 或 uWSGI 后端，对应使用 grpc_read_timeout、uwsgi_read_timeout，不可混用 proxy_*；
- 务必在 proxy_pass 所在的 location 块内显式配置，不要依赖上级继承。
配合健康检查与重试，单设 timeout 不解决问题
只调大超时，不解决节点宕机后持续打流量的问题：
- 主动健康检查 interval 必须大于 proxy_connect_timeout（例如后者 5s，前者至少设 10s）；
- fails 设 2–3 次防瞬时抖动误摘，passes 设 1–2 次确保恢复即回流；
- 启用 proxy_next_upstream error timeout invalid_header http_500 http_502 http_503；
- proxy_next_upstream_tries 控制最大重试次数（建议 2–3），proxy_next_upstream_timeout 限制整条重试链路总耗时（建议 ≤ proxy_read_timeout）。
别漏掉客户端侧和系统级协同参数
代理超时不是孤立存在，要和前后两端对齐：
- client_body_timeout：控制客户端两次上传数据包间隔，不是总上传时间。弱网或大文件上传建议设 60–300 秒；
- client_header_timeout：尤其 TLS 握手慢时易超时，跨云或移动端建议 30–60 秒；
- send_timeout：响应下发阶段，客户端未 ACK 的等待时间，建议 15–30 秒；
- keepalive_timeout：Nginx 与客户端之间长连接空闲时间，建议 30–75 秒；upstream keepalive 连接池建议设 32–64，提升复用率；
- 所有 proxy_set_header 中必须含 Connection ''，避免某些后端（如 gRPC）因连接头干扰超时判定。
