Varnish和WordPress，是否有可能在没有外部插件的情况下进行真正的缓存？

Question

也许这在Varnish Cache世界里听起来是个新手问题，但为什么在WordPress中似乎需要安装一个外部缓存插件，才能完全缓存？

网站可以通过curl -I命令Varnish正确加载：

HTTP/1.1 200 OK
Server: nginx/1.11.12
Date: Thu, 11 Oct 2018 09:39:07 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: max-age=0, public
Expires: Thu, 11 Oct 2018 09:39:07 GMT
Vary: Accept-Encoding
X-Varnish: 19575855
Age: 0
Via: 1.1 varnish-v4
X-Cache: MISS
Accept-Ranges: bytes
Pragma: public
Cache-Control: public
Vary: Accept-Encoding

使用此配置时，默认情况下不会缓存WordPress安装。在测试多个缓存插件-some不工作，或者没有复杂的配置无法工作-我发现Swift的性能，在他们的精简版本，简单地激活缓存选项，这里真的采取了所有的优势，这里我可以看到varnish是完全工作的非常好的结果在压力测试中。

这对于单个环境上的单个站点来说是可以的，但在共享主机方面，当每个客户都可以安装自己的WP (或其他CMS)时，可能会出现问题。

所以关键是，如果不安装第三方缓存(和复杂的)插件，就没有办法充分利用Varnish的缓存优势？为什么不在默认情况下缓存所有内容？

任何形式的建议和帮助都将非常欢迎，提前感谢。

Answer 1

使用此配置时，默认情况下不会缓存WordPress安装

默认情况下，如果不更改Wordpress或Varnish配置中的任何内容，就会以Wordpress页面被缓存120秒的方式协同工作。因此，真正的缓存是可能的，但它将是一个短暂的缓存和非常低效的缓存。

您的特定标头指示不应发生缓存。它们要么是由Varnish本身发送的(我们都对复制粘贴内容而不考虑它的作用感到内疚)，要么是一个Wordpress插件(更多的是坏的，而不是好的)。如果不知道你的具体配置，就很难破译任何东西。

Varnish是一种透明的HTTP缓存代理。这意味着它将使用HTTP头，默认情况下是，它由后端(Wordpress)发送，比如Cache-Control，来决定是否可以缓存资源以及缓存多长时间。

事实上，Wordpress除了在一些特定的区域(错误页面、登录POST提交等)外，不会发送与缓存相关的头部。

here概述的标准方法是使用最高的TTL来配置Varnish。在此基础上：

Varnish不知道你什么时候更新文章内容，或者什么时候改变主题。典型的解决方案就是使用缓存失效插件，比如Varnish HTTP清除。

当内容改变时，插件需求来自于清除缓存的必要性。

假设你更新了一个Wordpress页面的文本。您之前访问过相同的页面，并将其放入Varnish缓存进行存储。在下一次访问时发生的事情是，Varnish将向所有下一位访问者提供相同的、现在已经过时的内容。

用于Varnish的Wordpress插件，如Varnish HTTP清除，将以一种方式与Wordpress挂钩，当页面更新时，它们将指示Varnish清除缓存。这是他们的主要目的。

这种方法(高TTL和缓存清除)是Varnish事实上的标准。因为Varnish没有关于何时更新内容的信息，所以清除缓存的内部工作是由应用程序本身完成的。缓存清除功能要么捆绑到CMS代码本身(例如Magento 2，具有开箱即用的功能，而不需要任何额外的插件)，要么是Wordpress插件。