宝塔面板启用gzip但未生效，常见原因有三：一是gzip on被重复定义导致冲突；二是gzip_types未包含请求资源的mime类型；三是配置位置错误，未置于server块内。
宝塔面板点启用但没生效，curl -I 看不到 Vary: Accept-Encoding
说明 Gzip 实际没跑起来，不是前端没触发，而是 Nginx 根本没执行压缩逻辑。常见原因有三个：一是站点配置里 gzip on 被重复定义且被覆盖（比如全局开了，站点又关了）；二是 gzip_types 没包含你请求的资源类型（比如你测的是 .svg，但配置里没写 image/svg+xml）；三是配置位置错了——必须放在 server { } 块内，不能塞在 location 里，否则不继承。
实操建议：
- 用宝塔【网站】→【配置文件】打开该站点配置，搜索
gzip，确认只有一处gzip on，且没被#注释 - 检查
gzip_types行是否包含你实际请求的 MIME 类型，比如application/javascript（不是text/javascript，后者已过时） - 确认整段 gzip 配置在
server {和最后一个}之间，不在任何location或if块内部 - 改完后务必点【保存】→【重载配置】，不要只点保存就以为生效
手动加了 gzip on 却报 nginx: [emerg] "gzip" directive is duplicate
这是 Nginx 启动时校验失败的典型错误，意味着你在多个地方写了 gzip on。宝塔默认会在全局 /etc/nginx/nginx.conf 的 http 块里启用一次，如果你又在某个站点的 server 块里再写一遍，就会冲突。
实操建议：
- 先查全局配置：
grep -n "gzip on" /etc/nginx/nginx.conf，看是否已存在 - 如果全局已开，站点配置里就**不要重复写
gzip on**，只保留gzip_types、gzip_comp_level等可覆盖的指令即可 - 如果想统一控制，直接去【软件商店】→【Nginx】→【设置】→【性能调整】调
gzip_comp_level，别碰配置文件 - 改完用
nginx -t手动验证语法，比等宝塔报错快得多
启用了 Gzip，但 JS/CSS 文件还是没压缩（Content-Encoding: gzip 缺失）
最常被忽略的其实是 gzip_min_length。默认值是 20，单位是字节——也就是说，小于 20 字节的响应不压缩。而很多现代构建工具生成的 inline script 或小 CSS 片段，体积远低于这个阈值。
实操建议：
- 把
gzip_min_length改成1k（即 1024 字节），这是生产环境通用安全值 - 确认你测试的文件真实大小：用
curl -s http://yoursite.com/app.js | wc -c看字节数 - 注意浏览器 DevTools 的 Network 面板有时会缓存未压缩版本，强制刷新（Ctrl+Shift+R）或禁用缓存再测
- 如果用了 CDN（如 Cloudflare），它可能覆盖了源站的
Vary头，需在 CDN 后台单独开启压缩
为什么加了 gzip_vary on 还是被 CDN 或代理缓存错？
gzip_vary on 的作用是让 Nginx 返回 Vary: Accept-Encoding 响应头，告诉中间缓存“这个资源有压缩/未压缩两个版本，请按请求头里的 Accept-Encoding 分别缓存”。但它本身不保证缓存行为，只提供依据。
实操建议：
- 确认代理层（CDN、WAF、反向代理）确实识别并尊重
Vary头；Cloudflare 默认支持，但部分企业级 WAF 需手动开启 Vary 感知 - 避免在
gzip_vary on之外又加add_header Vary "Accept-Encoding"，重复会导致响应头异常 - 如果用了多层代理，检查每一层是否剥离或覆盖了
Vary，可用curl -I对比源站和 CDN 返回头差异
