跨域请求中Gzip头部丢失本质是Nginx未正确透传或与后端压缩冲突所致；需确认压缩主体、排查proxy_hide_header等干扰配置，并推荐统一由Nginx压缩且启用gzip_vary。
跨域请求中 Gzip 头部丢失，本质不是 Nginx 主动删了 Content-Encoding: gzip，而是它没参与压缩、或压缩后未正确透传响应头，导致浏览器收不到压缩标识。关键在确认：Gzip 是谁压的？谁负责传头？谁在中间干扰？
确认 Gzip 压缩是否由 Nginx 承担
如果后端服务（如 Spring Boot、Node.js）已自行压缩响应体并设置了 Content-Encoding: gzip，Nginx 默认会原样转发——但前提是它不修改响应体、也不覆盖响应头。
- 若 Nginx 启用了
gzip on，又收到已压缩的响应，它可能尝试二次压缩或拒绝处理，造成头被清空或响应异常 - 更常见的是：Nginx 开启了
gzip on，但后端也压缩，两者冲突，Nginx 为避免乱码会丢弃Content-Encoding头 - 验证方法：用
curl -I http://your-nginx/api/xxx查看响应头，对比直连后端的结果。若直连有Content-Encoding: gzip而 Nginx 代理后没有，说明问题出在代理链路
确保 Nginx 正确透传已有 Gzip 响应头
Nginx 默认不会过滤 Content-Encoding，但它可能因配置不当隐式干扰：
- 检查是否误配了
proxy_hide_header Content-Encoding—— 这行会直接屏蔽该头，必须删除 - 确认未启用
proxy_buffering off且配合了不兼容的缓冲策略，某些旧版本在禁用缓冲时会重写响应头 - 若使用了
sub_filter或add_after_body等内容改写模块，它们会触发响应体重写，导致 Nginx 自动移除Content-Encoding（因压缩体已被解包）
统一由 Nginx 负责压缩（推荐做法）
把压缩逻辑收归 Nginx，后端只返回原始响应，可彻底规避头冲突和透传风险：
- 在
http或server块中开启压缩：gzip on;、gzip_types application/json text/plain text/css application/javascript; - 明确允许跨域场景下压缩生效：
gzip_vary on;—— 它会添加Vary: Accept-Encoding，让浏览器和 CDN 知道该响应依赖压缩能力 - 跨域响应中，
Vary头对缓存和 CORS 兼容性很重要；缺失时，部分 CDN 或浏览器可能拒绝复用压缩响应 - 注意：不要对
OPTIONS预检响应开启压缩（体积小无意义），可用location块单独关闭：gzip off;
多级代理中 Gzip 头的传递保障
若请求经过多层 Nginx（如 CDN → 边缘 Nginx → 应用 Nginx），需确保每层都不破坏压缩链路：
- 上游代理必须透传
Accept-Encoding请求头给下游：proxy_set_header Accept-Encoding $http_accept_encoding; - 下游 Nginx 才能根据该头决定是否压缩；若上游清空了它，下游永远看不到压缩意愿
- 所有中间层禁用
gzip_disable对特定 UA 的拦截，避免意外跳过压缩 - 用
log_format记录$sent_http_content_encoding，便于逐层排查哪一环丢失了头
