在nginx的server块中配置gzip压缩适用于多域名共用服务器且需差异化压缩策略的场景，必须置于server顶层、配合gzip_min_length 1024、gzip_comp_level 5或6、显式gzip_types（含application/x-httpd-php等）、gzip_vary on及gzip_http_version 1.1等关键参数，并避免对已压缩格式启用，验证需检查content-encoding: gzip响应头。
在 Nginx 的 server 块中配置 Gzip 压缩，适合需要为特定站点单独控制压缩行为的场景，比如多个域名共用一台服务器但压缩策略不同。它比全局配置更灵活，也更容易排查和维护。
必须放在 server 块顶层
所有 gzip 指令必须写在 server { } 块的最外层，不能嵌套在 location 或 if 内部，否则不会生效。尤其注意：如果该站点走 PHP（如 FastCGI），仅在 server 块里启用还不够——application/x-httpd-php 类型的响应需在 location ~ \.php$ 块内再显式声明一次 gzip on 和对应 gzip_types，否则 PHP 动态页面不会被压缩。
关键参数要写全
只写 gzip on; 是无效的。必须配合以下基础项：
-
gzip_min_length：建议设为
1024（1KB），避免压缩极小文本（如空响应、短 JSON）带来 CPU 开销反而得不偿失 -
gzip_comp_level：推荐
5或6，兼顾压缩率与响应速度；数值越高越耗 CPU -
gzip_types：必须显式列出类型，Nginx 默认只压
text/html。常见组合包括：text/plain text/css application/javascript application/json text/xml application/xml+rss image/svg+xml application/x-httpd-php - gzip_vary on：务必开启，否则 CDN 或反向代理可能缓存未压缩版本，导致部分用户看到乱码或空白页
避开常见错误
这些细节容易忽略，却直接导致压缩失效：
- 不要对
image/jpeg、image/png、font/woff2、application/pdf等本身已压缩格式启用 gzip——几乎不减体积，还浪费 CPU - 若使用反向代理（如前端有 CDN 或 Nginx 做负载均衡），可加
gzip_proxied any;，让代理返回的内容也被压缩 - 不要遗漏
gzip_http_version 1.1;，尤其在旧客户端兼容性要求不高时，能避免 HTTP/1.0 下压缩被忽略
验证是否生效
改完配置后执行 nginx -t 检查语法，再 nginx -s reload 生效。验证方式有两种：
- 浏览器打开开发者工具 → Network → 刷新页面 → 点击任意 HTML/JS/CSS 请求 → 查看 Response Headers 中是否有
Content-Encoding: gzip - 命令行执行：
curl -H "Accept-Encoding: gzip" -I https://your-domain.com/index.html，观察返回头是否含Content-Encoding: gzip
