worker_connections 本身不直接导致 OOM，但配置过高且未同步限制缓冲区、日志、缓存等资源时，易引发内存溢出；低配机建议设为 512 并关闭非必要模块，高配机需系统级与 Nginx 参数对齐，反向代理场景应按内存估算连接数。
worker_connections 本身不直接导致内存溢出（OOM），但它和系统资源、Nginx 进程行为强相关。配置不当会加剧内存压力，尤其在低配机器或反向代理场景下——连接数设得过高，而系统文件描述符、缓冲区、日志、缓存等没同步收紧，就容易触发 OOM Killer 杀掉 worker 进程。
明确内存消耗的主要来源
Nginx 内存占用不是由 worker_connections 单独决定的，而是多个模块叠加的结果：
- 每个连接的基础开销：HTTP/1.1 空闲 keepalive 连接约占用 20–40 KB 内存；启用 SSL 后升至 50–100 KB；若开启 gzip、proxy_buffering 或 upstream keepalive，单连接可能突破 150 KB
- 缓冲区放大效应：proxy_buffers × proxy_busy_buffers_size × 并发连接数，极易吃光内存。例如默认 proxy_buffers 8 4k，busy_buffers_size 8k，1000 连接就占 16 MB 缓冲区
- 日志与缓存：access_log 开启且未异步写入时，高并发下日志缓冲堆积；open_file_cache 在大量静态文件场景下也会显著增重
- worker 进程数量：worker_processes 越多，进程自身开销（如共享内存、锁结构）越明显，1GB 内存 VPS 建议固定为 1
低配机型（如 1 核 1GB）的安全配置法
目标是让单个 worker 进程稳定控制在 ≤60 MB（HTTP）或 ≤100 MB（HTTPS），避免触发 OOM：
- worker_processes 1（禁用 auto，防止容器或云主机误判为多核）
- worker_connections 512（足够支撑 300–400 实际并发请求，留出余量给上游连接和日志 fd）
- 关闭非必要模块：access_log off;、gzip_static off;、open_file_cache off;
- 大幅缩减缓冲区：client_body_buffer_size 1k;、proxy_buffering off;（反向代理时）、large_client_header_buffers 2 1k;
- keepalive_timeout 设为 15s 或更低，避免长连接空占内存
中高配环境（4 核+、4GB+内存）的稳健调优路径
重点不是堆高数字，而是让各层限制对齐、不留短板：
- 先调系统级限制：ulimit -n 65536（永久写入 /etc/security/limits.conf，用户为 nginx 或 www-data）
- 在 nginx.conf 主块声明：worker_rlimit_nofile 65536;（必须 ≥ worker_processes × worker_connections）
- events 块内：worker_connections 8192; + use epoll; + multi_accept on;
- 配套收紧内存敏感项：proxy_buffering off;（若后端稳定）、client_max_body_size 2m;、reset_timedout_connection on;
- 用 stub_status 和 /proc/$(pgrep nginx)/status 实时观察 VmRSS 值，压测时单 worker 控制在 300 MB 以内较安全
反向代理场景下的连接数预估公式
不同于纯静态服务，反向代理每路客户端请求会额外消耗至少 1 个上游连接 + 若干缓冲区。经验公式如下：
- 实际可用并发 ≈ (worker_connections − 2 × worker_processes − 4) ÷ 2（适用于短连接、无 keepalive 的压测场景）
- 更稳妥的做法是：worker_connections ≤ (总内存 MB × 0.6) ÷ 0.15（按单连接平均 150 KB 估算）
- 例如：2GB 内存机器，预留 512 MB 给系统和其他进程，剩余 1500 MB × 0.6 = 900 MB 可用于连接 → 900 × 1024 ÷ 150 ≈ 6144，取整设为 4096 更稳妥
