worker_connections需按直播连接类型精准设置：hls建议4096–8192，http-flv/websocket-flv建议2048–4096，rtmp推流需预留fd；必须同步对齐系统、用户、nginx进程三级文件描述符限制，并启用epoll、multi_accept等events参数。
在流媒体直播分发场景中，worker_connections不能按常规Web服务思路设置——它直接决定单个worker能承载多少路观众连接，而一路HLS或HTTP-FLV拉流就占1个连接，RTMP推流再占1个，WebSocket弹幕又占1个。设高了撑不住，设低了连不上，必须结合连接类型、生命周期和系统资源精准匹配。
按连接性质区分配置区间
直播场景的连接不是均质的：RTMP推流连接稳定但数量少（通常1–10路），观众拉流连接量大但协议不同、持续时间差异显著。
-
HLS（.m3u8 + .ts）：每个观众会频繁发起HTTP请求（每5–10秒拉一次新ts片段），实际是短连接池行为，
worker_connections建议设为 4096–8192，配合keepalive_timeout 15;复用连接减少开销 -
HTTP-FLV 或 WebSocket-FLV：单观众维持1个长连接，持续几十分钟，内存与fd占用更刚性，推荐 2048–4096，并严格设置
client_body_timeout 60s;和reset_timedout_connection on;主动清理僵死连接 -
RTMP 推流端（如 OBS）：通常仅几路，但需预留足够fd给后续控制接口（如
/control）、状态页（/stat）及日志写入，不单独占大头，但不可忽略
必须同步对齐的三层文件描述符限制
只改 worker_connections 没用。真实并发上限由三者最小值决定：
-
系统级：
/proc/sys/fs/file-max建议设为worker_processes × worker_connections × 1.5（含TIME_WAIT、SSL缓存、日志句柄等冗余） -
用户级：在
/etc/security/limits.conf中为 nginx 运行用户（如www-data）添加：www-data soft nofile 65536www-data hard nofile 65536 -
Nginx进程级：在
nginx.conf主块（http外）加：worker_rlimit_nofile 65536;（必须 ≥worker_connections，否则启动失败或静默降级）
events 块关键协同参数不可省略
Linux下仅靠调高 worker_connections 不足以应对突发拉流洪峰，必须启用事件模型优化：
-
use epoll;—— 必须显式声明，避免回退到低效的select/poll -
multi_accept on;—— 让一个worker在单次事件循环中尽可能多地accept()新连接，缓解排队 -
accept_mutex on;—— 默认开启，防止多个worker争抢同一连接导致“惊群” -
worker_connections值应 ≤ 单进程 ulimit 的 80%（HTTPS场景还要额外预留SSL session cache等fd）
配套资源节流与验证手段
光设参数不够，得让系统“稳得住、看得清”：
- 关闭未启用的日志写入；若需访问日志，改用缓冲模式：
access_log /var/log/nginx/access.log buffer=64k flush=1s; - 监控实时连接数：
ss -s | grep "TCP:"或 Nginx/stat页面（需启用rtmp_stat） - 压测时重点看：
lsof -u www-data | wc -l（实际打开fd数）是否接近ulimit -n，而非只盯Nginx error log里的“too many open files”
