关键在于区分客户端与后端连接管理，通过超时分级（proxy_read_timeout、keepalive_timeout等）、连接复用（upstream keepalive、least_conn）和状态感知（健康检查、协议头控制）解耦耗时逻辑，并辅以资源限制防雪崩。
处理大量长耗时请求（如文件上传、大报表导出、实时流响应、WebSocket 推送等），关键不是“扛住连接数”，而是让 Nginx 在不阻塞、不超限、不误杀的前提下，稳住连接生命周期，并把压力合理传导给后端。核心思路是：**区分客户端连接与后端连接的管理策略，用超时分级+连接复用+状态感知来解耦耗时逻辑。**
客户端侧：延长并可控地保持连接
客户端发起长耗时请求时，Nginx 需避免因默认超时主动断开，但也不能无限等待。重点配置：
- proxy_read_timeout：设为合理上限（如 600s 或 1800s），表示 Nginx 等待后端返回完整响应的最长时间；超过即关闭连接并返回 504。这是防“挂死”的第一道闸。
-
keepalive_timeout：建议设为 75–120s，控制客户端空闲连接存活时间；它和
proxy_read_timeout是两回事——前者管“没发新请求的静默期”，后者管“正在等后端响应的忙碌期”。 - client_header_timeout / client_body_timeout：分别控制客户端发送请求头/请求体的超时（如上传大文件时体传输慢），建议设为 300s 左右，防半开连接堆积。
后端侧：复用连接 + 智能调度
长耗时请求容易导致后端连接被长期占用，若 Nginx 还按轮询分发，会加剧热点。应启用：
-
upstream 中启用
least_conn：优先将新请求分给当前活跃连接数最少的后端节点，避免某台机器因几个慢请求就堵死。 -
配置
keepalive N（如keepalive 32）：每个 worker 进程为每个后端维护最多 N 个空闲长连接；值不宜过大（一般 ≤ 后端单实例最大连接池的 1.2 倍），否则内存浪费且故障隔离变慢。 -
配合健康检查：加上
max_fails=3 fail_timeout=30s，让 Nginx 自动踢掉暂时无响应的后端，防止慢请求持续打到异常节点。
协议与头部：显式声明长连接语义
HTTP/1.1 下，必须显式告诉上下游“我们支持复用”，否则默认按短连接处理：
-
proxy_http_version 1.1：强制使用 HTTP/1.1，启用 keep-alive 能力。 -
proxy_set_header Connection ""：清空客户端传来的 Connection 头（如Connection: close），避免 Nginx 被误导而提前关闭连接。 - 对 WebSocket 场景，额外加：
proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";
资源兜底：防雪崩的关键限制
再好的长连接管理，也需硬性资源约束：
-
worker_connections：确保全局连接容量足够（如设为 10240），并配合
worker_processes auto充分利用多核。 -
limit_conn / limit_req：可按 IP 或 key 限制并发连接数或请求频次，防个别用户拖垮整体（例如：
limit_conn addr 100;）。 - proxy_buffering off：对流式响应（如 SSE、大文件下载），关闭缓冲，让数据边生成边转发，降低 Nginx 内存压力。
