最可靠的方式是检查响应头中的 Content-Encoding: gzip。用 curl -H "Accept-Encoding: gzip" -I https://your-domain.com/style.css 查看是否返回 Content-Encoding: gzip、Vary: Accept-Encoding 及 Content-Length 明显减小；浏览器中通过 F12 → Network → Headers 确认 Response Headers 含 Content-Encoding: gzip。
直接检查响应头中的 Content-Encoding: gzip 是最可靠的方式。只要这个字段存在，就说明 Nginx 已成功对当前响应启用压缩。
用 curl 命令快速验证
在服务器或本地终端执行：
curl -H "Accept-Encoding: gzip" -I https://your-domain.com/style.css
观察返回的响应头，重点确认以下三点：
- Content-Encoding: gzip —— 必须出现，表示已压缩
- Vary: Accept-Encoding —— 应存在，确保 CDN 或代理能正确缓存不同编码版本
-
Content-Length 值明显小于未压缩时的大小（可对比不带
-H "Accept-Encoding: gzip"的请求）
注意：必须带上 -H "Accept-Encoding: gzip"，否则服务端不会触发压缩逻辑。
通过浏览器开发者工具验证
打开网站后按 F12 → Network → 刷新页面 → 点击任意 JS/CSS/HTML 请求，在右侧 Headers 标签页中查找：
-
Response Headers 区域是否有
Content-Encoding: gzip - 同时确认该资源的 MIME 类型确实在 Nginx 的
gzip_types列表中（例如text/css、application/javascript），否则即使配置了gzip on也不会压缩
检查是否被中间层干扰
如果本地 curl 或浏览器显示未压缩，但你确定配置无误，需排查以下常见干扰点：
- CDN 或反向代理（如 Cloudflare、Nginx 前置层）覆盖了压缩行为：它们可能提前解压再转发，导致后端 Nginx 的 gzip 失效；可在 CDN 后直连源站 IP 测试
-
PHP 或 FastCGI 输出已提前 flush：若 PHP 脚本调用了
ob_flush()或flush()，可能导致 gzip 无法生效 -
gzip_disable 规则匹配了当前 UA：比如配置了
gzip_disable "MSIE [1-6]\."，而测试环境恰好是旧版 IE
批量验证多个资源类型
避免只测单个文件，建议分别对以下典型资源发起带 gzip 请求：
- HTML 页面：
curl -H "Accept-Encoding: gzip" -I https://example.com/ - CSS 文件：
curl -H "Accept-Encoding: gzip" -I https://example.com/main.css - JS 文件：
curl -H "Accept-Encoding: gzip" -I https://example.com/app.js - JSON 接口：
curl -H "Accept-Encoding: gzip" -I https://example.com/api/data
每类都应返回 Content-Encoding: gzip，才能确认 gzip_types 配置完整且无遗漏。
