如何强制Nginx反向代理与后端使用gzip压缩？配置疑问咨询

我现在用Nginx做反向代理，需要优化它和后端服务器之间的通信——我们传输的未压缩文本负载大概1MB，而且反向代理和后端在不同的数据中心。

我测试后发现，默认情况下反向代理和后端之间的压缩依赖于客户端的请求头，但这显然不是最优的：哪怕客户端没请求gzip，反向代理和后端之间也应该用gzip来节省跨数据中心的带宽。

我已经实现了强制压缩的功能，但不确定配置是否合理，尤其是强制设置Accept头这部分。我的思路是：代理请求时强制设置Accept-Encoding: gzip，如果客户端没请求gzip，就用gunzip来解压返回给客户端。

我的配置如下：

upstream backend { 
    server fqdn:443; 
    keepalive 32; 
} 

server { 
    listen 8080; 
    gzip on; 
    gunzip on; 
    gzip_proxied any; 
    gzip_vary on; 
    gzip_types text/css text/javascript text/xml text/plain application/javascript application/x-javascript application/json; 
    proxy_buffering "off"; 
    proxy_http_version 1.1; 

    location / { 
        proxy_set_header "Accept-Encoding" "gzip"; 
        proxy_pass https://backend; 
    } 
}

想请教两个问题：

1. 必须强制设置这个请求头是否合理？
2. 为什么gzip_proxied any没法满足我的需求？

首先，你的思路完全合理，强制设置Accept-Encoding: gzip这个操作在你的跨数据中心场景下非常有必要，下面我来拆解具体原因：

为什么gzip_proxied any帮不到你？ #

gzip_proxied这个指令管的是Nginx作为前端服务器，给客户端返回响应时是否启用gzip压缩，和反向代理与后端之间的通信压缩完全是两回事。它的逻辑是：当Nginx判断请求来自代理（或者满足你设置的any条件）时，会对返回给客户端的内容做gzip压缩。但它完全不影响Nginx作为"客户端"（向后端发起请求）时，是否请求压缩后的内容——这部分是由Nginx发送的Accept-Encoding请求头决定的。

默认情况下，Nginx作为反向代理向后端发请求时，会把客户端的Accept-Encoding头原封不动传过去。如果客户端没请求gzip，后端自然不会返回压缩后的内容，这就导致跨数据中心传输的是大体积的未压缩数据，完全浪费了带宽资源。

强制设置Accept-Encoding: gzip是否合理？ #

在你的场景（跨数据中心、大文本负载）下，这个操作不仅合理，甚至是最优选择：

• 跨数据中心的带宽成本通常更高，1MB文本压缩后大概能降到200-300KB，既能大幅节省带宽成本，还能降低传输延迟。
• 你已经配置了gunzip on，这意味着如果客户端不支持gzip（或者没请求），Nginx会自动把后端返回的gzip内容解压后再发给客户端，完全不影响客户端的体验。

不过有几个小细节可以优化你的配置：

• 可以把proxy_set_header "Accept-Encoding" "gzip";改成proxy_set_header Accept-Encoding gzip;，引号不是必须的，写法更简洁。
• 如果你后端支持的话，可以考虑让后端开启更高压缩比的配置（比如gzip_comp_level 6），进一步优化压缩效率。
• 如果没有特殊需求，建议把proxy_buffering "off"改成开启状态——开启缓冲后Nginx可以先完整接收后端的压缩响应，再按需解压发给客户端，避免因为客户端接收慢导致后端连接被长时间占用。

总的来说，你的核心配置思路是正确的，强制设置Accept-Encoding是实现反向代理与后端强制压缩通信的关键手段。

内容的提问来源于stack exchange，提问作者poussma