nginx gzip 不生效需排查配置加载、请求条件、mime 类型、gzip_static 干扰及响应头验证：先 nginx -t 与 reload 确保配置生效；再用 curl 检查 accept-encoding、content-encoding、vary、content-type 和 content-length 是否符合预期。
排查 Nginx Gzip 配置不生效，核心是确认“请求—压缩—响应”整条链路是否完整打通。问题往往不出在 gzip 指令本身，而在于上下文、条件匹配或中间环节干扰。
检查配置是否真正加载生效
Nginx 不会自动重载配置，改完必须手动验证：
- 运行
nginx -t确认语法无误，避免因拼写错误（如gizp on）导致静默失效 - 执行
nginx -s reload重新加载，不能只改文件不 reload - 确认配置位置合理：若在
http块启用gzip on，但某个location块里写了gzip off，则该路径下压缩被关闭
验证客户端请求是否触发压缩条件
服务端压缩只对符合条件的请求响应，缺一不可：
- 用
curl -I -H "Accept-Encoding: gzip" http://host/test.js模拟支持 gzip 的客户端，再对比不带该头的请求，看Content-Encoding: gzip是否只在前者出现 - 检查响应体大小是否低于
gzip_min_length（默认 20 字节），小文件会被跳过；可临时设为gzip_min_length 1测试 - 确认请求资源的 MIME 类型在
gzip_types列表中，例如返回application/json却没配application/json，就不会压缩
排除 gzip_static 与常规 gzip 的混淆干扰
如果同时启用了 gzip_static on 和 gzip on，行为逻辑不同，容易误判：
-
gzip_static是“找 .gz 文件硬匹配”，不生成、不压缩，只返回已存在的index.html.gz；若文件不存在，且gzip off，就可能返回空或 404 - 用
curl -I http://host/index.html查响应头：有Content-Encoding: gzip但没Vary: Accept-Encoding，大概率是gzip_static在工作（它不自动加 Vary） - 想让
gzip_static生效，必须确保.gz文件真实存在、权限可读，且gzip_static on写在能覆盖该资源的location块内
抓关键响应头交叉比对
浏览器开发者工具 Network 面板看到的只是最终结果，需用命令行精准比对：
- 执行
curl -I http://host/style.css，确认返回头含Content-Encoding: gzip和Vary: Accept-Encoding - 对比同一资源的未压缩请求（如禁用 gzip 的 curl 或删掉 Accept-Encoding 头），看
Content-Type是否一致——乱码常因gzip_static返回时Content-Type变成text/plain导致 - 检查
Content-Length：若值明显偏小，或实际响应字节数（curl -s | wc -c）与原始 .gz 文件大小不等，说明响应被截断，可能是proxy_buffering off或缓冲区不足
