使用nginx作为iis / .NET应用程序服务器之前的反向代理/负载均衡器。
我们的服务器被configuration为gzip响应有效载荷。 工作正常。
当我们把gzip放在前面的时候，反应就不再被压缩了。
问题1：我们需要重新configurationnginx中的gzip吗？
问题2：做两次gzip工作是否合适？
这里做什么是正确的？
（我觉得gzip应该只发生在一层，尽pipe减less线上的负载是有好处的，甚至在nginx之后）。
这里是我目前的configuration参数为gzip（在http部分，在第一个上游块之前）
# ****************************** begin gzip section ******************** # Compression gzip on; # Enable Gzip compressed. # Enable compression both for HTTP/1.0 and HTTP/1.1. gzip_http_version 1.1; # Compression level (1-9). # 5 is a perfect compromise between size and cpu usage, offering about # 75% reduction for most ascii files (almost identical to level 9). gzip_comp_level 5; # Don't compress anything that's already small and unlikely to shrink much # if at all (the default is 20 bytes, which is bad as that usually leads to # larger files after gzipping). gzip_min_length 1000; # Compress data even for clients that are connecting to us via proxies, # identified by the "Via" header (required for CloudFront). gzip_proxied any; # Tell proxies to cache both the gzipped and regular version of a resource # whenever the client's Accept-Encoding capabilities header varies; # Avoids the issue where a non-gzip capable client (which is extremely rare # today) would display gibberish if their proxy gave them the gzipped version. gzip_vary on; # Compress all output labeled with one of the following MIME-types. # text/html is always compressed by HttpGzipModule gzip_types text/css text/* text/javascript message/* application/x-javascript application/json application/xml application/atom+xml application/xaml+xml; # ****************************** end gzip section ******************** 这可能是由于IIS运行gzip的HTTP版本。
Nginx代理默认通过HTTP 1.0进行后端请求。 目前大多数浏览器都使用HTTP 1.1。
我不确定IIS，但nginx在HTTP 1.1上运行gzip。
因此，如果没有中间的代理，请求可能会通过HTTP 1.1进入后端。 使用中间的代理，请求将在HTTP 1.0上触发后端。
尝试在代理服务器上设置proxy_http_version 1.1 。 这将通过HTTP 1.1发送后端请求。
你只应该gzip一次。 一般来说，最好是在实际的应用程序（就像你在做的那样）这样做，以便下拉caching图层可以cachinggzip的响应。应用程序开发人员应该做出决定gzip是否有益（基于在响应的大小，是否可压缩等）。 所以我build议在您的代理上closuresgzip。