nginx需启用gunzip模块对后端返回的gzip响应进行条件解压，以兼容老旧移动端浏览器；须同时满足响应含content-encoding: gzip、客户端accept-encoding不含gzip、gunzip on已开启且作用域匹配、响应mime类型在gunzip_types列表中。
要让老旧移动端浏览器（如早期 Android WebView、Symbian 浏览器、部分功能机 UA）正常加载内容，关键不是“给它们加压缩”，而是当后端已返回 gzip 压缩响应时，由 Nginx 主动解压再发出去——避免乱码或白屏。gunzip 模块干的就是这件事。
确认触发条件是否满足
gunzip 不会无条件工作，必须同时满足四点：
- 后端响应头中明确包含 Content-Encoding: gzip（例如 Node.js/Java 应用自行启用了 gzip，或 Nginx 启用了
gzip_static on并命中 .gz 文件） - 老旧客户端请求头中 Accept-Encoding 不含 gzip（常见于 Android 2.x WebView、UC Browser 旧版、Opera Mini 等，有些甚至根本不带该头）
- Nginx 已启用
gunzip on，且作用域覆盖对应请求路径（推荐放在location块内，而非盲目全局开启） - 响应 MIME 类型在
gunzip_types列表中（默认只含text/plain，需手动补上text/html、application/javascript、application/json等移动端常用类型）
在 location 中精准启用并调优
不要在 http 块里一刀切开启 gunzip，尤其对高并发移动端接口，解压会增加 CPU 开销。应聚焦实际受影响的路径，例如静态资源或 API：
- 针对 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>} - 可选增强兼容性：搭配
gzip_disable "Android [1-3]\."; gunzip on;，显式匹配老旧 Android UA，确保不被 gzip 模块跳过又未被 gunzip 处理
验证是否真正生效
用 curl 模拟真实老旧终端行为，不依赖浏览器 UA 字符串猜测：
- 执行：
curl -s -I -H "Accept-Encoding:" https://yoursite.com/app.js - 检查响应头：
✅ 没有Content-Encoding: gzip
✅Content-Length明显变大（说明已解压）
✅Vary: Accept-Encoding仍存在（表示 Nginx 正确识别了协商逻辑） - 进一步确认内容可读：
curl -s -H "Accept-Encoding:" https://yoursite.com/app.js | head -n 3—— 应看到明文 JS 代码，而非乱码或二进制流
与 gzip 模块协同，不冲突也不重复
gunzip 和 gzip 可共存，分工明确：
-
gzip on：服务现代客户端，Nginx 对原始响应实时压缩 -
gunzip on：服务老旧客户端，Nginx 对后端传来的 gzip 响应做条件解压 - 二者互不影响——gzip 不会处理已带
Content-Encoding: gzip的响应；gunzip 也不会干预未压缩响应 - 典型组合配置：
gzip on;<br>gzip_types text/html application/javascript ...;<br>gunzip on;<br>gunzip_types text/html application/javascript ...;
