Nginx无传统缓冲区溢出漏洞，所谓内存溢出实为恶意或异常请求导致worker进程内存持续增长、被OOM Killer杀掉或服务中断；防范需从请求准入、内存分配、连接生命周期、系统资源边界四层协同控制，包括精准限制请求体与头大小、收紧超时与连接行为、优化压缩与缓冲内存分配、系统级兜底与可观测性。
精准限制请求体与头大小
这是第一道防线，必须在解析阶段就拦截，避免进入内存处理流程：
-
client_max_body_size：按业务设合理上限（如
50M或200M），放在location块中实现接口级控制；设为0等于关闭防护，不推荐 -
client_header_buffer_size 和 large_client_header_buffers：常规场景建议
client_header_buffer_size 2k;+large_client_header_buffers 4 8k;（总上限 32KB），足够容纳 JWT Token、多域名 Cookie 和分布式追踪头（如traceparent） -
client_body_buffer_size：设为
2k–8k，小请求走内存，超限自动落盘；避免设过大（如 64k）导致每个连接预占过多 RSS 内存
收紧超时与连接行为
慢速攻击（Slowloris 类）不靠体积，而靠“拖时间”长期占用连接和缓冲资源：
-
client_header_timeout 和 client_body_timeout 均建议设为
10s或更低，从收到 header 开始计时，中断即断连 - 反向代理场景下，显式关闭二次缓存：
proxy_buffering off;+proxy_request_buffering off;（Nginx 1.16+），防止 body 被代理层重复读取、放大内存压力 - 上游服务必须启用
keepalive：upstream backend { keepalive 200; }，并配套proxy_http_version 1.1;和proxy_set_header Connection '';，复用连接，避免 socket 缓冲 + proxy buffer 双重开销
优化压缩与缓冲内存分配
Gzip、proxy、open file 等缓冲若配置失当，在高并发下会成倍放大内存消耗：
-
gzip_buffers：避免默认
32 4k（128KB/连接）。中小响应为主时，改用gzip_buffers 16 8k；同时设gzip_min_length 1024，跳过极小响应的压缩开销 -
open_file_cache：静态资源多的场景，设
open_file_cache inactive=30s;+open_file_cache_errors on;，加快失效句柄释放，避免 fd 泄漏拖累内存 -
worker_connections：64 核机器不必配满。推荐
worker_processes 12;+worker_connections 32768;（约 39 万连接），平衡上下文切换与单连接内存占用（每连接约 30–50KB）
系统级兜底与可观测性
再好的配置也需系统层配合，否则资源耗尽仍会崩溃：
- 检查并提升 open files 限制：
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"，确保不低于 65536 - 调大内核参数：
fs.file-max = 2097152、net.core.somaxconn = 65535，防止连接队列溢出 - 定期用
ps -o pid,vsz,rss,comm -C nginx观察 worker RSS 是否持续上涨；结合free -h和cat /proc/sys/fs/file-nr判断是内存还是句柄瓶颈 - 全局关闭非必要日志：
access_log off;+log_not_found off;，仅关键路径单独开启
