我们的Web服务器正在运行IIS 7，并configuration为压缩dynamic和静态内容。 当我直接打这些服务器时，gzip压缩工作。
我最近把nginx放在它们前面，并且gzip压缩已经停止。 我能够通过在nginx本身上显式启用gzip压缩来解决这个问题，但是考虑到我有六个后端和只有一个活动的nginx框，这似乎有点低效。
看来nginx正在删除Accept-Encoding头。 有没有人有任何build议如何“纠正”这种行为？
示例configuration：
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; } }
Nginx是一个HTTP / 1.0反向代理，在HTTP / 1.1之前，gzip压缩不在HTTP规范中。
因此，nginx将不会发送gzip接受编docker，因为它根本不接受它。 在nginx中实现gzip处理的正确方法是将fastcgi与后端进行对话，或者使用nginx对gzip进行gzip处理。
显然这是可能的！ 通过电子邮件：
[nginx做的是HTTP / 1.0]，但你完全可以通过HTTP 1.0做gzip，而且我们可以。 gzip的内容是通过nginx触及的，我们将gzip级别9的所有静态内容，所以这是最佳的。
nginx可以configuration为识别可以执行gzip的浏览器，并且将所有正确的头文件转发到后端和/或执行gzip本身
我认为nginx由于分块编码不支持1.1到后端的主要原因。 （它在前端支持）它增加了处理中途连接的复杂性。
我不确定，因为多久，但NGINX现在支持HTTP / 1.1的后端，这只是一个标准的function。 您可以通过设置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