用 curl --compressed 验证 Gzip 是否生效后，需分三层测千兆网络下压缩稳定性：先确认单请求压缩正确（响应头、体积比、$gzip_ratio），再施加CPU密集/小资源/混合协商压力，最后结合Nginx指标与系统监控归因分析。
直接用 curl --compressed 配合响应头和大小比对，就能快速验证 Gzip 是否生效；但要测它在千兆网络下的传输极限，关键不是“压满带宽”，而是看 Nginx 在高吞吐、低延迟、CPU 受限等真实瓶颈下，压缩是否稳定触发、体积是否持续缩小、响应是否不超时。整个过程分三层：先确认单请求压缩行为正确，再施加贴近千兆网卡能力的负载，最后结合指标归因。
一、单请求验证：确认 Gzip 真正起作用
压测前必须排除配置错误或协商失败——否则测的全是未压缩流量，结果无效：
- 执行
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/app.js，检查响应头是否含Content-Encoding: gzip且状态码为 200 - 对比同一资源开启/关闭 Gzip 时的
Content-Length，文本类资源（如 JS、JSON、HTML）压缩后应降至原始体积的 25%–35% - 检查 Nginx 访问日志中
$gzip_ratio变量值：>1 表示压缩成功，=1 表示跳过（常见于小文件、类型不匹配、客户端不支持） - 确认没和 Brotli 冲突：若同时启用了 Brotli，需设
brotli off或至少确保gzip_vary on，避免协商逻辑混乱
二、千兆网络适配的压力模式
千兆网卡理论上限约 117 MB/s（即 936 Mbps），但实际有效吞吐受协议开销、TCP 拥塞控制、Nginx 处理能力制约。测试应模拟其典型瓶颈，而非盲目堆 QPS：
-
CPU 密集型吞吐：用
wrk -c 1000 -d 30s --latency -H "Accept-Encoding: gzip" https://yoursite.com/static/main.css，目标资源选 200–500 KB 的 CSS/JS。观察 CPU 是否持续 >85%，同时$gzip_ratio是否从 3.0+ 明显跌至 2.0 以下——说明高压下压缩质量妥协 -
小资源高频并发：压测大量
/api/v1/status（返回约 1.2 KB JSON），设gzip_min_length 1024。重点看是否出现大量$gzip_ratio=1日志——若本应压缩却被跳过，说明gzip_types漏了application/json -
混合协商压力：用脚本随机混发带不同
Accept-Encoding的请求（gzip、gzip,deflate、空头）。验证 Nginx 是否严格按 q 值返回（如Accept-Encoding: gzip;q=0.8,br;q=1.0→ 应返回br，而非降级为gzip）
三、关键指标与归因分析
仅看带宽数字没有意义，要结合 Nginx 内置变量和系统指标交叉判断：
- 监控
nginx_stub_status中的Active connections和Reading/Writing/Waiting分布：若Writing持续高位，说明响应生成慢（可能是压缩阻塞） - 用
pidstat -u -p $(pgrep nginx) 1观察 worker 进程 CPU 使用率：超过 90% 且$gzip_ratio下滑，说明压缩成为瓶颈 - 记录
upstream_response_time和request_time差值：若差值显著增大（如 >15ms），表明压缩耗时占比升高 - 检查
gzip_buffers是否不足：若日志频繁出现gzip buffer too small，需调大（如gzip_buffers 32 8k）
真正有效的极限测试，是让 Nginx 在接近千兆吞吐时仍能保持压缩率稳定、响应时间可控、CPU 不过载。它不追求峰值带宽数字，而关注服务在压力下的确定性表现。
