我们将运行一个 nginx 反向代理，它将通过互联网从后端提取数据。
我们所说的通过互联网是指后端机器不会与前端反向代理位于一个局域网上。
我们认为在通过互联网发送这些请求之前，最好先掌握它们。
我认为它应该是这样的：
客户端使用 accept-encoding 标头或 gzip 请求内容。
反向代理将其发送到后端服务器。
由于已发送 gzip 的接受编码标头，后端会压缩该内容。
请求沿链条一路压缩发送。
我们都可以这样做，因为它非常简单。我的问题是，如果我们在 nginx 反向代理端启用了 gzip 压缩，这将如何工作？
nginx 会尝试对已经 gzip 压缩过的内容进行 gzip 压缩吗？
希望这能让你理解。谢谢。
更新 1：
我理解缓存已压缩内容（以及此内容）的含义。我们将修改缓存键以包含接受编码标头，从而根据用户代理可以接受的内容提供（和缓存）正确压缩/未压缩的内容。
答案1
不，在反向代理和后端服务器上设置 gzip 没有问题。至少我从来没有遇到过任何问题。代理将识别已经 gzip 的内容并直接传送它。
如果您希望从后端对任何内容进行 gzip 压缩，只需添加适当的标题。
proxy_set_header Accept-Encoding "gzip";
答案2
http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_http_version- gzip 在后端压缩响应所需的 HTTP 请求版本默认为 1.1。
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version- 代理模块默认使用的HTTP请求版本是1.0
这意味着默认情况下，当代理从后端发出请求时，浏览器的 GET 1.1 请求会转换为 GET 1.0 请求。后端需要 1.1 来执行 gzip 压缩，因此不会压缩响应。
proxy_http_version 1.1;我的建议是在反向代理上使用，并gzip on;在后端服务器中使用标准等设置。
还有两个额外的方法可以优化这一点。一个是“gzip_static”（一个额外的模块）的设置。当对“index.html”发出请求时，此设置会查找并提交“index.html.gz”文件（如果存在）。这对 CPU 使用率有积极影响，因为压缩不是即时执行的。
至于问题的另一部分，实际压缩的内容是通过 gzip_types 选项设置的。默认情况下，只有 text/html 会被压缩。如果您有 gzip 文件，则应小心将其排除在外。如果您使用选项*（压缩所有内容），则压缩文件在发送之前也会使用 gzip 进行压缩。这对于大多数图像（jpg、png、gif）来说并不是最佳选择，因为它们已经实现了某种 LZW 压缩层。因此，压缩压缩文件只会导致文件大小略有减少甚至增加，同时使用大量 CPU 资源来执行压缩。您应该根据请求频率和请求的内容类型（或压缩率）仔细检查要压缩的内容。就图像而言，使用额外工具（optipng 等）对其进行优化比打开 gzip 压缩更有效。