排查Nginx Gzip是否生效需验证三件事：配置已加载（nginx -V确认模块存在、nginx -t检查语法）、响应头正确（Content-Encoding: gzip与Vary: Accept-Encoding同时存在）、压缩体真实变小（curl对比gzip/identity请求的字节数）。
排查 Nginx Gzip 压缩是否生效，核心是验证三件事：配置已加载、响应头正确、压缩体真实变小。不需要复杂工具，用好系统自带命令和浏览器就能快速定位问题。
确认 Nginx 是否真正启用了 gzip 模块
很多“配置写了却没效果”的问题，根源是模块根本不存在。必须先验证：
- 运行 nginx -V 2>&1 | grep with-http_gzip_module —— 若无输出，说明编译时没带该模块，改配置也没用，必须重编译并加 --with-http_gzip_module
- 若输出正常，再执行 nginx -t 确认语法无误；失败则说明配置写在了错误作用域（比如放在 location 里却没在 http 块开启基础支持）
- 注意：Ubuntu/Debian 的 apt 包通常自带模块，但 Alpine 或某些精简 Docker 镜像常默认不启用
检查响应头与实际压缩结果
光看配置不够，要抓真实 HTTP 流量：
- 用 curl -I -H "Accept-Encoding: gzip" https://yoursite.com/test.js 查看响应头：必须同时存在 Content-Encoding: gzip 和 Vary: Accept-Encoding
- 对比压缩前后体积：curl -H "Accept-Encoding: gzip" https://yoursite.com/app.js | wc -c vs curl -H "Accept-Encoding: identity" https://yoursite.com/app.js | wc -c —— 差值应明显（文本类资源通常减 60%+）
- 浏览器开发者工具 Network 标签页中，选中某个 JS/CSS 请求，看 Headers → Response Headers 里是否有 content-encoding: gzip，Preview 或 Response 标签页应显示乱码（说明是二进制压缩流）
常见失效原因与对应验证点
不是所有“没压缩”都是配置错，得逐层排除：
- gzip_types 漏类型：Nginx 默认只压 text/html。JSON 接口返回 404 或体积没变？检查是否漏加 application/json；SVG 图标没压缩？确认加了 image/svg+xml
- gzip_min_length 设太小或太大：设为 100 字节时，一个 {"ok":true}（约 14 字节）不会被压，但设成 0 反而可能因 gzip header 开销（20–30 字节）让响应更大。推荐从 1024 起步
- 后端提前输出或禁用压缩：PHP 中用了 ob_flush()、FastCGI 中设置了 fastcgi_buffering off，或应用层自己加了 Content-Encoding 头，都会导致 Nginx 跳过压缩
- CDN 或反向代理拦截：如果前面有 Cloudflare、Nginx 代理层或 Kubernetes Ingress，它们可能覆盖了 Vary 头或自行处理压缩，需逐级检查各层响应头
Gzip 与 Brotli 的效果实测对比方式
想量化 Brotli 是否值得上？别只看理论数字，做两组平行测试：
- 对同一份 JS 文件（如 vendor.abc123.js），分别用 gzip -k -9 和 brotili -Z -q 11 预压缩，对比生成文件大小：Brotli 通常再小 15%–20%
- 在 Nginx 中同时配置 gzip_static on 和 brotli_static on，用 curl 分别请求 Accept-Encoding: gzip 和 br，记录响应时间与 body size
- 重点看 CPU：用 top 或 pidstat -u 1 监控 nginx worker 进程，在高并发静态资源请求下，Brotli 预压缩几乎不耗 CPU，而实时 gzip 级别 6 以上会明显抬升负载
