HTTPS下Gzip压缩的真实收益需结合$ssl_handshake_time与$request_time交叉验证，握手时间占比过高（>300ms）时压缩效果被掩盖；Nginx≥1.19.2才支持该变量，须在log_format中显式配置。
HTTPS 下开启 Gzip 压缩确实能降低传输体积，但真实性能收益容易被 TLS 层开销掩盖，必须结合日志指标交叉验证，不能只看压缩率。
关键指标要盯紧 $request_time 和 $ssl_handshake_time
在 HTTPS 环境中，用户感知的总延迟（$request_time）包含三部分：TLS 握手时间、后端响应时间、网络传输+压缩耗时。若 $ssl_handshake_time 占比过高（比如 > 300ms），哪怕响应体压缩了 70%，终端加载速度也难有明显提升。
- Nginx ≥ 1.19.2 才支持 $ssl_handshake_time 变量，需在 log_format 中显式加入
- 对比开启 Gzip 前后，重点看 $request_time 中“握手占比”是否稳定——若握手时间波动大，压缩收益就不可靠
- 用命令快速筛查：awk '$8 > 0.3 {print $0}' ssl_gzip.log | wc -l（假设第 8 字段是 $ssl_handshake_time）
避免 HTTPS + Gzip 的典型误配
某些看似合理的配置组合，反而会拖慢 HTTPS 性能：
- 启用 TLS 1.0/1.1 或弱 cipher（如 RC4、DES），导致握手变慢甚至重试，压缩省下的几 KB 被几百毫秒握手抵消
- gzip_types 错误包含 image/*、font/* 等二进制类型，Nginx 仍尝试压缩（失败或低效），白白消耗 CPU
- gzip_vary on 后，CDN 或代理缓存未正确识别 Vary: Accept-Encoding，造成缓存击穿，反而增加回源压力
分场景看压缩收益是否真实落地
不是所有 HTTPS 请求都适合 Gzip，要看实际流量构成：
- API 接口（JSON/XML）：压缩率高（70%+）、体积适中（2–50 KB）、客户端普遍支持，收益最明显
- 移动端 HTML 页面：文本占比高，但需注意 gzip_min_length 设为 1k 而非 256 字节——小 HTML 文件压缩后可能因 TCP 包头开销反而更慢
- 静态资源（JS/CSS）：建议由构建工具预压缩（.gz 文件）+ Nginx 启用 gzip_static，比运行时压缩更稳、CPU 更低
实测建议：用 AB 日志比对而非单点平均值
直接对比两组日志（Gzip 开/关）中相同 URL、相似 User-Agent、HTTP/2 连接下的数据：
- 过滤掉 $http_accept_encoding 不含 gzip 的请求（说明没走压缩路径）
- 统计 request_time ≤ 100ms 的请求占比变化——压缩对快响应影响小，对慢响应（>500ms）改善更显著
- 检查 body_bytes_sent 分布：比如原来集中在 80–120 KB 的 HTML，开启后是否整体左移到 20–40 KB 区间
