在nginx的server块中配置gzip适合多域名共用服务器且需差异化压缩策略的场景，必须置于server顶层、显式包含application/x-httpd-php类型、在location ~ .php$内重复启用gzip on，并配合gzip_min_length 1024、gzip_comp_level 5、gzip_vary on及gzip_http_version 1.1等关键参数，避免压缩已压缩格式，验证需检查content-encoding: gzip响应头。
在 Server 块中配置 gzip，适合多站点环境下的精细化控制——既能避免全局影响，又能针对特定域名或应用（比如 PHP 项目）定制压缩策略。关键不是“堆参数”，而是让每条指令都精准生效。
必须写在 server 块顶层，且包含 PHP 响应支持
很多配置失效，是因为把 gzip on 和 gzip_types 错误地放在了 location 里，或者漏掉了 PHP 类型。Server 块内启用 gzip 的前提条件是：
- 所有 gzip 指令必须写在
server { }的最外层（即 location 之前） -
gzip_types必须显式包含application/x-httpd-php，否则 PHP 动态页面不会被压缩 - 若站点使用 fastcgi（绝大多数 PHP 环境），还需在
location ~ \.php$块内再写一次gzip on，否则 FastCGI 返回的响应可能绕过压缩
推荐压缩参数组合（兼顾速度与体积）
不盲目设 gzip_comp_level 9——它对 CPU 消耗显著上升，但体积收益已趋平缓。更实用的配置如下：
gzip on;-
gzip_min_length 1024;—— 小于 1KB 的响应跳过压缩（如小图标、空响应） -
gzip_comp_level 5;—— 平衡点：比 level 1 多压 20%~30%，CPU 开销仅略增 gzip_types text/html text/css application/javascript application/json text/xml application/xml+rss image/svg+xml application/x-httpd-php;-
gzip_vary on;—— 防止 CDN 或代理缓存混淆编码方式 -
gzip_http_version 1.1;—— 明确要求 HTTP/1.1，兼容性更稳
务必避开两类典型错误
Server 块配置最容易栽在这两个坑里：
-
误压已压缩格式：不要在
gzip_types中加入image/jpeg、image/png、font/woff2或application/pdf——它们本身已是高压缩率格式，gzip 不仅几乎不减体积，反而增加 CPU 负担 -
忽略语法校验直接 reload：修改后必须先运行
nginx -t；失败时常见原因是gzip_types行末尾少了分号，或 MIME 类型拼写错误（如text/javascrip少了个 t）
验证是否真正生效
别只看配置写了没，要确认浏览器实际收到的是压缩响应：
- 用 curl 测试：
curl -H "Accept-Encoding: gzip" -I https://your-domain.com/index.php - 检查响应头是否含
Content-Encoding: gzip和Vary: Accept-Encoding - 对比压缩前后大小：
curl -H "Accept-Encoding: gzip" -s https://your-domain.com/app.js | wc -cvscurl -H "Accept-Encoding:" -s https://your-domain.com/app.js | wc -c
