分类导航
程序笔记程序问答

无法开始使用 Varnish 和 Wordpress - 教程已过时？

程序问答   发布时间：2022-06-01  发布网站：大佬教程  code.js-code.com
大佬教程收集整理的这篇文章主要介绍了无法开始使用 Varnish 和 Wordpress - 教程已过时？，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。

如何解决无法开始使用 Varnish 和 Wordpress - 教程已过时？？

开发过程中遇到无法开始使用 Varnish 和 Wordpress - 教程已过时？的问题如何解决？下面主要结合日常开发的经验，给出你关于无法开始使用 Varnish 和 Wordpress - 教程已过时？的解决方法建议，希望对你解决无法开始使用 Varnish 和 Wordpress - 教程已过时？有所启发或帮助；

问题描述

我无法遵循官方教程 Wordpress with Varnish。我使用的是 wordpress 5.7（当前版本）。

我有网络和 wordpress 方面的经验，并且我已经使用 docker 设置了一个功能测试 wordpress 容器。我还启动了一个 varnish 容器，但第一个问题是 default.vcl 文件 - 教程中有一个错字，它使用 sub vcl_rec 而不是 sub vcl_recv。我解决了这个问题，容器成功启动。

我的默认.vcl 文件

按照教程和其他一些信息启用 https（在 Varnish 前面是一个 Traefik 反向代理容器，它终止 TLS 连接），这是我完整的 default.vcl 文件，它至少应该为 wordpress 站点启用缓存.


backend default {
  .host = "wp";
}

sub vcl_recv{
  if (req.url ~ "wp-admin|wp-login") {
    return (pass);
  }

  if(!req.http.X-Forwarded-Proto) {
    set req.http.X-Forwarded-Proto = "http";
  }

  // Remove has_Js and Google Analytics __* cookies.
  set req.http.cookie = regsuball(req.http.cookie,"(^|;\s*)(_[_a-z]+|has_Js)=[^;]*","");
  // Remove a ";" prefix,if present.
  set req.http.cookie = regsub(req.http.cookie,"^;\s*","");

  set req.http.cookie = regsuball(req.http.cookie,"wp-settings-\d+=[^;]+(; )?","wp-settings-time-\d+=[^;]+(; )?","wordpress_test_cookie=[^;]+(; )?","");

  if (req.http.cookie == "") {
    unset req.http.cookie;
  }
}

使用此 vcl，网站成功打开，但没有缓存任何内容。

Chrome 开发工具屏幕截图

这是 Chrome devtools 中网络面板的屏幕截图：

无法开始使用 Varnish 和 Wordpress - 教程已过时？

从教程中我希望看到一个有效的结果，但我认为缺少一些东西。根据我有限的知识，我知道 cookie 会阻止缓存 - 也许新版本的 wordpress 会添加一些额外的 cookie？

检查日志

我使用命令 varnishlog 来查看发生了什么，但我还不够了解。在我看来，可能会阻止缓存的 cookie 正在被成功地一一删除？但是为什么会出现缓存未命中呢？

无需检查任何日志即可使教程示例正常工作。不过，它们在这里：

*   << BeReq    >> 3440655
-   Begin          bereq 3440654 fetch
-   VCL_use        boot
-   Timestamp      Start: 1615741331.296846 0.000000 0.000000
-   BereqMethod    GET
-   BereqURL       /
-   BereqProtocol  http/1.1
-   Bereqheader    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_2) AppleWebKit/537.36 (KHTML,like Gecko) Chrome/89.0.4389.82 Safari/537.36
-   Bereqheader    Accept: text/HTML,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
-   Bereqheader    Accept-Language: en-US,en;q=0.9,sl;q=0.8
-   Bereqheader    Sec-Ch-Ua: "Google Chrome";v="89","Chromium";v="89",";Not A Brand";v="99"
-   Bereqheader    Sec-Ch-Ua-Mobile: ?0
-   Bereqheader    Sec-Fetch-Dest: document
-   Bereqheader    sec-fetch-mode: navigate
-   Bereqheader    sec-fetch-site: none
-   Bereqheader    Sec-Fetch-User: ?1
-   Bereqheader    upgrade-insecure-requests: 1
-   Bereqheader    X-Forwarded-Host: removed manually
-   Bereqheader    X-Forwarded-Port: 443
-   Bereqheader    X-Forwarded-Proto: https
-   Bereqheader    X-Forwarded-Server: traefik
-   Bereqheader    X-Real-Ip: myip
-   Bereqheader    X-Forwarded-For: myip,192.168.4.2
-   Bereqheader    host: removed-manually
-   Bereqheader    Accept-EnCoding: gzip
-   Bereqheader    X-Varnish: 3440655
-   VCL_call       BACKEND_FETCH
-   VCL_return     fetch
-   BackendOpen    31 default 192.168.4.4 80 192.168.4.5 43538 connect
-   Timestamp      Bereq: 1615741331.297039 0.000193 0.000193
-   Timestamp      Beresp: 1615741331.325222 0.028376 0.028182
-   BerespProtocol http/1.1
-   BerespStatus   200
-   BerespReason   OK
-   Berespheader   Date: Sun,14 Mar 2021 17:02:11 GMT
-   Berespheader   Server: Apache/2.4.38 (Debian)
-   Berespheader   X-Powered-By: PHP/7.4.15
-   Berespheader   link: <https://removed-manually.com/wp-Json/>; rel="https://API.w.org/"
-   Berespheader   vary: Accept-EnCoding
-   Berespheader   content-encoding: gzip
-   Berespheader   Content-Length: 3186
-   Berespheader   Content-Type: text/HTML; charset=UTF-8
-   TTL            RFC 120 10 0 1615741331 1615741331 1615741331 0 0 cacheable
-   VCL_call       BACKEND_RESPONSE
-   VCL_return     deliver
-   Filters         testgunzip
-   Storage        malloc s0
-   Fetch_Body     3 length stream
-   Gzip           u F - 3186 8579 80 80 25423
-   BackendClose   31 default recycle
-   Timestamp      BerespBody: 1615741331.325436 0.028589 0.000213
-   Length         3186
-   BereqAcct      817 0 817 296 3186 3482
-   End

*   << Request  >> 3440654
-   Begin          req 3440653 rxreq
-   Timestamp      Start: 1615741331.296724 0.000000 0.000000
-   Timestamp      Req: 1615741331.296724 0.000000 0.000000
-   VCL_use        boot
-   ReqStart       192.168.4.2 59606 http
-   ReqMethod      GET
-   ReqURL         /
-   ReqProtocol    http/1.1
-   Reqheader      Host: removed-manually
-   Reqheader      User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_2) AppleWebKit/537.36 (KHTML,like Gecko) Chrome/89.0.4389.82 Safari/537.36
-   Reqheader      Accept: text/HTML,application/signed-exchange;v=b3;q=0.9
-   Reqheader      Accept-EnCoding: gzip,deflate,br
-   Reqheader      Accept-Language: en-US,sl;q=0.8
-   Reqheader      Cache-Control: max-age=0
-   Reqheader      cookie: _ga=GA1.2.1969059563.1611504964; wordpress_test_cookie=WP%20cookie%20check
-   Reqheader      Sec-Ch-Ua: "Google Chrome";v="89",";Not A Brand";v="99"
-   Reqheader      Sec-Ch-Ua-Mobile: ?0
-   Reqheader      Sec-Fetch-Dest: document
-   Reqheader      sec-fetch-mode: navigate
-   Reqheader      sec-fetch-site: none
-   Reqheader      Sec-Fetch-User: ?1
-   Reqheader      upgrade-insecure-requests: 1
-   Reqheader      X-Forwarded-For: myip
-   Reqheader      X-Forwarded-Host: removed-manually
-   Reqheader      X-Forwarded-Port: 443
-   Reqheader      X-Forwarded-Proto: https
-   Reqheader      X-Forwarded-Server: traefik
-   Reqheader      X-Real-Ip: myip
-   ReqUnset       X-Forwarded-For: myip
-   Reqheader      X-Forwarded-For: myip,192.168.4.2
-   VCL_call       RECV
-   ReqUnset       cookie: _ga=GA1.2.1969059563.1611504964; wordpress_test_cookie=WP%20cookie%20check
-   Reqheader      cookie: ; wordpress_test_cookie=WP%20cookie%20check
-   ReqUnset       cookie: ; wordpress_test_cookie=WP%20cookie%20check
-   Reqheader      cookie: wordpress_test_cookie=WP%20cookie%20check
-   ReqUnset       cookie: wordpress_test_cookie=WP%20cookie%20check
-   Reqheader      cookie: wordpress_test_cookie=WP%20cookie%20check
-   ReqUnset       cookie: wordpress_test_cookie=WP%20cookie%20check
-   Reqheader      cookie: wordpress_test_cookie=WP%20cookie%20check
-   ReqUnset       cookie: wordpress_test_cookie=WP%20cookie%20check
-   Reqheader      cookie:
-   ReqUnset       cookie:
-   ReqUnset       Host: removed-manually
-   Reqheader      host: removed-manually
-   VCL_return     hash
-   ReqUnset       Accept-EnCoding: gzip,br
-   Reqheader      Accept-EnCoding: gzip
-   VCL_call       HASH
-   VCL_return     lookup
-   VCL_call       MISS
-   VCL_return     fetch
-   link           bereq 3440655 fetch
-   Timestamp      Fetch: 1615741331.325474 0.028750 0.028750
-   RespProtocol   http/1.1
-   RespStatus     200
-   RespReason     OK
-   Respheader     Date: Sun,14 Mar 2021 17:02:11 GMT
-   Respheader     Server: Apache/2.4.38 (Debian)
-   Respheader     X-Powered-By: PHP/7.4.15
-   Respheader     link: <https://removed-manually.com/wp-Json/>; rel="https://API.w.org/"
-   Respheader     vary: Accept-EnCoding
-   Respheader     content-encoding: gzip
-   Respheader     Content-Length: 3186
-   Respheader     Content-Type: text/HTML; charset=UTF-8
-   Respheader     X-Varnish: 3440654
-   Respheader     Age: 0
-   Respheader     Via: 1.1 varnish (Varnish/6.5)
-   VCL_call       DEliVER
-   VCL_return     deliver
-   Timestamp      Process: 1615741331.325489 0.028765 0.000014
-   Filters
-   Respheader     Accept-Ranges: bytes
-   Respheader     Connection: keep-alive
-   Timestamp      Resp: 1615741331.325551 0.028827 0.000061
-   ReqAcct        907 0 907 402 3186 3588
-   End

有了所有这些信息，有人可以帮我诊断出什么问题吗？ 非常感谢！

解决方法

根据 VCL 和 VSL，我可以得出结论，您的网站已正确缓存。

VCL 代码只是为了扩展 [内置 VCL][1]。

内置 VCL 仅在以下情况下从缓存中提供对象：

  • 对于 GET 或 HEAD 请求
  • 当没有 Cookie 标头时
  • 当没有 Authorization 标头时

删除 cookie 的 VCL 逻辑就是这样做的。它由以下 VSL 行说明：

-   ReqUnset       Cookie: _ga=GA1.2.1969059563.1611504964; wordpress_test_cookie=WP%20Cookie%20check
-   ReqHeader      Cookie: ; wordpress_test_cookie=WP%20Cookie%20check
-   ReqUnset       Cookie: ; wordpress_test_cookie=WP%20Cookie%20check
-   ReqHeader      Cookie: wordpress_test_cookie=WP%20Cookie%20check
-   ReqUnset       Cookie: wordpress_test_cookie=WP%20Cookie%20check
-   ReqHeader      Cookie: wordpress_test_cookie=WP%20Cookie%20check
-   ReqUnset       Cookie: wordpress_test_cookie=WP%20Cookie%20check
-   ReqHeader      Cookie: wordpress_test_cookie=WP%20Cookie%20check
-   ReqUnset       Cookie: wordpress_test_cookie=WP%20Cookie%20check
-   ReqHeader      Cookie:
-   ReqUnset       Cookie:

在这种情况下，请求被认为是可缓存的，并且会发生缓存查找。

以下几行显示了缓存查找和随后的缓存未命中：

-   VCL_call       HASH
-   VCL_return     lookup
-   VCL_call       MISS
-   VCL_return     fetch

别担心，缓存未命中只是尚未发生的命中。

日志中的 fetch 行表示访问了 WordPress 后端。

对于要存储在缓存中的获取对象，[内置VCL][1]也有一些规则：

  • TTL 必须大于零
  • 不得在 no-cache 标头中提及 no-store、private 或 Cache-Control
  • 响应中不得包含 Set-Cookie 标头
  • 不允许对所有标头进行缓存变体（通过 Vary: *）

您返回的响应不会触发任何不可缓存的行为，因此 Varnish 决定将对象存储在缓存中。

以下 VSL 行说明了这一点：

-   TTL            RFC 120 10 0 1615741331 1615741331 1615741331 0 0 cacheable

它还暴露了对象只会被缓存 120 秒。这是因为您的 WordPress 没有设置 Expires 或 Cache-Control 标头。

以下是 TTL 行的语法：

%s %d %d %d %d [ %d %d %u %u ] %s
|  |  |  |  |    |  |  |  |    |
|  |  |  |  |    |  |  |  |    +- "cacheable" or "uncacheable"
|  |  |  |  |    |  |  |  +------ Max-Age from Cache-Control header
|  |  |  |  |    |  |  +--------- Expires header
|  |  |  |  |    |  +------------ Date header
|  |  |  |  |    +--------------- Age (incl Age: header value)
|  |  |  |  +-------------------- Reference time for TTL
|  |  |  +----------------------- Keep
|  |  +-------------------------- Grace
|  +----------------------------- TTL
+-------------------------------- "RFC","VCL" or "HFP"

因为您的 WordPress 没有通过缓存标头设置 TTL，所以使用了 default_ttl 参数的值，默认为 120 秒。

但是，您的 Google Chrome 开发者工具屏幕截图显示了一个带有 Age: 4 标头的 HTTP 响应。这意味着在这种情况下，页面是从缓存中提供的，并且已经在缓存中存储了 4 秒。

也许因为存活时间短，您假设页面没有被缓存，但事实并非如此。

有两种方法可以解决这个问题：

  • 在您的 WordPress 或网络服务器中设置 Cache-Control: public,max-age=3600 响应标头以增加 TTL
  • 编写一些 VCL 来绕过 TTL。

以下是您可以添加到 VCL 文件中的一些 VCL：

sub vcl_backend_response {
    set beresp.ttl = 1h;
}

对于存储在缓存中的每种类型的对象，此代码段将 TTL 设置为一小时。 [1]：https://github.com/varnishcache/varnish-cache/blob/6.0/bin/varnishd/builtin.vcl

大佬总结

以上是大佬教程为你收集整理的无法开始使用 Varnish 和 Wordpress - 教程已过时？全部内容，希望文章能够帮你解决无法开始使用 Varnish 和 Wordpress - 教程已过时？所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。
标签：
猜你在找的程序问答相关文章
其他相关热搜词更多
JavaScriptJS对象htmlcss字符串ui循环架构npm异步dom数据库json算法事件http运算符promise栈