开启gzip后Content-Length丢失是因为Nginx启用压缩时自动切换为Transfer-Encoding: chunked，导致下载进度无法显示、校验失败或触发ERR_CONTENT_LENGTH_MISMATCH错误。
开启 gzip 后 Content-Length 丢失，本质是 Nginx 在启用压缩时自动切换为 Transfer-Encoding: chunked，而 chunked 编码不带 Content-Length 头——这会直接导致前端下载无法显示进度、部分客户端校验失败，甚至触发 ERR_CONTENT_LENGTH_MISMATCH 错误。
优先启用 gzip_static（静态预压缩）
这是最推荐的解法：提前将 JS/CSS 等资源用 gzip 压缩好（如 app.js.gz），再让 Nginx 直接返回该文件，而非实时压缩。
- 确保资源同名 .gz 文件已存在（例如
style.css对应style.css.gz） - 在 http/server/location 块中添加：
gzip_static on; - 保留原有
gzip on和gzip_types配置，作为兜底 - 此时响应仍含
Content-Encoding: gzip，但Content-Length是 .gz 文件真实大小，不会丢失
禁用 gzip 用于下载类接口
对明确用于文件下载的 location（如 /download/ 或匹配 *.zip 的路径），应关闭压缩，强制保留原始长度头。
- 在对应 location 中加入：
gzip off; - 同时建议显式关闭分块传输：
chunked_transfer_encoding off; - 若后端（如 SpringMVC）已设置正确的
Content-Length，Nginx 就会透传该头
验证并规避权限与配置干扰
Content-Length 丢失有时不是 gzip 本身的问题，而是底层异常掩盖了真实原因。
- 检查
/var/log/nginx/error.log，确认有无Permission denied或readv() failed报错 - 确保 Nginx 工作用户（如
www-data或nginx）对静态文件目录有读取权限：sudo chown -R nginx:nginx /path/to/staticsudo chmod -R 644 /path/to/static/* - 避免在 proxy_pass 场景下混用 gzip 和流式响应；上游服务若本身未压缩，Nginx 不应强行 gzip
不依赖 Content-Length 的兼容方案（备用）
当必须开启 gzip 又无法改后端逻辑时，可考虑前端降级处理：
- 下载请求加
Accept-Encoding: identity请求头，主动声明不接受压缩 - 后端根据该头跳过压缩，并确保写入完整
Content-Length - 或由后端改用
Content-Range+206 Partial Content模式，虽不常用但能绕过长度声明问题
