nginx 反向代理：如何将“接受编码”标头传递到后端服务器

Question

在 IIS 8.5 前使用 nginx。

IIS 8.5 已配置压缩并且运行良好。

但是当我们通过 nginx（下面的配置）点击它时，gzip 丢失了（从 Web 浏览器的角度来看）。

第 1 部分：解决方案尝试 #1 是在 nginx 上启用 gzip，这从浏览器的角度带回了 gzip，但现在（我们担心）已经（a）强加了双 gzip 开销（iis 中的 gzip，在 nginx 上解压缩，重新 gzip在 Nginx 上）；或者，(b) gzip 现在在 nginx 上，这并不理想（因为我们对 iis 有更好的控制，而 iis 可以更好地决定什么是静态的，什么是动态的，因此缓存更好，等等）。解决方案 #1 的配置可以在这里看到：nginx: gzip on server is lost during proxy

附录 1：根据 nginx 文档（https://www.nginx.com/resources/admin-guide/compression-and-decompression/）：“NGINX ...不会“双重压缩”已经压缩的响应”

这很好，因为不会发生双重压缩。

第 2 部分：所以我们真正想要的是让accept-encoding 标头通过，从浏览器通过 nginx 到 iis，让 iis 完成所有压缩，并通过 nginx 传递 gzipped 响应，而不会在 nginx 上发生任何 gzip 开销。我们的运行配置如下。

问题：我们如何在 nginx 1.7.9 中实现第 2 部分？

运行反向代理配置，它剥离所有 gzip（例如它似乎剥离了接受编码标头）：

http {

upstream sandbox_site {
    least_conn;
    # we pipe to back end on port 80 only, so that nginx handles all ssl
    server 192.168.2.16:80 max_fails=1 fail_timeout=60s;  # sbox3-site is .2.16
}

server {
    # This is sandbox.myapp.com block **************************************
    listen 192.168.2.27:80;
    server_name sandbox.myapp.com;

    location / {
    proxy_pass http://sandbox_site;
        proxy_redirect     off;
        proxy_set_header   Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    # This is SSL version of sandbox.myapp.com block **************************************
    listen 192.168.2.27:443 ssl;
    server_name sandbox.myapp.com;

    ssl_certificate      new-sandbox-myapp-com.cer;
    ssl_certificate_key  new-sandbox-myapp-com.key;

    ssl_protocols SSLv3 TLSv1;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://sandbox_site;
        proxy_redirect     off;
        proxy_set_header   Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;            
    }
} 

Answer 1

当然，主题发起者已经找到了答案，但为了其他观众，我会将其发布。

第一个解决方案（在 nginx 本身中启用 gzip）不会导致重复压缩。Nginx 足够聪明，可以看到上游已经进行了压缩，并且不会尝试压缩两次。

第 2 部分的解决方案只遗漏了代理配置中的一位，即：

proxy_http_version 1.1;

添加了这一点后，一切都会按预期工作（nginx 将从上游传送 gzip 压缩的内容）