必须显式配置gzip_types application/json，否则nginx不压缩json响应；还需启用gzip on、gzip_min_length 1024、gzip_comp_level 6、gzip_vary on、gzip_proxied any，并通过curl验证content-encoding: gzip及压缩比。
API 接口返回的 JSON 数据非常适合用 Nginx 的 gzip_types 进行压缩，但必须精准匹配响应头中的 Content-Type: application/json，否则压缩不会生效。
必须显式加入 application/json
gzip_types 默认只包含 text/html，不包含任何 JSON 类型。即使后端返回的是标准 JSON，若未在配置中明确列出 application/json，Nginx 就不会压缩它。
- 正确写法：
gzip_types text/plain application/json application/javascript text/css; - 错误写法：
gzip_types text/plain;（JSON 被忽略） - 注意大小写：
application/json必须全小写，Nginx 匹配严格区分大小写
避免压缩已压缩或二进制类型
JSON 是纯文本，压缩收益高；但图片、音视频、PDF 等二进制内容本身已压缩，再套 Gzip 可能体积变大、浪费 CPU。
- 不要加入：
image/jpeg、video/mp4、application/pdf等 - 特别警惕：
application/octet-stream—— 很多文件下载接口用此类型，不应压缩 - 若 API 返回 Base64 编码的图片数据（仍属
application/json），可压缩，但实际收益低，建议前端分离资源请求
配合其他关键参数协同生效
仅配置 gzip_types 不够，还需确保整体压缩链路畅通：
-
gzip on;—— 全局启用，缺省为 off -
gzip_min_length 1024;—— 小于 1KB 的 JSON 响应（如简单状态返回）不压缩，避免开销反超收益 -
gzip_comp_level 6;—— 级别 6 是压缩率与 CPU 开销的合理平衡点，级别 9 对 JSON 提升不足 5%，但 CPU 负载翻倍 -
gzip_vary on;—— 让 CDN 或代理缓存区分压缩/未压缩版本，防止缓存污染 -
gzip_proxied any;—— 若 Nginx 作为反向代理（常见于 API 网关场景），需开启此项，否则上游返回的 JSON 即使符合类型也不压缩
验证是否真正生效
不能只看配置，要实测响应头：
- 用
curl -H "Accept-Encoding: gzip" -I https://api.example.com/v1/user查看返回头是否有Content-Encoding: gzip - 对比压缩前后响应体大小：
curl -H "Accept-Encoding: gzip" https://api.example.com/v1/list | wc -cvscurl -H "Accept-Encoding:" https://api.example.com/v1/list | wc -c - 检查 Nginx error 日志或启用
$gzip_ratio日志变量，确认压缩比（典型 JSON 压缩率在 60%~75%）
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
