移动端浏览器不支持 gzip 压缩实为老旧客户端未声明 accept-encoding: gzip 导致后端误压，nginx 的 gunzip 模块可在转发前按需解压，需同时满足：响应含 content-encoding: gzip、客户端 accept-encoding 不含 gzip、配置启用 gunzip on 且作用域匹配、mime 类型在 gunzip_types 列表中。
移动端浏览器不支持 Gzip 压缩，通常不是指“完全不能解压”，而是某些老旧环境（如 Android 2.x–4.3 的 WebView、Symbian 浏览器、早期 UC/Opera Mini）在请求头中不带 Accept-Encoding: gzip，或明确声明不支持（如 Accept-Encoding: identity），导致后端或 Nginx 误判为“可压缩”，结果返回了 gzip 编码内容——而客户端无法解压，最终页面白屏或脚本执行失败。
核心思路：不是禁用压缩，而是按需解压
关键不是让 Nginx “不压缩”，而是当后端已返回 gzip 响应（比如 Node.js 自行压缩、或启用了 gzip_static on 并命中 .gz 文件）时，由 Nginx 主动识别不兼容客户端，并在转发前解压再发出。这正是 gunzip 模块的作用。
- 只对真正不支持 gzip 的请求触发解压，不影响现代浏览器的压缩传输
- 解压发生在 Nginx 层，客户端收到的是原始未压缩内容，完全兼容
- 避免后端重复适配，统一由反向代理层兜底
必须同时满足的四个触发条件
gunzip 不会自动工作，缺一不可：
- 后端响应头含
Content-Encoding: gzip - 客户端请求头中
Accept-Encoding不含gzip（甚至为空或只有identity） - Nginx 配置中启用
gunzip on，且作用域覆盖该请求路径（推荐写在location块内） - 响应 MIME 类型在
gunzip_types列表中（默认仅text/plain，需手动补全）
精准配置示例（按场景）
不要在 http 块全局开启 gunzip on，避免无谓 CPU 开销：
- 静态资源（HTML/JS/CSS）：
location ~* \.(html|js|css|json)$ {<br> gunzip on;<br> gunzip_types text/html application/javascript text/css application/json;<br> gunzip_min_length 1000;<br>} - API 接口：
location /api/ {<br> proxy_pass http://backend;<br> gunzip on;<br> gunzip_types application/json;<br>} - 增强 UA 匹配（可选）：
gzip_disable "Android [1-3]\."; gunzip on;—— 确保这些 UA 不被gzip模块跳过，又不会漏掉gunzip处理
验证是否生效
用 curl 模拟真实行为，比看 UA 更可靠：
- 执行：
curl -s -I -H "Accept-Encoding:" https://yoursite.com/app.js - 检查响应头：
✅ 无Content-Encoding: gzip
✅Content-Length明显变大（说明已解压）
✅ 仍有Vary: Accept-Encoding（证明协商逻辑正常） - 进一步确认内容可读：
curl -s -H "Accept-Encoding:" https://yoursite.com/app.js | head -n 3，应看到清晰的 JS 代码而非乱码
