必须显式配置gzip_types并包含application/json等API类型，因Nginx默认仅压缩text/html；gzip_types匹配响应头Content-Type而非文件后缀，需避免误加图片类型、漏配关键类型，并关闭后端压缩以统一由Nginx处理。
要让 Nginx 对常用 API 请求的响应（尤其是 JSON）启用 Gzip 压缩，必须显式配置 gzip_types 并匹配响应头中的 Content-Type。Nginx 默认只压缩 text/html，对 application/json 等 API 主流类型完全不压缩——这不是遗漏，而是设计使然。
API 响应压缩依赖 Content-Type，而非文件后缀
gzip_types 匹配的是响应头里的 Content-Type 字段值，不是 URL 路径或文件扩展名。例如：
- 后端返回
Content-Type: application/json→ 需在 gzip_types 中包含application/json - 返回
Content-Type: application/vnd.api+json→ 必须单独加上该类型，不能靠通配符 - 返回
Content-Type: application/json; charset=utf-8→ 仍匹配application/json（分号后参数会被忽略）
推荐为 API 场景配置的 MIME 类型
针对 RESTful 或 GraphQL 接口，以下类型压缩收益高、兼容性好，建议直接写入：
-
application/json（必备，覆盖绝大多数接口） -
application/xml和text/xml（如旧版 SOAP 或 RSS） -
application/vnd.api+json（JSON:API 规范） -
text/plain（纯文本格式的调试响应、日志输出等） -
application/javascript（动态生成的 JS 数据脚本，如 JSONP）
需避开的常见陷阱
这些配置看似合理，实则容易导致压缩失效或资源浪费：
- 漏掉
application/json—— 最常见的原因，导致所有 JSON 响应原样传输 - 误加
image/*或video/*—— 这些二进制格式本身已高压缩，Gzip 几乎无收益，还白耗 CPU - 混用
application/x-javascript和application/javascript—— 后者是现代标准，前者仅作兼容，无需并存 - 未设
gzip_min_length 1024—— 小于 1KB 的 JSON 响应（如 {“ok”:true}）压缩后可能更大，反而增加传输量
验证是否真正生效
光看配置正确不够，得确认实际请求走通了压缩链路：
- 用
curl -H "Accept-Encoding: gzip" -I https://api.example.com/users，检查响应头是否有Content-Encoding: gzip - 在浏览器 DevTools 的 Network 标签中，选中某 API 请求，看 Headers → Response Headers 是否含
Content-Encoding，同时 Preview/Response 显示可读内容（说明浏览器已解压） - 注意：若后端已自行压缩（如 Spring Boot 的 server.compression.enabled=true），Nginx 再压一次会出错，应关闭后端压缩，统一由 Nginx 处理
