nginx高并发超时策略需与上游能力、连接复用及系统资源联动设计：proxy_read_timeout应设为后端p99响应时间加1～3秒缓冲；keepalive需分客户端与upstream两侧配置；启用proxy_next_upstream防雪崩；并调优系统级参数如worker_rlimit_nofile和tcp_fin_timeout。
高并发下 Nginx 代理超时策略不能只盯着 proxy_read_timeout 这几个参数调，必须和上游处理能力、连接复用节奏、系统资源水位联动设计。调得太松，连接堆积、文件描述符耗尽；调得太紧，大量 504 和重试压垮后端。关键在于“对齐”——让 Nginx 的等待逻辑匹配真实链路瓶颈。
一、先对齐上游真实处理能力
代理超时不是拍脑袋定的，得从后端服务的实际响应分布出发：
- 查后端应用的 P95/P99 响应时间（比如 Tomcat 或 Go 服务），proxy_read_timeout 应设为 P99 + 缓冲（建议 1～3 秒），而不是统一写 60 秒
- 如果后端平均 RT 是 80ms、P99 是 320ms，那
proxy_read_timeout 5s就足够；若 P99 已达 8s，再设 5s 就会频繁触发 504 -
proxy_connect_timeout要小于后端 TCP 握手实际耗时（通常 1～3s），云环境建议设3s；内网直连可压到1s -
proxy_send_timeout主要防后端写响应卡住，一般设为proxy_read_timeout的 1.2～1.5 倍即可，避免单次发送阻塞整条连接
二、按场景分层设置 keepalive 超时与复用策略
客户端连接和 upstream 连接是两套生命周期，必须分开控制：
- 客户端侧：
keepalive_timeout 30s（非 CDN/静态站场景），keepalive_requests 1000，避免小请求反复建连，又不长期占着 worker 连接 - upstream 连接池：必须显式启用长连接，否则每次请求都新建 TCP，放大后端压力
upstream backend {<br> server 192.168.1.10:8080;<br> keepalive 32;<br>}
其中keepalive 32表示每个 worker 进程最多缓存 32 个空闲 upstream 连接 - 对应 proxy 指令要补全：
proxy_http_version 1.1;+proxy_set_header Connection '';，否则 upstream keepalive 不生效
三、防止超时引发的雪崩式排队
504 不是终点，而是排队开始的信号。以下配置能快速释放被卡住的连接：
-
proxy_next_upstream error timeout http_502 http_504;—— 允许失败后自动切到其他节点（有多个 upstream 时） -
proxy_next_upstream_tries 3;+proxy_next_upstream_timeout 10s;—— 控制重试总时长，避免无限兜底 - 配合限流：
limit_req zone=api burst=20 nodelay;，把突发流量削峰，比等超时再断更可控 - 加监控项：
$upstream_response_time和$request_time差值持续 >2s，说明上游在排队，该扩线程池或加节点了
四、系统层兜底：别让超时失效
Nginx 配置再细，也架不住系统级限制拖后腿：
-
worker_rlimit_nofile必须 ≥worker_processes × worker_connections，且同步改/etc/security/limits.conf中* soft nofile和hard nofile -
/etc/sysctl.conf加上：net.ipv4.tcp_fin_timeout = 30、net.ipv4.tcp_tw_reuse = 1，加速 TIME_WAIT 回收，避免端口耗尽 - 检查
net.core.somaxconn（默认 128）和net.core.netdev_max_backlog，高并发下至少提到 65535，否则新连接还没进 nginx 就被内核丢弃
