![nginx:代理期间服务器上的 gzip 丢失](https://linux22.com/image/669395/nginx%EF%BC%9A%E4%BB%A3%E7%90%86%E6%9C%9F%E9%97%B4%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8A%E7%9A%84%20gzip%20%E4%B8%A2%E5%A4%B1.png)
使用 nginx 作为 iis/.NET 应用程序服务器前面的反向代理/负载平衡器。
我们的服务器已配置为 gzip 响应负载。运行良好。
当我们将 gzip 放在前面时,响应不再是 gzip 压缩的。
问题1:我们需要在nginx中重新配置gzip?
问题 2: 执行两次 gzip 工作是否合适?
- nginx 将请求传递给 Web 服务器
- Web 服务器 gzip 响应
- (我认为)nginx 解压响应,重新 gzip 压缩响应
此时该做什么才正确?
(我觉得 gzip 应该只在一层发生,尽管它有利于减少线路负载,即使在 nginx 之后也是如此。)
这是我当前的 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 ********************
答案1
这可能是由于 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。通常,最好在实际应用中执行此操作(就像您正在做的一样),以便下游缓存层等可以缓存经过 gzip 压缩的响应。应用开发人员应该确定 gzip 是否有用(基于响应的大小、是否可压缩等)。因此,我建议在您的代理上关闭 gzip。