NGINX gzip配置正确但未生效

前言
今年2月份左右为项目搭建了NGINX静态资源服务器，并启用了GZIP压缩功能，网站首页打开下载资源由原来的695KB降低到295KB。可以说效果显著。但在4月份监控网络发现流量使用量突然激增， 打开浏览器开发人员工具检查发现下载资源又回到695KB，并且所有静态资源都没有使用GZIP进行压缩，以下为Responce Headers

Connection: keep-alive
Content-Length: 19675
Content-Type: text/css
Date: Wed, 03 Apr 2019 02:48:45 GMT
ETag: "5c743ed6-4cdb"
Last-Modified: Mon, 25 Feb 2019 19:15:34 GMT
Server: nginx
Vary: Accept-Encoding

可以看出其中并没有Content-Encoding: gzip标签，而浏览器请求头里面是有的Accept-Encoding: gzip, deflate, 标签的。

Accept: text/css,*/*;q=0.1
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cache-Control: no-cache
Connection: keep-alive
...

出现该问题后，我先分析了NGINX服务器检查配置是否有更改，比对NGINX.conf与预生产的配置，并没有差异仅存在IP地址及路径相关配置的差异，gzip配置没有任何区别。 并且预生产gzip压缩功能正常，直接通过负载均衡地址访问网站gzip功能也正常。

gzip_static on;
gzip  on;
gzip_proxied any;
gzip_min_length  1k;
gzip_buffers     4 16k;
gzip_http_version 1.0;
gzip_comp_level 5;
gzip_types text/plain application/javascript application/css text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
gzip_vary on;

分析到这里可以确定并不是nginx服务器的问题，回想这两个月应用服务器并没有做任何更改，但整个网站的外网设备都进行了万兆升级。前面通过浏览器开发人员工具检查资源时可以看出服务器返回的包头里面没有gzip标签，确定是网络的某一层将头里面的这个标签屏蔽了，于是联系了所有设备的厂商人员对设备的出入口进行抓包，检查是在哪一层将gzip标签屏蔽了，最后发现是waf里面的防护策略将该标签屏蔽掉了。放开后网络带宽瞬间由原来1.5G下降到500M左右。