curl -i 默认不发送 accept-encoding: gzip，需手动添加该请求头才能触发服务器压缩并显示 content-encoding: gzip 等关键响应头，否则可能误判 gzip 配置失效。
直接用 curl -I 只能查看响应头，但默认不发送 Accept-Encoding: gzip，服务器通常因此不返回压缩内容，也就看不到 Content-Encoding: gzip 这类关键头——这正是 Gzip 配置看似“失效”的常见原因。
必须手动带上 Accept-Encoding 请求头
curl 默认不声明支持压缩，Nginx/Apache 等服务器会跳过压缩逻辑。要真实模拟浏览器行为，需显式添加请求头：
curl -I -H "Accept-Encoding: gzip" https://example.com- 若想同时看是否启用 Brotli，可加：
-H "Accept-Encoding: gzip, br" - 注意：-I（HEAD 方法）虽快，但部分服务器对 HEAD 不压缩；如仍无
Content-Encoding，改用-s -o /dev/null -D -发送 GET 并只输出响应头
重点检查的响应头字段
成功启用 Gzip 后，响应中应至少出现以下字段：
- Content-Encoding: gzip —— 最直接证据
- Vary: Accept-Encoding —— 表示服务器根据该头做缓存区分，是规范做法
-
Content-Length 值明显小于未压缩时（可对比不带
Accept-Encoding的请求） - 若看到 Content-Encoding: identity 或完全缺失该字段，说明未压缩
排除常见干扰因素
即使配置正确，也可能因以下原因不触发压缩：
-
响应体太小：Nginx 默认
gzip_min_length 20;，小于 20 字节不压缩；Apache 也有类似阈值 -
MIME 类型未匹配：确认
gzip_types（Nginx）或AddOutputFilterByType（Apache）包含当前资源类型（如text/css、application/javascript） -
后端禁用压缩：PHP 的
zlib.output_compression或应用框架（如 Express 的compression()中间件）可能覆盖 Web 服务器设置 - CDN 或反向代理拦截：检查是否经过 Cloudflare、Nginx 反代等，它们可能解压后再发给客户端
快速验证压缩效果（不只看 Header）
单看响应头不够直观，建议组合命令验证实际压缩行为：
- 获取压缩后大小：
curl -H "Accept-Encoding: gzip" -s https://example.com/style.css | wc -c - 获取原始大小（禁用压缩）：
curl -H "Accept-Encoding: identity" -s https://example.com/style.css | wc -c - 对比两个数值，差异显著（如 30%+ 减少）且
Content-Encoding: gzip存在，即可确认生效
