Nginx默认将gzip_http_version设为1.1，是因为HTTP/1.0不支持chunked编码，而即时压缩无法预知响应长度，故不能设置Content-Length；HTTP/1.1支持chunked，可安全流式压缩。
Nginx 默认只对 HTTP/1.1 及以上版本的请求启用 Gzip 压缩，对 HTTP/1.0 请求默认不压缩——这不是 bug，而是有意为之的设计选择，核心原因在于协议特性与响应头约束之间的冲突。
为什么 gzip_http_version 默认设为 1.1
Nginx 的 gzip_http_version 指令控制启用压缩所需的最低 HTTP 版本，默认值是 1.1。这意味着只有当请求的 HTTP 版本 ≥ 1.1 时，Nginx 才会进入压缩流程（前提是还满足 Accept-Encoding: gzip 和 gzip_types 匹配等条件）。
HTTP/1.0 缺乏对分块传输编码（Transfer-Encoding: chunked）的原生支持，而 Nginx 的即时压缩（on-the-fly compression）无法预先知道压缩后内容长度，因此不能设置准确的 Content-Length 响应头。在 HTTP/1.0 中，若不提供 Content-Length，客户端通常会认为连接已关闭，导致响应截断或解析失败。
HTTP/1.1 明确支持 chunked 编码，允许服务器边压缩边发送、无需预知总长度，因此能安全启用流式压缩。
HTTP/1.0 请求为何仍大量存在
尤其在移动网络环境下，部分运营商网关或老旧代理会主动降级请求为 HTTP/1.0，例如：
- 某些 4G/5G 网关中间设备不识别或忽略 HTTP/1.1 的
Connection: keep-alive，强制回退到 1.0 语义； - 低版本 Android WebView 或嵌入式终端发起的请求仍使用 1.0；
- 部分 CDN 或防火墙策略会统一改写请求版本以简化处理逻辑。
这类请求虽走 1.0 协议，但往往仍携带 Accept-Encoding: gzip，具备压缩条件——只是被 Nginx 默认规则拦截了。
如何安全开启 HTTP/1.0 压缩
如果确认下游客户端能正确处理无 Content-Length 的 gzip 响应（现代浏览器均支持），可显式放宽限制：
- 在
http、server或location块中添加：gzip_http_version 1.0; - 确保同时启用：
gzip on;gzip_types text/plain text/css application/javascript application/json; - 注意：开启后，Nginx 对 HTTP/1.0 请求将采用
chunked编码发送压缩内容（即使协议版本是 1.0，只要响应中声明了Transfer-Encoding: chunked，兼容客户端就能正常接收）。
该配置不会影响 HTTP/1.1 行为，仅扩展支持范围。
实际效果与权衡
文本类资源（HTML/CSS/JS）经 Gzip 压缩后，体积通常降至原始的 25%–33%，显著降低传输带宽。在移动网络下，30% 的 HTTP/1.0 请求若全部未压缩，整体响应流量可能上升 2–2.5 倍——这是真实观测到的性能损耗。
但需注意：开启 HTTP/1.0 压缩会略微增加 CPU 开销（所有匹配请求都进压缩流水线），且对极小响应（如 <1KB）可能得不偿失。建议配合 gzip_min_length 1024; 避免压缩过小内容。
