nginx长连接性能优化需从客户端、上游、系统层及监控四方面协同：合理设置keepalive_timeout（30–60s）、keepalive_requests（100–500），启用http/1.1并清空connection头；upstream配置keepalive 32、避免ip_hash；调高worker_connections与内核参数，启用reuseport；通过stub_status和超时指令主动管控连接。
处理 Nginx 长连接（如 Long-polling）场景下的性能瓶颈，核心在于**避免连接积压、减少资源空耗、保障后端复用效率**。这类请求通常持续数秒至数十秒，空闲等待时间长，若配置不当，极易引发连接堆积、TIME_WAIT泛滥、worker资源耗尽等问题。
合理设置客户端长连接参数
Long-polling 依赖 HTTP/1.1 的 keep-alive，但默认值往往不适用高并发长等待场景：
- keepalive_timeout 建议设为 30–60 秒：太短（如默认 75s）会导致客户端频繁重连；太长（如 >120s）会使大量连接长期挂起，挤占 worker_connections 资源。
- keepalive_requests 可设为 100–500：Long-polling 单连接通常只发 1–2 次请求（建立 + 终止），设过高无意义，反而延缓连接释放。
- 务必启用 proxy_http_version 1.1 和清空 Connection 头：
proxy_set_header Connection "";
否则上游服务可能误判为短连接，提前关闭。
优化 upstream 连接池复用
后端（如 Node.js、Java 应用）才是 Long-polling 的实际处理方，Nginx 必须高效复用到它的连接：
- 在 upstream 块中显式配置：
keepalive 32;（每个 worker 保持最多 32 个空闲连接到单台后端）
keepalive_timeout 60s;
keepalive_requests 100; - 配合 proxy_next_upstream error timeout http_502，快速剔除无响应后端节点。
- 避免使用
ip_hash等会话绑定策略——Long-polling 连接生命周期长，易造成后端负载倾斜。
系统与 Nginx 资源层加固
长连接对文件描述符、端口、内核连接队列压力显著，需同步调优：
- worker_connections 至少设为 16384 或更高，并确认 ulimit -n 已调至匹配值（如 65535）。
- 内核参数重点调整：
net.core.somaxconn = 65535（监听队列）
net.ipv4.tcp_tw_reuse = 1（允许 TIME-WAIT 复用）
net.ipv4.tcp_fin_timeout = 30（加快连接回收） - 启用 reuse_port（需 Nginx ≥1.9.1）：
listen 80 reuseport;
让多个 worker 进程各自监听同一端口，缓解 accept 锁争用，实测短连接 QPS 可提升 2–3 倍，对 Long-polling 的连接分发也更均衡。
监控与主动清理空闲连接
通过 stub_status 模块实时观察连接状态，及时发现异常：
- 访问
/nginx_status查看 Waiting 数值：若持续 >80% 的worker_connections，说明大量连接处于空闲等待，需调低keepalive_timeout或检查后端响应延迟。 - 结合日志分析
$request_time和$upstream_response_time，区分是 Nginx 层阻塞还是后端处理慢。 - 对超时未响应的 Long-polling 请求，可在 location 中加：
proxy_read_timeout 60;（防止 Nginx 等待过久）
proxy_send_timeout 5;（快速中断异常响应流）
