Nginx网关应全局启用Gzip压缩：http块设gzip on，限定gzip_types为文本类MIME，gzip_min_length 1024，gzip_buffers 16 8k，gzip_vary on，gzip_http_version 1.1，gzip_comp_level 5，并透传Accept-Encoding头。
在分布式微服务网关中，Nginx 通常作为最外层反向代理或 API 网关统一入口，此时 Gzip 压缩应集中在 http 块全局配置，而非每个 server 或 location 单独开启——这样才能确保所有后端服务（无论 Java、Go 还是 Node.js）返回的文本响应都按统一策略压缩。
统一启用并限定压缩范围
只对真正受益的文本类型启用压缩，避免浪费 CPU 或适得其反：
-
必须开启
gzip on，且放在http块顶层，保证所有server继承 -
严格限制
gzip_types：仅包含可高效压缩的 MIME 类型，例如text/plain text/html text/css application/javascript application/json application/xml text/xml
不添加image/*、video/*、application/octet-stream等二进制类型——它们本身已压缩，Gzip 反而增大体积 -
排除已压缩的响应头：若后端服务（如 Spring Cloud Gateway）自身做了 Gzip，可通过
proxy_hide_header Content-Encoding和gzip_disable "msie6"避免重复压缩或兼容问题
设置合理阈值与缓冲区
防止小文件压缩开销反超收益，同时适配高并发场景：
-
gzip_min_length 1024（即 1KB）：低于此大小的响应跳过压缩。HTML 小页面、JSON 状态响应常在此范围，压缩几乎无收益 -
gzip_buffers 16 8k：分配 16 个 8KB 缓冲区（共 128KB），足以应对多数文本响应；过大易占内存，过小可能触发临时文件写入 -
禁用对旧客户端的压缩：用
gzip_disable "MSIE [1-6]\.";避免 IE6 等老浏览器解压异常，现代网关已无需支持此类终端，可直接移除该行
确保缓存与编码协商正确
网关常对接 CDN 或代理缓存，Vary 头和 HTTP 版本控制直接影响缓存命中率：
-
始终开启
gzip_vary on：让上游缓存（如 Varnish、CDN）根据Accept-Encoding区分存储 gzip / non-gzip 版本，避免未压缩内容被错误返回给支持 gzip 的客户端 -
强制
gzip_http_version 1.1：HTTP/1.0 不可靠支持分块编码与压缩协商，网关层应拒绝低版本请求或统一升至 1.1 -
检查后端是否透传
Accept-Encoding：默认proxy_set_header Accept-Encoding ""会清空该头，需显式保留：proxy_set_header Accept-Encoding $http_accept_encoding;
压缩级别与性能权衡
网关是流量中枢，CPU 效率比单点服务更关键：
-
固定使用
gzip_comp_level 5或6：Level 6 比 Level 5 压缩率仅高约 3%～5%，但 CPU 使用率上升明显；在千级 QPS 网关上，Level 5 是更稳的选择 -
不建议动态调整级别：Nginx 无原生条件压缩（如按 URL 路径设不同 level），强行用
map+ 多个gzip_comp_level会增加配置复杂度且不可靠 -
监控压缩效果：通过日志变量
$gzip_ratio记录实际压缩比，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $gzip_ratio';
