宝塔面板中启用nginx gzip需手动修改nginx.conf：在http块中配置gzip on、min_length 1024、comp_level 6、types含application/json等、gzip_vary on，并检查站点配置和cdn干扰。
宝塔面板里改 Nginx 的 gzip 配置，别只点“启用”就完事
单纯在「软件商店 → Nginx → 设置 → 网站压缩」里勾选“开启 Gzip”，只能启用默认压缩（gzip_comp_level 1），对 HTML/JS/CSS 压缩效果弱，且默认不压缩动态响应（如 PHP 输出的页面）。真要压得实、传得快，得手动调参数。
直接改 Nginx 主配置文件，绕过宝塔界面限制
宝塔的“网站压缩”开关只控制基础开关和静态资源压缩，gzip_vary、gzip_min_length、动态 MIME 类型支持等关键项必须进配置文件改。路径是：/www/server/nginx/conf/nginx.conf，在 http 块内添加或修改以下内容：
gzip on; gzip_min_length 1024; gzip_buffers 4 16k; gzip_comp_level 6; gzip_types text/plain text/css text/javascript application/javascript application/json application/x-javascript application/xml application/xhtml+xml application/rss+xml application/atom+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype font/truetype image/svg+xml image/x-icon; gzip_vary on; gzip_disable "MSIE [1-6]\."; # 兼容老 IE，可保留
-
gzip_comp_level 6是平衡速度与压缩率的推荐值（1–9），设太高（如 9）会明显增加 CPU 负担，尤其高并发时 -
gzip_types必须显式加上application/json和application/javascript，否则 PHP/AJAX 返回的 JSON 或动态 JS 不会被压缩 -
gzip_min_length 1024防止小文件（如空响应、小图标）被强行压缩反而变大，但别设成 0 —— Nginx 对小于 1024 字节的响应默认不压
确认 PHP 动态内容真被压缩了，别被缓存骗了
改完配置后重载 Nginx（bt 1 或面板点“重载配置”），但浏览器开发者工具的 Network 面板看到 Content-Encoding: gzip 不一定代表 PHP 输出被压了——可能只是静态资源或 Nginx 缓存层在起作用。
- 用
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/api/test.php直接测接口，看响应头是否含Content-Encoding: gzip - 确保 PHP 没关 zlib：检查
php.ini中zlib.output_compression = Off（宝塔默认关），否则 PHP 层和 Nginx 层双重压缩会出错或失效 - 如果用了宝塔的「网站缓存」或「静态文件缓存」，先临时关闭，避免缓存响应掩盖真实压缩状态
常见踩坑：改了没生效？先查这三处
很多人改完配置 reload 了，但 curl 测还是没 gzip 头，问题往往不在 Nginx 本身：
- 站点配置里写了
gzip off;—— 宝塔每个网站的配置文件（/www/server/panel/vhost/nginx/xxx.conf）可能单独关掉了 gzip，优先级高于主配置，得搜一遍删掉 - HTTPS 站点没配
gzip_vary on，某些代理或 CDN 会缓存未压缩版本，导致后续请求拿不到压缩响应 - 用了 Cloudflare 或其他 CDN，它可能覆盖了源站的
Content-Encoding头，此时要在 CDN 后台开启“Brotli/Gzip 压缩”，而非只靠源站
动态压缩等级提升不是加个数字就完事，关键是让所有响应路径都经过同一套 gzip 规则，而宝塔的图形化开关只管表层。最稳的方式，是把压缩逻辑收归到 nginx.conf 的 http 块，再逐个排除站点级覆盖和中间层干扰。
