Nginx Gzip压缩响应本不应依赖Content-Length，而应使用Transfer-Encoding: chunked；问题根源是代理/缓存中传输机制混用导致头体不匹配，引发ERR_CONTENT_LENGTH_MISMATCH。
排查 Nginx Gzip 压缩因缺少 Content-Length 导致失败，核心不是“gzip 本身没加 Content-Length”，而是要厘清：Gzip 压缩响应本就不该依赖 Content-Length —— 它通常走分块传输（Transfer-Encoding: chunked），而 Content-Length 仅在非分块、非压缩或静态文件直传时才必须存在。真正出问题的场景，是 Nginx 在代理或缓存过程中错误地混用了传输机制，导致响应头与响应体不匹配，最终触发浏览器 ERR_CONTENT_LENGTH_MISMATCH。
确认是否真需要 Content-Length
HTTP/1.1 协议允许两种方式声明响应体长度：
-
有
Content-Length：适用于已知完整长度的响应（如小静态文件、未启用 chunked 的代理响应） -
有
Transfer-Encoding: chunked：适用于流式生成或压缩后长度未知的响应（Nginx 启用 gzip 且未禁用 chunked 时默认行为）
若你看到 gzip 响应里既没有 Content-Length，也没有 Transfer-Encoding: chunked，那才是异常——说明 Nginx 错误地删掉了长度标识，又没启用分块，导致浏览器无法判断响应边界。
检查 Nginx 是否意外清除了长度头或禁用了 chunked
以下配置极易引发“无长度头 + 非 chunked”状态：
-
proxy_set_header Content-Length ""或proxy_set_header Content-Length $sent_http_content_length（错误引用） -
chunked_transfer_encoding off（显式关闭分块，又未提供 Content-Length） -
proxy_buffering off且后端以流式输出 gzip 内容，Nginx 未能正确封装成 chunked
执行 nginx -T | grep -A5 -B5 "chunked\|Content-Length" 快速定位相关指令。临时注释掉所有 proxy_set_header Content-Length 和 chunked_transfer_encoding 行，reload 后用 curl -I http://host/test.js 观察响应头是否出现 Transfer-Encoding: chunked。
验证 gzip 响应实际传输是否完整
即使头里没 Content-Length，只要 Transfer-Encoding: chunked 存在且响应体完整，就不会报错。问题常出在“传输被截断”：
- 用
curl -s http://host/app.js | wc -c获取实际接收字节数 - 对比原始未压缩文件大小：
wc -c /path/to/app.js（若启用gzip_static，则比对app.js.gz） - 若
curl返回字节数明显偏小（如卡在 4096、8192 等缓冲边界），说明 proxy_buffers 不足或proxy_max_temp_file_size过小，导致 gzip 流被截断
可临时加大缓冲：在 location 块中添加 proxy_buffers 16 64k; proxy_busy_buffers_size 128k;，再测试。
区分 gzip 和 gzip_static 对 Content-Length 的影响
这是最易混淆的一点：
-
常规 gzip on：Nginx 动态压缩，响应走 chunked，不设
Content-Length是正常且推荐的 -
gzip_static on：Nginx 直接返回预压缩的 .gz 文件，此时必须有
Content-Length（等于 .gz 文件大小），且Content-Encoding: gzip和Content-Type必须正确配对；若缺失Content-Length，大概率是文件权限问题或gzip_static实际未生效
用 curl -I http://host/style.css 查看：若有 Content-Encoding: gzip 但无 Content-Length，且你启用了 gzip_static，就去检查 style.css.gz 是否真实存在、Nginx 进程能否读取、location 块是否正确启用了 gzip_static on。
