直接设gzip_http_version 1.0无法让http/1.0客户端获得压缩响应，因协议不支持chunked编码且无法准确设置content-length，nginx会拒绝压缩；真正有效方案是启用gunzip on配合gzip_disable和差异化cache_key实现缓存层按需解压。
直接把 gzip_http_version 设为 1.0 并不能让旧客户端（比如 HTTP/1.0 浏览器）获得压缩响应——Nginx 在底层会拒绝为 HTTP/1.0 请求执行 Gzip 压缩，这是协议限制决定的硬性规则，不是靠改配置就能绕过的。
为什么不能靠降低 gzip_http_version 兼容旧协议
HTTP/1.0 不支持分块传输（Transfer-Encoding: chunked），而 Nginx 的实时 Gzip 压缩必须流式输出，无法提前知道响应体总长度。若强行压缩并返回给 HTTP/1.0 客户端，就无法设置准确的 Content-Length，多数老客户端会因收不到长度声明而中断连接，导致页面乱码或资源加载失败。
- 即使你写
gzip_http_version 1.0;，Nginx 日志里仍会出现gzip not used: http 1.0提示 - 这不是 Bug，而是设计保护：避免把压缩内容发给无法正确解压的终端
- HTTP/2 连接不受影响，因为 Nginx 内部将其识别为 ≥1.1，
gzip_http_version 1.1默认生效
真正有效的旧客户端兼容方案
对不支持 Accept-Encoding: gzip 的老旧终端（如 IE6、部分嵌入式设备），应采用“缓存层按需解压”策略，而不是试图让它们接收压缩内容：
-
gunzip on;—— 启用 Nginx 的自动解压能力（需确保模块已编译） -
gzip on; gzip_vary on;—— 源站仍以 .gz 形式缓存资源，并通过Vary头区分编码版本 -
proxy_cache_key "$scheme$request_method$host$uri$is_args$arg_v$http_accept_encoding";—— 让带 gzip 和不带 gzip 的响应各自独立缓存 -
gzip_disable "MSIE [1-6]\.";—— 显式匹配老旧 UA，触发gunzip解压逻辑
验证旧客户端是否被正确处理
用模拟请求确认行为是否符合预期：
- 用 IE6 UA 请求：
curl -I -H "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0)" https://yoursite.com/app.js - 响应头中不应出现
Content-Encoding: gzip - 应有
Vary: Accept-Encoding（说明缓存已做编码区分） - 响应体大小应接近原始未压缩文件，而非 .gz 文件大小
推荐的标准配置组合
在 http 或 server 块中统一设置，兼顾现代与旧终端：
gzip on; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; gzip_vary on; gzip_min_length 1000; gzip_comp_level 6; gzip_disable "MSIE [1-6]\."; gunzip on;
这套配置既保障了 HTTP/1.1+ 和 HTTP/2 客户端获得高效压缩，又通过 gunzip + gzip_disable 实现对老旧 UA 的无感降级，不增加后端负担，也不牺牲缓存效率。
