worker_connections 过大本身不直接导致内存溢出，但会放大单 worker 内存基线；真正风险在于其与过大 buffer、冗余缓存等配置叠加，在高并发时突破内存极限。
worker_connections 配置过大本身不会直接“引发”内存溢出，但它会显著放大每个 worker 进程的内存基线——因为 Nginx 为每个连接预分配缓冲区（如 client_header_buffer、proxy_buffer 等），配置值越高，潜在内存占用上限就越高。真正的问题是：配置远超实际负载需求，又叠加了不合理的 buffer 参数或缓存设置，导致单 worker RSS 在高并发时突破系统承受极限。排查关键不是看“设了多少”，而是验证“用了多少”和“为什么用这么多”。
看 error.log 是否有连接拒绝但无资源耗尽迹象
如果 worker_connections 设得极大（比如 65536+），但 error.log 中频繁出现：
- accept() failed (11: Resource temporarily unavailable) —— 表明内核连接队列已满，新连接被丢弃，但 worker 自身并未满；
- 却没有 “too many open files” 或 “out of memory” 类错误；
- 同时 stub_status 显示 Active connections 长期低于配置值的 30%，Waiting 值也极低。
这就提示：连接能力严重过剩，而内存压力可能来自其他地方（比如每个连接分配的缓冲区总和过大），而非连接数本身不足。
查单 worker 实际 RSS 与理论内存占用是否严重偏离
执行命令定位最高 RSS 的 worker：
ps -o pid,rss,comm -p $(pgrep -P $(pgrep nginx)) | sort -k2 -nr | head -3
再估算理论最小内存消耗：
- 按当前活跃连接数 × 每连接平均缓冲开销（约 0.4–0.5 KB）；
- 若某 worker RSS 达到 1.2 GB，但 active connections 仅 8000，说明每连接均摊内存高达 150 KB+，明显异常；
- 此时重点检查：client_body_buffer_size（上传体）、large_client_header_buffers（请求头）、proxy_buffers（后端响应）是否被设为 128k/16 甚至更大。
核对 buffer 配置与业务请求特征是否错配
大 worker_connections 常见于长连接场景（如 WebSocket、SSE），但这类连接多数时间空闲，不发数据。如果仍沿用面向短连接 HTTP 的 buffer 配置，就会造成巨大浪费：
- 例如：设 client_body_buffer_size 16m，而 95% 请求 body
- 又如：proxy_buffers 16 128k → 单连接最多占 2MB，百万连接理论需 2TB 内存；
- 建议策略：长连接场景下，关闭 proxy_buffering 或大幅调小 proxy_buffer_size（如 4k），并确保 client_max_body_size 合理限制上传。
检查 open_file_cache 和 ssl_session_cache 是否过度缓存
worker_connections 大时，配套缓存若未收缩，会成倍放大句柄与内存占用：
- open_file_cache max=10000 inactive=300s：在短生命周期静态请求多的场景下，300 秒太长，缓存条目堆积 → 句柄不释放 → 触发 “Too many open files”；
- ssl_session_cache shared:SSL:20m：若实际每秒新建会话仅 100 个，20MB 可缓存约 4 万个会话，远超需要，且共享内存段长期驻留；
- 优化方向：inactive 缩至 20–60s；ssl_session_cache 改为 shared:SSL:4m（约 8000 会话），并开启 ssl_session_cache_timeout 300s 控制单条有效期。
