后台把gzip开关打开了，配置文件里那一行也确实在，可拿工具一测，页面体积和关掉的时候一模一样。服务器没报错，访问日志里也没有任何告警，开着和没开从表面上完全看不出区别，这不是错觉，也不一定是测法有问题。
判断压缩到底有没有生效，别看浏览器，看响应头。用curl -sI带上Accept-Encoding: gzip发一次请求，回来的头部里找不到Content-Encoding这一行，就说明这次传输没有被压缩，配置写得再标准也一样。
第一个原因是资源类型没被列进去，nginx的gzip_types默认只包含text/html这一项，样式表、脚本、JSON全都不在名单里，所以首页的HTML确实变小了，CSS和JavaScript还是原样。加类型要按mime写，text/css、application/javascript、application/json写在同一行、用空格隔开，同一个位置重复写这条指令会报重复定义，nginx直接起不来。改完还要reload，不reload等于没改。
第二个原因出在请求经过的链路上，gzip_proxied默认是off，请求头里带Via的、也就是从CDN回源或者经过反向代理转发过来的请求，nginx默认不给它压。前面套了一层CDN，回源那一跳拿到的就是未压缩的完整体积，用户侧看缓存头一切正常，中间那一层压不压它并不管。
第三个原因是这个文件本身就不该再压一次，图片、字体、压缩包已经是压缩格式，再走一遍gzip只会多消耗CPU，体积还可能略大一点，nginx按gzip_min_length判断，长度只取响应头里的Content-Length，比这个值小就跳过，没有Content-Length的动态页面不看这一条。所以拿一张图或者一个woff2去测，多半看不到Content-Encoding，据此得出开了没用的结论就偏了。要核对的是HTML、CSS、JavaScript这三类文本资源，各挑一个地址分别测，别拿首页一个结果推断全站，也别拿图片的结果反推配置写错。这三类里只要有一类没压到，整页体积就降不下来多少。
还有一个不会报错、但会让结果对不上的地方是缓存。响应头里缺了Vary: Accept-Encoding，中间那层缓存不知道同一个地址存在压缩和未压缩两个版本，谁先被缓存下来就长期发那一版。配好之后测还是没压缩，原因可能根本不在nginx这一侧。
验证的办法是把字节数直接打出来，别只盯响应头。curl加--compressed让它接受压缩，再用-w参数输出实际收到的字节数，格式串写%{size_download}，和不带压缩的那一次对比，文本资源常见能压掉一半甚至更多，重复度越高降得越多。差值为零，说明这条链路上一次都没压过，两个数字并排看最直接。
三处原因里，前两处在配置文件，第三处在资源本身，缓存那一段在中间层。改完拿一个HTML和一个CSS各测一次，两个都出现Content-Encoding，压缩这件事才算真正落地，否则只是开关打开了而已。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
