我在我的服务器上使用 varnish 7.1.2,我想升级到 varnish 7.4.2 一切都很好,但自从我进行升级后,我注意到一个奇怪的行为: 当我卷曲时,我看到 VARY cookie 更改为:
变化:接受编码、Cookie、用户代理 - 正确
到
变化:用户代理、Cookie - 错误
这意味着网络使用量的巨大增加,因为当 varnish 从后端获取内容时以及在客户端和 varnish 之间的通信中,内容似乎都不再被压缩。
经过大量搜索,我在函数 vcl_backend_response 中添加了以下内容:
if (beresp.http.content-type ~ "text") {
set beresp.do_gzip = true;
}
情况似乎有所改善,因为客户端收到了压缩内容,并且“accept-encoding”再次出现在不同的 cookie 上。然而,varnish 从后端获取内容时似乎始终是未压缩的,因此网络占用率仍然很高。
目前我决定回滚到 7.1.2,但从长远来看它仍然不是一个可持续的解决方案。
谁能帮我理解一下?
非常感谢
我已经使用不同版本的官方 Varnish Docker 镜像对此进行了测试。老实说:我看不出不同版本之间有任何行为差异。
我使用
varnish:latest
、varnish:7.1
甚至 varnish:stable
来执行测试。在所有测试场景中,只有 Vary: Cookie, User-Agent
出现。我没有在任何版本的 Accept-Encoding
标题中发现 Vary
标题。
这促使我做了更多研究,结果发现我用于测试的标准
nginx:alpine
图像没有在虚拟主机配置中启用 gzip。
这意味着如果您的后端服务器没有返回
Content-Encoding: gzip
标头,Varnish 将不会添加 Vary: Accept-Encoding
变体。
在我的 Nginx 配置中设置 gzip on;
没有帮助。显然设置
gzip_proxied any;
就成功了,突然间我得到了一个
Vary: Cookie, User-Agent, Accept-Encoding
标题。
我并不是说我的解决方案适合您,但值得检查您的后端是否确实返回 gzip 编码的内容。
故障排除
sudo varnishlog -g request -b -i berequrl -I BerespHeader:Content-Encoding -I BerespHeader:Vary -i Gzip -q "ReqUrl eq '/'"
请务必在空缓存上运行此命令,以便捕获后端获取。此示例还假设我们正在主页上进行测试
gzip 编码内容的输出可能如下所示:
** << BeReq >> 65541
-- BereqURL /
-- BerespHeader Vary: Cookie, User-Agent
-- BerespHeader Content-Encoding: gzip
-- BerespHeader Vary: Cookie, User-Agent, Accept-Encoding
-- Gzip u F - 37 11 80 216 226
对于纯文本输出,输出可能如下所示:
** << BeReq >> 3
-- BereqURL /
-- BerespHeader Vary: Cookie, User-Agent
结论如果后端实际返回 gzip 编码的内容,
Varnish 只会添加Vary: Accept-Encoding
。 Web 服务器配置阻止代理请求的 gzip 编码内容。请使用上述故障排除提示来检查此问题。