WebSocket长连接要求Nginx worker_processes向下收敛（如8核设4–6），并绑定CPU、提升单进程文件描述符上限（worker_rlimit_nofile≥worker_connections）、启用epoll与multi_accept，配合keepalive_timeout、proxy_read/send_timeout等参数协同调优。
WebSocket长连接业务对Nginx的资源占用模式与HTTP短连接完全不同：每个连接常驻内存、持续消耗文件描述符、维持双向socket状态，且生命周期可能长达数小时。因此，worker_processes不能按物理核心数“照搬”，必须向下收敛，避免单个worker因连接堆积而内存耗尽或fd打满。
按CPU核心数做减法，不是加法
即使服务器是8核16线程，也不建议设为8或更高：
- 通用Web服务可设为物理核心数（如8核→
worker_processes 8），但WebSocket场景要降档 - 大量长连接时，推荐设为物理核心数的1/2～3/4：8核机器设为
4或6更稳妥 - 若同时承担TLS终止（如WSS），可比该值多配1个，例如8核+高SSL负载→
worker_processes 5～7 - 混合部署（Nginx与Java/DB共存）需预留资源，可用
$(nproc --all)-2动态计算
必须同步绑定CPU与提升单进程上限
只改数量不配约束，等于没调：
-
worker_cpu_affinity auto;：让每个worker固定绑定独立物理核心，避免上下文切换开销 -
worker_rlimit_nofile 65535;：写在main块中，确保单进程能打开足够多的连接（至少≥worker_connections） - 系统级ulimit必须跟上：
nginx用户的nofile软硬限制需≥worker_rlimit_nofile - events块中显式启用
use epoll;和multi_accept on;，提升事件处理效率
验证是否真正跑稳了
重载配置后别只看启动成功，要查实际运行态：
- 执行
ps -eo pid,psr,comm | grep nginx，确认各worker分布在不同CPU编号上 - 用
htop观察CPU使用率：所有worker的%CPU应大致均衡，总和接近N×100%（N为worker数） - 启用
stub_status模块，访问/nginx_status，重点关注Waiting值；长期偏高说明连接排队，此时应优先调大worker_connections，而非增加worker数
配合长连接的关键参数联动
worker_processes只是入口，它必须与以下参数协同才有效：
-
worker_connections建议设为2048–8192（非短连接的4096–16384），并严格匹配worker_rlimit_nofile -
keepalive_timeout设为3600s或更高，配合后端心跳周期，防止空闲断连 -
proxy_read_timeout和proxy_send_timeout需≥客户端最长无数据间隔，常见设为3600–86400 - 后端upstream需加
keepalive 32;，复用到后端的连接，降低后端建连压力
