时间戳

首页 > 解决方案 > Varnish + Wordpress + Nginx - 防止 no-store no-cache must-revalidate headers

wordpress - Varnish + Wordpress + Nginx - 防止 no-store no-cache must-revalidate headers

问题描述

大约一周前，我们推出了一个网络应用程序，经历了一次沉重的负载高峰，并且宕机了近 2 个小时。我不会点名提到这家公司，但我们依靠他们的建议来防止这种确切的事情发生。

他们说，由于我们使用了 Varnish，我们可以很容易地处理流量涌入。但是，我们没有验证缓存是否按预期工作。不是。

TLDR：我们的网络应用程序正在发送Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0带有请求的标头，但没有迹象表明这是为什么。

我在哪里可以防止这些标头被发送？

PHP：5.6 Nginx：1.4.6 Varnish：1.1 Wordpress：4.6.12 Timber：1.2.4

与我们合作的 linux 管理员表示，他们仔细检查了配置，除了 AJAX 请求外，没有找到任何指定这些标头的内容。

#dont cache ajax requests

if(req.http.X-Requested-With == "XMLHttpRequest" || req.url ~ "nocache" || req.url ~ "(control.php|wp-comments-post.php|wp-login.php|bb-login.php|bb-reset-password.php|register.php)")

当我们在网站上强制使用 HTTPS（force-https 插件）后正确配置 Varnish 以进行缓存时，这是 Pre-launch 的一个 curl：

$ curl -Ik -H'X-Forwarded-Proto: *************
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
X-Server: *****
Date: Sat, 03 Nov 2018 22:36:43 GMT
X-Varnish: 53061104
Age: 0
Via: 1.1 varnish
Connection: keep-alive

从发布后：

curl -ILk ***********
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
X-Varnish: 691817320
Vary: Accept-Encoding
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: text/html; charset=UTF-8
X-Server: ****
Date: Mon, 19 Nov 2018 19:17:02 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Transfer-Encoding: chunked
Accept-Ranges: bytes
Via: 1.1 varnish
Connection: Keep-Alive
Set-Cookie: X-Mapping-fjhppofk=33C486CB71216B67C5C5AB8F5E63769E; path=/
Age: 0

Force-https 插件：我们激活了它，更新了 Varnish 配置以避免重定向循环，并在发布前一周确认它可以工作。

插件：这些没有改变，除了 force-https。

Web 应用程序：它是以前应用程序的更新版本，完全重新设计，但据我所知，应用程序中没有任何内容指定no-store no-cache要发送的标头。

我应该从哪里开始？谢谢！

标签： wordpressnginxvarnishvarnish-vcltimber

解决方案

发送这些标头的是 PHP 引擎。

每当您启动会话时，它都会这样做，这显然是基于Set-Cookie存在而发生的。

确保仅在绝对需要时才启动 PHP 会话。默认情况下，当响应包含其中之一Set-Cookie或“否定”时，Varnish 不会缓存Cache-Control，您两者都有。

所以摆脱无关session_start()和/或setcookie()电话是这里的关键。

您可以在此处找到有关何时可以预期发送反缓存标头的更多信息。

推荐阅读