Nginx Gzip模块无内存阈值判断，“内存不足失效”实为系统资源瓶颈、缓冲区配置不当或响应流截断所致；需先验证压缩是否真正触发（检查Accept-Encoding/Content-Encoding/Vary等响应头），再排查系统内存、worker进程OOM、gzip_buffers/proxy_buffering配置及gzip_static干扰。
Nginx 的 Gzip 模块本身不会因“内存不足”而主动停止压缩，它没有运行时内存阈值判断逻辑。所谓“Gzip 因内存不足失效”，实际是压缩过程被中断或跳过，根源在系统级资源瓶颈、缓冲区配置不当或响应流被截断，而非 Gzip 模块报错退出。
确认是否真有压缩行为被跳过
先排除误判：Gzip 不生效 ≠ 内存不足。多数情况是条件不满足导致根本没进入压缩流程：
- 用 curl -I -H "Accept-Encoding: gzip" http://host/test.js 检查响应头是否有 Content-Encoding: gzip 和 Vary: Accept-Encoding
- 对比同一请求去掉 Accept-Encoding 头的结果，确认差异仅出现在带该头时
- 检查响应体大小是否低于 gzip_min_length（默认 20 字节），小响应默认不压；临时设为 gzip_min_length 1 测试可快速验证
- 确认资源 MIME 类型在 gzip_types 列表中，比如返回 application/json 却未配置该类型，就不会触发压缩
排查系统与 worker 级内存压力
当系统内存严重紧张或 Nginx worker 进程 RSS 持续飙升时，压缩可能因 malloc 失败而静默跳过，甚至导致 worker 崩溃：
- 执行 free -h 和 htop，观察可用内存是否长期低于 512MB，Swap 是否频繁使用
- 查看 Nginx 错误日志：grep -i "out of memory\|malloc failed" /var/log/nginx/error.log
- 检查 dmesg：dmesg -T | grep -i "nginx.*killed\|oom"，确认是否被 OOM Killer 终止
- 用 ps aux --sort=-%mem | head -10 查看 nginx worker 进程内存占用是否异常偏高（如单个 > 500MB）
检查缓冲区配置是否引发压缩中断
即使系统内存充足，Nginx 缓冲区过小或代理模式下 buffer 不足，也会导致 gzip 压缩流写入失败或截断，浏览器解压失败但无错误码：
- 确认 gzip_buffers 设置合理，例如 gzip_buffers 16 8k（避免单 buffer 太小无法容纳压缩后数据）
- 若启用了 proxy_buffering on，检查 proxy_buffers 和 proxy_buffer_size 是否足够承载压缩后的响应体
- 对大响应（如 >1MB 的 JSON 或 HTML），临时加大缓冲：proxy_buffering off 或增大 proxy_max_temp_file_size 防止落盘失败
- 用 curl -s http://host/large.json | wc -c 对比原始文件大小，若字节数明显偏少，说明响应被截断
验证 gzip_static 是否干扰判断
如果同时开启 gzip_static on 和 gzip on，容易混淆问题来源：gzip_static 不消耗 CPU 压缩，但要求 .gz 文件真实存在且可读；若文件缺失或权限不对，Nginx 可能回退到未压缩响应，看起来像“压缩失效”：
- 执行 ls -l /path/to/file.js.gz 确认文件存在、属主可读
- 用 curl -I http://host/file.js 观察响应头：有 Content-Encoding: gzip 但无 Vary: Accept-Encoding → 很可能是 gzip_static 在工作
- 临时注释掉 gzip_static on，只保留 gzip on，重新测试，隔离变量
