核心是分层控制缓冲区：client_header_buffer_size设2k配4 8k，client_max_body_size按接口设于location内，小请求走内存、大请求早落盘或拦截，前置卡住准入上限。
在 server 块中配置缓冲区，核心不是堆大内存，而是按请求特征分层控制：把请求头、请求体、响应头、响应体的缓冲分开设限，避免单个连接无节制吃掉 worker 内存。重点是让小请求走内存、大请求早落盘或直接拦截，而不是靠增大缓冲硬扛。
控制请求头和请求体的准入上限
这是最前置的防线，必须在解析阶段就卡住，不进内存处理流程：
-
client_header_buffer_size 设为
2k，搭配 large_client_header_buffers4 8k（总上限 32KB），足够承载 JWT、多域名 Cookie 和 traceparent 等现代头部字段，又不会为每个连接预占过多 RSS 内存 -
client_max_body_size 按接口实际需要设，比如上传接口写
200M，API 接口保持默认1m或设为10m；务必放在 location 块里实现接口级控制，避免全局宽松 -
client_body_buffer_size 设为
4k或8k：小请求全程走内存，超限自动落盘；不建议设成 64k 以上，否则每个连接都预分配大量内存，高并发时极易 OOM
收紧连接生命周期与超时行为
慢速攻击不靠体积，靠拖时间长期占着连接和缓冲资源，超时设置不当会让内存“只进不出”：
-
client_header_timeout 和 client_body_timeout 均设为
10s：从收到 header 开始计时，中间断连即释放全部缓冲 - 反向代理场景下，在对应 location 中显式关闭二次缓存：
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、fastcgi 等缓冲若配置失当，在高并发下会成倍放大内存消耗：
-
gzip_buffers 改为
16 8k（共 128KB），比默认32 4k更适配中小响应；同时加gzip_min_length 1024，跳过极小响应的压缩开销 -
proxy_buffer_size 设为
32k～64k，专门应对大响应头（如含大量 Set-Cookie 或自定义 Header）；注意它不能超过单块proxy_buffers的大小 -
proxy_buffers 按业务 P95 响应体大小设，普通页面用
16 256k（共 4MB），导出接口可用8 512k（共 4MB），配套proxy_busy_buffers_size 2m，且必须 ≤ 总 buffer 容量
系统级兜底与路径隔离
再精细的配置也需系统层配合，否则缓冲参数只是纸面限制：
- 将
client_body_temp_path、proxy_temp_path指向 SSD 分区或内存盘（如/dev/shm/nginx_temp），避开系统盘和机械盘，降低落盘延迟与 I/O 风险 -
proxy_max_temp_file_size 设为
1024m～2048m，允许合理落盘，但不建议设为 0（禁用磁盘缓存），否则可能直接返回 502 - 确认内核参数
net.core.somaxconn和net.ipv4.tcp_max_syn_backlog≥65535，避免连接队列溢出导致连接被丢弃、重试放大内存压力
