worker_connections需按连接类型差异化调优：长连接为主时保留60%～70%余量，短连接密集型可设16384并同步调高somaxconn和tcp_tw_reuse，混合场景建议起步8192，必须与ulimit、worker_rlimit_nofile、epoll、multi_accept及keepalive_timeout协同配置，否则无效。
worker_connections 不是设得越高越好，尤其在长连接与短连接混合的场景下，必须兼顾连接持有时间、系统资源消耗和并发吞吐之间的平衡。关键在于让每个 worker 进程既能稳定承载大量长连接（如 WebSocket、SSE、HTTP/1.1 Keep-Alive），又能快速响应并释放短连接（如 API 查询、静态资源请求），避免 FD 耗尽或内存堆积。
区分连接类型，按需分配资源余量长连接持续占用文件描述符（FD）和内存，而短连接虽生命周期短，但高频时会引发大量 TIME-WAIT、accept 队列溢出和上下文切换开销。因此不能简单套用“最大连接数 = worker_processes × worker_connections”来规划：对长连接为主的服务（如实时消息网关），建议保留 60%～70% 的 worker_connections 用于维持活跃连接，其余留给新连接接入和上游通信对短连接密集型服务（如 RESTful API 网关），可适当提高 worker_connections（如 16384），但必须同步调高net.core.somaxconn和net.ipv4.tcp_tw_reuse，防止监听队列丢包和端口耗尽混合场景推荐起步值为 8192，再根据压测中active connections与reading/writing/waiting的比例动态调整：waiting 长期高于 active 的 30%，说明连接复用率低，需检查 keepalive_timeout 和 upstream keep-alive 设置配套调优 events 模块参数仅改 worker_connections 不起作用，必须配合事件模型与连接调度策略：use epoll;—— Linux 下强制启用高效 I/O 多路复用，避免 select/poll 性能衰减multi_accept on;—— 允许单次事件触发时尽可能多地 accept 新连接，减少短连接排队延迟accept_mutex on;—— 在多 worker 场景下避免惊群，防止长连接空闲时仍频繁争抢 accept 锁keepalive_timeout 15s;—— 比默认 65s 更激进；长连接业务可单独在 location 中延长，避免全局设置拖累短连接回收同步收紧系统级资源限制worker_connections 生效的前提是底层资源不卡脖子：单进程 FD 上限：确保ulimit -n≥ worker_connections，且worker_rlimit_nofile设为相同或略高（如 8192 → 10000）
系统总句柄池：
fs.file-max应 ≥ worker_processes × worker_rlimit_nofile × 1.2（预留日志、缓存、上游连接等开销）
TCP 监听队列：net.core.somaxconn = 65535，避免高并发短连接 burst 时丢 SYN 包TIME-WAIT 控制：net.ipv4.tcp_tw_reuse = 1+net.ipv4.tcp_fin_timeout = 30，加速端口回收，特别利于短连接突发场景验证与观测要点配置生效后，不能只看 nginx -t 或启动成功，要通过运行态指标确认是否真正适配混合负载：用nginx -s reload后执行ss -s查看 socket 统计，重点关注total、tcp、tw（TIME-WAIT 数量）是否突增异常访问/nginx_status（需开启 stub_status）观察Active connections与Reading/Writing/Waiting的分布：Waiting 长期 > 80% 表示连接积压，可能是 upstream 响应慢或 keepalive 复用未生效用cat /proc/$(pgrep nginx)/limits | grep "Max open files"确认 worker 进程实际加载的 nofile 限制是否符合预期压测时关注错误日志中的"accept() failed (24: Too many open files)"或"connect() failed (11: Resource temporarily unavailable)"，这是资源未对齐的直接信号