☰

nginx 未使用 gzip 与后端服务器通信

tag-icon • tag-icon nginx gzip
nginx 未使用 gzip 与后端服务器通信

我们的 Web 服务器运行的是 IIS 7，并配置为压缩动态和静态内容。当我直接访问这些服务器时，gzip 压缩可以正常工作。

我最近将 nginx 放在它们前面，gzip 压缩已停止。我可以通过明确在 nginx 本身上启用 gzip 压缩来解决这个问题，但考虑到我有六个后端和只有一个活动的 nginx 框，这似乎有点低效。

看来 nginx 正在删除Accept-Encoding标头。有人对如何“纠正”此行为有什么建议吗？

示例配置：

upstream backend {
  server 127.0.0.1:8080;
}

server {
  listen   80;
  proxy_set_header        Host            $host;
  proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

  location / {
    proxy_pass http://backend;
  }
}

答案1

Nginx 是 HTTP/1.0 反向代理，gzip 压缩直到 HTTP/1.1 才出现在 HTTP 规范中。

因此 nginx 不会发送 gzip accept-encoding 标头，因为它根本不接受它。在 nginx 中实现 gzip 处理的正确方法是使用 nginx 将 fastcgi 与后端通信或与 gzip 通信。

答案2

我不确定从什么时候开始，但 NGINX 现在确实支持其后端的 HTTP/1.1，只是这不是标准功能。您可以通过设置来启用它proxy_http_version。当您的后端服务器位于虚拟主机上时非常有用。例如：

location / {
  proxy_set_header X-Real-IP $remote_addr;
  proxy_pass http://my-backend-vhost.example.com/;
  proxy_http_version 1.1;
}

参考：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version

答案3

显然这是可以做到的！通过电子邮件：

[nginx 确实支持 HTTP/1.0]，但您完全可以通过 HTTP 1.0 进行 gzip，我们也这样做了。经过 gzip 压缩的内容不会受到 nginx 的影响，我们会预先对所有静态内容进行 gzip 级别 9 压缩，因此这是最佳选择。

nginx 可以配置为识别可以执行 gzip 的浏览器，并将所有正确的标头转发到后端和/或自行执行 gzip

我认为 nginx 不支持后端 1.1 的主要原因是因为分块编码。（它在前端确实支持）它增加了处理中途中断的连接的复杂性。

相关内容