Nginx gzip_代理指令的选项是什么？

该指令允许以下选项（非详尽）：

• 过期
  如果响应标头包含“Expires”字段，且该字段的值禁用缓存，则启用压缩
• 无缓存
  如果响应标头包含带有“无缓存”参数的“缓存控制”字段，则启用压缩
• 无店铺
  如果响应头包含带有“no store”参数的“Cache Control”字段，则启用压缩
• 私人
  如果响应头包含带有“private”参数的“Cache Control”字段，则启用压缩
• 没有上次修改
  如果响应标头不包含“上次修改”字段，则启用压缩
• 无标签
  如果响应标头不包括“ETag”字段，则启用压缩
• auth
  如果请求标头包含“授权”字段，则启用压缩

我看不出有任何合理的理由使用这些选项中的大多数。例如，为什么代理请求是否包含

Authorization

头或

Cache Control:private

，会影响我是否要gzip它

考虑到Nginx的旧版本，我可以看到no_etag的一个用例：如果您没有将Nginx配置为为为gzip响应生成etag，那么您可能更喜欢使用etag传递未压缩的响应，而不是不使用etag生成压缩的响应

不过，我想不出还有其他的

每个选项的预期使用情况是什么？

来自：（重点）

该指令有许多参数，指定NGINX应该压缩哪种类型的代理请求。例如，只压缩对不会缓存在代理服务器上的请求的响应是合理的。为此，gzip_proxied指令具有一些参数，这些参数指示NGINX检查响应中的缓存控制头字段，并在值为no Cache、no store或private时压缩响应。此外，必须包含expired参数以检查Expires标头字段的值。以下示例中设置了这些参数以及auth参数，auth参数检查是否存在授权标头字段（授权响应特定于最终用户，通常不缓存）

我同意不压缩可缓存响应是合理的。考虑到代理缓存的主要节省是提高性能（响应时间）并减少代理请求上游资源时所花费的时间和带宽。要获得这些性能优势，需要权衡缓存存储的成本。以下是一些不压缩可缓存响应的用例：

在许多网站的正常web流量中，非个性化响应（构成大多数可缓存响应）已经在web构建过程中通过脚本缩小、图像大小优化等技术进行了优化。虽然这些静态资源可能会因压缩而略有减少，但尝试将它们压缩得更小的CPU成本可能不是对代理层机器资源的有效利用。但为登录用户提供的包含大量应用程序生成内容的动态生成页面很可能会从压缩中获益（通常不可缓存）

您正在昂贵的上游服务前设置代理，但您正在为另一个代理提供响应，该代理将负责每个用户代理的压缩。例如，如果您的CDN向同一昂贵的上游资源（来自不同的地理边缘位置）发出多个请求，并且您希望确保可以重用昂贵的响应。如果CDN缓存未压缩的版本（为已压缩和未压缩的用户代理提供服务），则您可能在代理服务器上进行压缩，而在CDN上再次对其进行解压缩，这只是在两侧浪费硬件和电力，以减少链中最高带宽部分的带宽。（Response gzip压缩在最后一英里时最为有效，可以将响应数据发送到用户的手机，当用户进入地铁时，手机的响应数据下降到一个信号点。）

对于相当大的响应实体，对于资源的字节范围，请求可能（来自各种用户代理，但通常通过下游CDN中介）进入不支持压缩的用户代理。CDN可能从自己的缓存中提供字节范围请求，前提是缓存中已经有未压缩的版本

---

“尝试将它们压缩到更小的CPU成本可能不是对代理层机器资源的有效利用”-但我们不是在讨论代理层中的压缩，对吗？我们在讨论Nginx后端上的gzip，在某个代理层后面，该代理层已将请求转发到该Nginx后端；代理层不需要压缩或解压缩响应本身。（不影响你的观点的整体主旨，只是吹毛求疵。）第1点（关于gzip压缩可缓存资源通常不值得，因为可缓存资源通常已经缩小，而gzip压缩可缓存资源是浪费时间）对我来说非常脆弱。这在原则上似乎是合理的，但我认为在实践中是错误的；人们已经发现，即使gzipping的内容已经缩小，gzipping仍然会显著减少文件大小。另一方面，第2点和第3点更有说服力！如果我可以提供tl；dr：代理通常需要他们缓存的内容的解压缩版本，ei