用curl模拟移动端请求可验证Gzip实际压缩效果：需检查Content-Encoding头、响应体大小及$bytes_sent日志值，重点确认application/json压缩、gzip_min_length阈值合理、gzip_vary开启。
直接用 curl 模拟移动端请求，配合响应头和大小对比，就能快速验证 Gzip 对移动端流量的实际节省效果。关键不是看配置有没有开，而是看真实请求下是否压缩、压了多少、是否被正确解码。
用 curl 模拟典型移动端请求
移动端浏览器普遍发送 Accept-Encoding: gzip, deflate，且 User-Agent 带有 Mobile 或 iOS/Android 字样。测试时应尽量贴近真实场景：
- 加
--compressed参数（等价于自动带上Accept-Encoding: gzip） - 显式指定移动端 UA，例如：
curl -H "User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1" --compressed https://your-api.com/data - 对比不带压缩的请求：
curl -H "User-Agent: ..." https://your-api.com/data
重点观察三项返回指标
不用算百分比，直接看终端输出或日志里的原始数字：
-
响应头中是否有
Content-Encoding: gzip—— 没这个头，说明没走压缩流程（可能被gzip_disable拦截，或gzip_types不匹配） -
响应体大小（
Content-Length值） —— 用-I查看响应头，或用--write-out "%{size_download}\n"获取实际下载字节数 -
日志中的
$bytes_sent—— 如果 Nginx 日志格式里包含此项，它反映真实发出的字节数，比Content-Length更可靠（尤其涉及 chunked 或后端流式响应时）
针对移动端的特殊验证点
很多优化在 PC 上有效，但在移动弱网下会失效或适得其反：
- 检查是否对
application/json分页接口生效 —— 移动端常批量拉取 JSON 列表，这类响应通常 2–10KB，是压缩收益最大的场景 - 确认
gzip_min_length没设太高（如 4k）—— 移动端小响应（如登录成功返回{"ok":true}）若小于阈值，就白白浪费了压缩机会 - 验证
gzip_vary on是否开启 —— 否则 CDN 或代理可能缓存未压缩版本，导致后续移动端用户拿到大包
快速对比脚本示例
把下面命令保存为 test-mobile-gzip.sh，一键跑出对比结果：
#!/bin/bash
URL="https://your-api.com/api/v1/list"
echo "=== 未压缩请求 ==="
curl -s -o /dev/null -w "Size: %{size_download} bytes\n" "$URL"
echo "=== 移动端 + gzip 请求 ==="
curl -s -H "User-Agent: Mozilla/5.0 (Linux; Android 13) AppleWebKit/537.36" \
--compressed -o /dev/null \
-w "Size: %{size_download} bytes, Encoding: %{content_type}\n" "$URL"
运行后你会看到两行 size 数值，差值就是移动端真实节省的流量。
