nginx 不为 http/1.0 客户端启用 gzip 压缩，因协议不支持分块传输导致 content-length 无法准确设置；应使用 ngx_http_gunzip_module 实现缓存层按需解压，配合 gunzip on、gzip_vary on、差异化 cache_key 及 gzip_disable 规则实现兼容。
直接调低 gzip_http_version 并不能让老旧 HTTP/1.0 客户端获得 Gzip 压缩响应——Nginx 的设计逻辑决定了它不会为 HTTP/1.0 请求启用压缩，这是协议限制导致的硬性约束，不是配置可绕过的。
为什么 gzip_http_version 不能“兼容”旧客户端
HTTP/1.0 不支持分块传输（Transfer-Encoding: chunked），而 Nginx 的实时压缩必须在不预知响应体长度的前提下流式输出。若对 HTTP/1.0 请求强行压缩，就无法设置准确的 Content-Length，多数 HTTP/1.0 客户端会因收不到长度声明而提前关闭连接，造成响应截断或乱码。
因此，即使你显式写 gzip_http_version 1.0;，Nginx 在实际处理中仍会忽略该请求的压缩流程（日志中可见 gzip not used: http 1.0 类提示）。
真正有效的兼容路径是“降级解压”，而非“强制压缩”
对不支持 Content-Encoding: gzip 的老旧终端（如 IE6、嵌入式设备、部分 IoT 客户端），应采用 ngx_http_gunzip_module 实现缓存层按需解压：
- 后端或源站仍以 gzip 形式生成并缓存资源（节省带宽与磁盘）
- Nginx 检测到客户端请求头不含
Accept-Encoding: gzip（或匹配gzip_disable规则）时，自动从缓存读取 .gz 文件并实时解压后返回明文 - 整个过程无需修改上游服务，也不增加 CPU 压力（解压仅发生在命中缓存时）
配套关键配置示例
确保以下几项同时生效：
-
gunzip on;—— 在 http/server/location 块中启用解压能力 -
gzip on;且gzip_vary on;—— 保证上游压缩内容能被正确缓存并区分编码版本 -
proxy_cache_key "$scheme$request_method$host$uri$is_args$arg_v$http_accept_encoding";—— 让 gzip 和非 gzip 响应各自独立缓存 -
gzip_disable "MSIE [1-6]\.";—— 显式排除老旧 UA，触发 gunzip 解压逻辑
验证是否生效
用老旧 UA 模拟请求，检查响应头：
- 不应出现
Content-Encoding: gzip - 应有
Vary: Accept-Encoding（说明缓存已区分编码） - 响应体大小应接近原始未压缩文件（而非 .gz 文件大小）
可用 curl 测试：curl -I -H "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0)" https://yoursite.com/app.js
