☰

nginx 反向代理：如何将“accept-encoding”标头传递到后端服务器

tag-icon • tag-icon nginx
nginx 反向代理：如何将“accept-encoding”标头传递到后端服务器

在 IIS 8.5 之前使用 nginx。

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

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

第1部分：解决方案 #1 尝试在 nginx 上启用 gzip，从浏览器角度来看，这可以恢复 gzip，但现在（我们担心）要么 (a) 施加了双重 gzip 开销（iis 中的 gzip、nginx 上的解压缩、nginx 上的重新 gzip）；要么 (b) gzip 现在在 nginx 上，这并不理想（因为我们可以更好地控制 iis，iis 可以更好地决定什么是静态的，什么是动态的，因此缓存效果更好，等等）。解决方案 #1 的配置可以在此处看到：nginx：代理期间服务器上的 gzip 丢失

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

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

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

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

运行反向代理配置，剥离所有 gzip（例如，它似乎剥离了 accept-encoding 标头）：

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;            
    }
}

答案1

当然，主题发起者已经找到了答案，但为了其他观众的利益，我还是会发布它们。

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

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

proxy_http_version 1.1;

添加此位后，一切都将按预期工作（nginx 将从上游提供 gzip 压缩的内容）

相关内容