防止恶意大文件压缩耗尽内存的关键是合理配置Gzip缓冲：按响应大小分级设置gzip_buffers，严控后端响应源头，绑定压缩开关到内容特征，并通过监控与系统级限制实现兜底。
防止恶意大文件压缩耗尽内存，关键不是禁用压缩，而是让 Gzip 缓冲不被滥用——它只在响应满足条件时才分配，且每个连接独占一组缓冲。失控往往源于配置宽松、响应无约束、并发叠加。
收紧 gzip_buffers，按业务响应大小分级设值
默认 gzip_buffers 32 4k（共 128KB/连接）在高并发下极易雪崩。例如 1000 并发响应平均 80KB，仅压缩缓冲就吃掉约 128MB 内存。应根据真实响应分布调整：
- 中小响应为主（如 API 返回 ≤16KB 占比超 90%）：改用 gzip_buffers 16 8k，总容量仍为 128KB，但单缓冲更大、碎片更少、小响应开销更低
- 含报表或长列表的接口：可设 gzip_buffers 8 32k（共 256KB），但必须配合 gzip_min_length 4k，跳过极小响应（如 200 字节 JSON）的无效压缩
- 纯静态资源站（JS/CSS/HTML）：启用 gzip_static on，直接返回预压缩 .gz 文件，完全绕过运行时压缩内存分配
严控响应源头，从后端切断大输出
Gzip 缓冲只是“最后一环”，真正风险来自后端吐出无节制的大响应。Nginx 无法替应用做业务限流，但可设硬边界：
- 在 proxy_pass location 中加 proxy_buffering off，禁用 Nginx 缓存整个响应体，避免 body 缓冲 + gzip 缓冲双重占用
- 配 proxy_max_temp_file_size 0，强制超大响应直接失败（返回 502），而非写临时文件撑爆磁盘
- 对已知高风险路径（如 /export/csv、/report/pdf），用 limit_rate 512k + limit_rate_after 2m，前 2MB 不限速，之后限速，兼顾首屏体验与防拖库
绑定压缩开关到内容特征，拒绝无效压缩
不是所有响应都值得压缩，盲目开启反而放大内存压力：
- 只压缩真实受益类型：gzip_types application/json text/html text/css application/javascript，移除
application/octet-stream等二进制类型 - 用 gzip_vary on 配合 CDN 或代理，避免缓存污染导致重复压缩
- 对已压缩格式（.jpg/.png/.mp4/.zip）禁止再压：map $sent_http_content_type $do_gzip { ~image/ 0; ~video/ 0; default 1; }，再通过 gzip on 前加 gzip_disable "msie6"; 和该 map 变量控制
监控与兜底：让异常压缩行为可感知、可中断
配置生效后需验证是否真起作用：
- 用 nginx -t -v 检查配置加载内存增幅；用 pmap -x $(pgrep nginx) 查看 worker 进程 RSS 是否稳定
- 开启 error_log /var/log/nginx/error.log notice，关注 “gzip buffer too small” 或 “could not build the gzip hash table” 日志，这是缓冲不足或配置冲突信号
- 在系统层设 worker_rlimit_as 512m，限制单 worker 虚拟内存上限，防止异常响应触发 OOM Killer
