Nginx Worker 进程通过分级策略自主管理长连接：客户端侧靠 keepalive_timeout 与 keepalive_requests 控制空闲时长和请求数；upstream 侧依赖 upstream keepalive、proxy_http_version 1.1 和 proxy_set_header Connection "" 三者协同实现连接复用，所有操作均在 worker 内独立完成，无需 master 干预。
Nginx 的 Worker Process 本身不“维持”长连接状态，而是按需复用、主动管理、分级控制——它不被动守着连接，而是通过明确策略对客户端连接和上游连接分别建模、调度与清理。
Worker 进程如何管理客户端长连接
客户端到 Nginx 的连接由每个 worker 独立处理，关键靠两个参数协同生效：
-
keepalive_timeout：空闲等待时间（如设为 60s），超时即关闭该 socket -
keepalive_requests：单连接最大请求数（如设为 1000），达到即断开
当一个请求结束，worker 会把对应 TCP 连接标记为 idle，并放入本进程的空闲连接队列；下个同客户端请求到来时，优先从中取出复用。若队列为空、超时或满员，就新建连接。
这个过程完全由 worker 自主完成，无需 master 干预，也不依赖操作系统 TCP keepalive。
Worker 进程如何管理 upstream 长连接
Nginx 与后端的连接池是 per-worker、per-upstream server 的，靠三要素配合：
-
upstream { keepalive N; }：每个 worker 最多缓存 N 个空闲连接到该后端 -
proxy_http_version 1.1;：确保发给后端的是 HTTP/1.1 请求，支持复用 -
proxy_set_header Connection "";：清除干扰头，避免后端误判为短连接
比如配置 keepalive 32 + 4 个 worker + 2 台后端，理论最多保留 4 × 2 × 32 = 256 个空闲 upstream 连接。这些连接在空闲时受 keepalive_timeout（upstream 级）约束，不是永久驻留。
Worker 不会无限等待， reload 时有兜底机制
遇到 WebSocket、大文件上传等长耗时连接，worker 在 reload 时可能卡在 “shutting down” 状态。此时 worker_shutdown_timeout（需写在 main 块）起作用：
- 设为 30s，表示旧 worker 最多再撑 30 秒，之后强制关闭所有剩余连接退出
- 该值应略大于业务最长响应时间（如
proxy_read_timeout），防止误杀活跃流
实际效果取决于系统资源与协同配置
worker 能否稳定跑满长连接能力，还依赖：
-
worker_connections设置是否匹配ulimit -n和net.core.somaxconn -
worker_rlimit_nofile是否同步调高 - 后端服务自身是否启用 connection timeout，且比 Nginx 的
keepalive_timeout更长
不复杂但容易忽略
