Nginx网关统一开启Gzip压缩需在http或server块配置：gzip on; gzip_min_length 1024; gzip_comp_level 5; gzip_types text/plain text/css application/javascript application/json application/xml text/html; gzip_vary on; gzip_proxied any；并关闭后端服务压缩，避免双重压缩。
在微服务网关中用 Nginx 统一开启 Gzip 压缩，核心是把压缩逻辑收口到最外层反向代理层，避免每个后端服务重复配置、版本不一致或漏配。Nginx 作为流量入口，天然适合集中控制响应体压缩行为——既降低带宽消耗，又提升前端加载速度，且对后端服务完全透明。
哪些响应该压缩？关键判断依据
不是所有响应都适合 Gzip。Nginx 默认只压缩文本类资源，需明确指定 MIME 类型：
-
必须包含：
text/plain、text/css、text/javascript、application/javascript、application/json、application/xml -
建议加入：
application/vnd.api+json（JSON:API）、text/html（尤其 SSR 或网关返回的 HTML 入口页） -
通常排除：图片（
image/*）、视频、已压缩格式（application/gzip、application/zip）、大于 1MB 的响应（防 CPU 过载）
Gzip 核心参数配置要点
以下配置应放在 http 或 server 块中，确保全局或按域名生效：
-
gzip on;—— 启用压缩（必须显式开启） -
gzip_min_length 1024;—— 小于 1KB 的响应不压缩，避免小内容反而增大体积 -
gzip_comp_level 5;—— 推荐 4–6 级：兼顾压缩率与 CPU 开销；级别越高越慢，7+ 在高并发下易成瓶颈 -
gzip_types text/plain text/css application/javascript application/json application/xml text/html;—— 显式声明支持类型，不依赖默认值 -
gzip_vary on;—— 自动添加Vary: Accept-Encoding响应头，确保 CDN 或浏览器缓存正确区分压缩/未压缩版本 -
gzip_proxied any;—— 关键项：让 Nginx 对代理返回的响应也执行压缩（否则默认只压自己生成的内容）
与微服务协同的注意事项
压缩发生在 Nginx 层，后端服务无需改动，但需注意两点：
-
避免双重压缩：确认各微服务（如 Spring Boot、Node.js）未开启自身 Gzip（如 Spring 的
server.compression.enabled=true），否则 Nginx 再压一次可能损坏响应或浪费资源 -
响应头兼容性：若后端设置了
Content-Encoding: gzip，Nginx 不会再压缩；此时应统一关闭后端压缩，交由网关统一处理 -
流式接口慎用：SSE（Server-Sent Events）或长连接流式 JSON 响应，压缩可能导致延迟或解析异常，可配合
gzip_disable "msie6";或按 location 排除
验证是否生效
部署后用 curl 检查关键接口：
curl -H "Accept-Encoding: gzip" -I https://api.example.com/api/user/123
观察响应头是否含 Content-Encoding: gzip 和 Vary: Accept-Encoding；同时对比压缩前后 Content-Length 是否明显下降（如 JSON 从 25KB → 6KB）。浏览器开发者工具 Network 面板也能直观查看传输大小。
