如何检查服务器是否开启了 gzip 压缩
用 GET 请求检查 Content-Encoding: gzip，并区分单个响应与全站压缩。提供 curl 传输大小对比、浏览器检查及 Nginx/Apache 配置示例。
一句话回答：看响应头里的 Content-Encoding: gzip——表示这一条响应使用 gzip，不代表全站所有资源都压缩。最快的命令行检查：curl -H "Accept-Encoding: gzip" -D - -o /dev/null https://你的站点，返回头中出现 Content-Encoding: gzip 即压缩生效；注意必须带上 Accept-Encoding 请求头，否则服务器可能返回未压缩版本，造成"没开"的误判。
方法一：curl（最快）
curl -sS -H "Accept-Encoding: gzip" -D - -o /dev/null https://example.com | grep -i content-encoding
# 输出 Content-Encoding: gzip → 已开启
不带 -H "Accept-Encoding: gzip" 的 curl 默认不声明支持压缩，服务器可能返回原文——这是检查时用 curl 最容易犯的错。
想看实际压缩率对比：
curl -sS -H "Accept-Encoding: identity" -o /dev/null -w "%{size_download}\n" https://example.com
curl -sS -H "Accept-Encoding: gzip" -o /dev/null -w "%{size_download}\n" https://example.com
以上比较同一稳定资源的响应体传输大小，须先确认状态码和 Content-Encoding。--compressed 会自动解压，因此其输出再 wc -c 不能测出压缩后大小；HEAD 与 GET 的响应头也可能不同，验证实际传输优先 GET。
方法二：浏览器 DevTools
- F12 → Network 面板 → 刷新页面
- 点击 HTML/CSS/JS 请求 → Response Headers
- 找
Content-Encoding: gzip（或br，Brotli 压缩也算达标）
Network 的传输大小与资源大小可辅助比较，但缓存命中、响应头开销和浏览器计量口径会影响差值，不应把差值直接当作精确压缩收益。
没开启怎么开
Nginx：
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
gzip_min_length 1k;
Apache（mod_deflate）：
AddOutputFilterByType DEFLATE text/html text/css application/javascript
注意：JPEG/PNG、视频、WOFF2 等已压缩格式通常不值得再 gzip；SVG 等文本格式则可能受益。CDN 的压缩取决于产品、资源类型和配置，应分别验证边缘与源站响应，不要假定默认已经开启。共享缓存还需正确处理 Vary: Accept-Encoding。
配置确认后，可为这一个资源建立观测云 HTTP 拨测，发送相同的 Accept-Encoding 请求头并检查 Content-Encoding，持续验证后续发布没有改变该资源的压缩行为。
常见问题（FAQ）
Q：Content-Encoding: br 是什么？
A：Brotli 压缩，在某些内容和压缩级别下可能更小，收益须用实际资源比较。浏览器/CDN 是否协商 br 取决于支持情况及配置。gzip 或 br 有其一即算"开了压缩"。
Q：API 的 JSON 响应需要 gzip 吗？
A：适合对足够大的文本 JSON 做评估，收益取决于内容和 CPU 开销，不能保证固定比例。确保 gzip_types 里包含 application/json。
Q：开了 gzip 但 DevTools 里看不到？
A：检查路径上是否有反向代理/CDN 把压缩剥掉或未透传 Accept-Encoding；也可能是 gzip_min_length 设得比你的资源大，小文件不压缩属正常行为。
核查依据
本文依据官方文档核对，示例未在实际业务环境运行；上线前请按部署版本、权限与数据范围验证。
