开启Gzip压缩需先确认Nginx已编译支持gzip模块，再在http或server块中配置gzip on、gzip_vary on、gzip_min_length 1000、gzip_comp_level 4及显式gzip_types；排除图片等已压缩格式；最后用curl -H "Accept-Encoding: gzip" -I验证响应头。
开启 Gzip 压缩后，HTML、CSS、JS 等文本类静态资源体积通常能减少 60%–70%，但默认 Nginx 是关闭的，且直接启用可能触发 404 或 Content-Encoding 错误——关键不在“开不开”，而在“对谁开、怎么开、开完怎么验”。
确认 Nginx 已编译支持 gzip 模块
Nginx 必须包含 ngx_http_gzip_module（绝大多数预编译包都自带），但精简版或自编译未加 --with-http_gzip_module 的会缺失。运行以下命令验证：
nginx -V 2>&1 | grep -o with-http_gzip_module
若无输出，说明模块未启用，需重装或重编译。别跳过这步——很多“配置写了不生效”的问题根源在此。
在 http 或 server 块中配置 gzip 参数
压缩行为由一组联动参数控制，仅写 gzip on 不够，常见疏漏点如下：
-
gzip_types必须显式列出要压缩的 MIME 类型；Nginx 默认只压text/html，.css、.js、.json都不会被处理 -
gzip_vary on必须开启，否则 CDN 或代理可能缓存未压缩版本，导致部分用户看到乱码 -
gzip_min_length 1000推荐设为 1000 字节以上再压缩，避免小文件因压缩头开销反而变大 -
gzip_comp_level 4是较优平衡点；设为9会显著增加 CPU 负载，但体积节省不足 5%
推荐最小可用配置示例：
gzip on;<br>gzip_vary on;<br>gzip_min_length 1000;<br>gzip_comp_level 4;<br>gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
排除不适宜压缩的资源类型
不是所有资源都适合 Gzip：已压缩格式（如 .jpg、.png、.webp）再压无效，甚至可能略增体积；某些老旧客户端（如 IE6）对压缩响应处理异常。因此：
- 用
gzip_disable "msie6"屏蔽 IE6（如仍需兼容） - 避免在
gzip_types中加入image/.*或application/octet-stream - 若使用了 Brotli（
ngx_brotli），注意它和 Gzip 不互斥，但需独立配置，且优先级由客户端Accept-Encoding决定
验证压缩是否真实生效
浏览器开发者工具的 Network 面板容易误判：它显示的 Content-Encoding: gzip 可能来自上游 CDN 或反向代理，而非本机 Nginx。可靠验证方式是直接请求并检查响应头：
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/style.css
若返回中含 Content-Encoding: gzip 且 Content-Length 明显小于原始文件大小，才算真正生效。另外注意：curl 默认不自动解压，加 -H "Accept-Encoding: gzip" 才触发服务端压缩逻辑。
最易被忽略的是：修改配置后必须 nginx -t && nginx -s reload，而不仅仅是重启；且部分系统（如 Ubuntu + systemd）的 nginx.service 可能屏蔽了重载信号，得手动发 SIGHUP。
