必须在 http 块中全局配置 gzip，精准设置 gzip_types、gzip_min_length 1024、gzip_comp_level 6，并验证 content-encoding: gzip 响应头生效。
开启 gzip on 本身只是启用压缩功能的第一步，真正实现“动态文本压缩、削减带宽、加速首屏渲染”，需要在 Nginx 中完成一整套合理配置，而非仅写一行指令。关键在于：选对作用域、设好阈值、限定类型、兼顾兼容性，并验证生效。
必须放在 http 块中，不能只写在 server 或 location 里
Nginx 的 gzip on 指令作用域为 http、server、location，但生产环境强烈建议只在 http { } 块内全局启用。这样所有 server 块自动继承，避免遗漏子站点；也防止因 location 匹配顺序导致部分资源未压缩（比如 /api/ 下的 JSON 接口）。
错误示例（无效或不可靠）：
-
location / { gzip on; }—— 可能被其他 location 覆盖，且不作用于静态文件服务路径 -
server { gzip on; }—— 若有多个 server，需重复配置，易出错
正确位置：打开 /etc/nginx/nginx.conf，在 http { 开头后、include /etc/nginx/conf.d/*.conf; 前插入完整 gzip 配置段。
压缩哪些内容？精准指定 gzip_types 是提速核心
默认只压缩 text/html，其余如 JS、CSS、JSON、SVG、Web 字体等必须手动加入 gzip_types，否则浏览器收到的是原始体积——这是“开了 gzip 却没效果”的最常见原因。
推荐配置（覆盖主流前端资源）：
text/plain text/css text/javascript application/javascript application/json application/xml application/rss+xmlimage/svg+xml font/ttf font/otf font/eot application/wasmapplication/ld+json application/geo+json text/vtt
⚠️ 注意：不要对 image/jpeg、image/png 等二进制图片加压缩——它们已是高压缩格式，再 gzip 可能增大体积或毫无收益。
控制开销与收益平衡：min_length 和 comp_level 得当才真快
小文件压缩反而拖慢响应：1KB 以下的 HTML 片段、空响应、短 JSON，压缩后可能比原大小还大，且白白消耗 CPU。
-
gzip_min_length 1024;—— 明确跳过小于 1KB 的响应（Nginx 默认是 20 字节，必须改） -
gzip_comp_level 6;—— 级别 6 是当前（2026年）CPU 利用率与压缩率的最佳交点；设为 9 虽然体积略小，但首屏 TTFB 可能延迟 5–15ms，得不偿失 -
gzip_buffers 16 8k;—— 提供充足缓冲，避免频繁内存分配影响并发性能
验证是否真生效？用 curl 或浏览器 Network 看响应头
配置保存后执行 nginx -t && nginx -s reload，然后立即验证：
- 终端命令：
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/main.js，检查返回头中是否有Content-Encoding: gzip - 浏览器开发者工具 → Network → 刷新页面 → 点击任意 JS/CSS/HTML 请求 → Response Headers → 查找
Content-Encoding字段 - 对比压缩前后大小：Response 栏中的 “Size”（传输体积）应明显小于 “Content”（原始体积），差值即压缩收益
若未生效，优先排查：配置是否写在 http 块内、gzip_types 是否漏掉关键类型、CDN 是否覆盖了源站响应头、是否启用了 proxy_buffering 导致 gzip 被绕过。
