我们正在Azure中使用Verizon CDN的标准产品。从文档中可以明显看出，如果客户端支持多个压缩方案（https://docs.microsoft.com/en-us/azure/cdn/cdn-improve-performance#azure-cdn-from-verizon-profiles），则Verizon会优先于Brotli其他压缩方案：
如果请求支持多个压缩类型，则这些压缩类型优先于brotli压缩。
问题是我们的血统优先于Brotli。因此，对于直接向原点发送
Accept-Encoding: gzip, deflate, br头的请求，响应将返回Content-Encoding: br头。但是，通过CDN进行的同一请求将返回Content-Encoding: gzip。
Azure的文档尚不清楚此处发生的情况。 POP节点是否解压缩资源并使用gzip和缓存重新压缩？它是否解压缩并缓存，然后根据请求的标头动态压缩？我向Azure支持人员提出了这个问题，可惜没有得到明确的答案。
我们正在Azure中使用Verizon CDN的标准产品。从文档中可以明显看出，如果客户端支持多个压缩方案，则Verizon会优先于Brotli其他压缩方案（...
我终于从Verizon得到了一个明确的答案。从CDN的POP节点到源的Via标头有效地禁用了压缩（此页面将对此进行更好的解释：https://community.akamai.com/customers/s/article/Beware-the-Via-header-and-its-bandwidth-impact-on-your-origin?language=en_US）。在我们的Web服务器中进行处理（剥离标题或将Web服务器配置为无论如何都进行压缩）都解决了该问题。换句话说，如果客户端支持Brotli，而Origin更喜欢Brotli，则Verizon的CDN会缓存并使用通过Brotli压缩的内容。