无法开始使用 Varnish 和 Wordpress - 教程已过时?
Cannot get started with Varnish and Wordpress - tutorial outdated?
问题描述
我跟不上官方教程Wordpress with Varnish。我正在使用 wordpress 5.7(当前版本)。
我有网络和 wordpress 方面的经验,我已经用 docker 设置了一个功能测试 wordpress 容器。我还启动了一个 varnish 容器,但第一个问题是 default.vcl 文件——教程中有一个错字,它使用 sub vcl_rec
而不是 sub vcl_recv
。我修复了这个问题,容器成功启动。
我的 default.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+=[^;]+(; )?", "");
set req.http.cookie = regsuball(req.http.cookie, "wp-settings-time-\d+=[^;]+(; )?", "");
set req.http.cookie = regsuball(req.http.cookie, "wordpress_test_cookie=[^;]+(; )?", "");
if (req.http.cookie == "") {
unset req.http.cookie;
}
}
使用这个 vcl,网站成功打开,但没有缓存任何内容。
CHROME 开发工具屏幕截图
这是 Chrome devtools 中网络面板的屏幕截图:
我希望从教程中看到有效的结果,但我认为缺少了一些东西。根据我有限的知识,我知道 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/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
- ReqHeader Accept-Encoding: gzip, deflate, br
- ReqHeader Accept-Language: en-US,en;q=0.9,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", "Chromium";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, deflate, 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 代码只是用来扩展 [built-in VCL][1].
在以下情况下,built-in VCL 仅从缓存中提供 objects:
- 对于
GET
或 HEAD
个请求
- 当没有
Cookie
header 存在时
- 当没有
Authorization
header 存在时
删除 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
Don't worry, a cache miss is just a hit that hasn't happened yet.
日志中的 fetch
行表示访问了 WordPress 后端。
为了将获取的 object 存储在缓存中,[built-in VCL][1] 也有一些规则:
- TTL 必须大于零
Cache-Control
header 中不得提及 no-cache
、no-store
或 private
- 响应中不能有
Set-Cookie
header
- 不允许所有 header 的缓存变体(通过
Vary: *
)
您返回的响应不会触发任何 non-cacheable 行为,因此 Varnish 决定将 object 存储在缓存中。
下面的 VSL 行说明了这一点:
- TTL RFC 120 10 0 1615741331 1615741331 1615741331 0 0 cacheable
它还暴露了 object 只会被缓存 120 秒。这是因为您的 WordPress 没有设置 Expires
或 Cache-Control
header。
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 没有通过缓存 header 设置 TTL,所以使用 default_ttl
参数的值,默认为 120秒。
但是,您的 Google Chrome 开发人员工具屏幕截图显示带有 Age: 4
header 的 HTTP 响应。这意味着在这种情况下,页面是从缓存中提供的,并且已在缓存中存储了 4 秒。
可能因为生存时间短,您假设页面没有缓存,但事实并非如此。
有两种方法可以解决这个问题:
- 在您的 WordPress 或网络服务器中设置
Cache-Control: public, max-age=3600
响应 header 以增加 TTL
- 写一些 VCL 来绕过 TTL。
这里有一些您可以添加到您的 VCL 文件中的 VCL:
sub vcl_backend_response {
set beresp.ttl = 1h;
}
对于缓存中存储的每种 object 类型,此代码段会将 TTL 设置为一个小时。
[1]: https://github.com/varnishcache/varnish-cache/blob/6.0/bin/varnishd/builtin.vcl
问题描述
我跟不上官方教程Wordpress with Varnish。我正在使用 wordpress 5.7(当前版本)。
我有网络和 wordpress 方面的经验,我已经用 docker 设置了一个功能测试 wordpress 容器。我还启动了一个 varnish 容器,但第一个问题是 default.vcl 文件——教程中有一个错字,它使用 sub vcl_rec
而不是 sub vcl_recv
。我修复了这个问题,容器成功启动。
我的 default.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+=[^;]+(; )?", "");
set req.http.cookie = regsuball(req.http.cookie, "wp-settings-time-\d+=[^;]+(; )?", "");
set req.http.cookie = regsuball(req.http.cookie, "wordpress_test_cookie=[^;]+(; )?", "");
if (req.http.cookie == "") {
unset req.http.cookie;
}
}
使用这个 vcl,网站成功打开,但没有缓存任何内容。
CHROME 开发工具屏幕截图
这是 Chrome devtools 中网络面板的屏幕截图:
我希望从教程中看到有效的结果,但我认为缺少了一些东西。根据我有限的知识,我知道 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/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
- ReqHeader Accept-Encoding: gzip, deflate, br
- ReqHeader Accept-Language: en-US,en;q=0.9,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", "Chromium";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, deflate, 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 代码只是用来扩展 [built-in VCL][1].
在以下情况下,built-in VCL 仅从缓存中提供 objects:
- 对于
GET
或HEAD
个请求 - 当没有
Cookie
header 存在时 - 当没有
Authorization
header 存在时
删除 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
Don't worry, a cache miss is just a hit that hasn't happened yet.
日志中的 fetch
行表示访问了 WordPress 后端。
为了将获取的 object 存储在缓存中,[built-in VCL][1] 也有一些规则:
- TTL 必须大于零
Cache-Control
header 中不得提及 - 响应中不能有
Set-Cookie
header - 不允许所有 header 的缓存变体(通过
Vary: *
)
no-cache
、no-store
或 private
您返回的响应不会触发任何 non-cacheable 行为,因此 Varnish 决定将 object 存储在缓存中。
下面的 VSL 行说明了这一点:
- TTL RFC 120 10 0 1615741331 1615741331 1615741331 0 0 cacheable
它还暴露了 object 只会被缓存 120 秒。这是因为您的 WordPress 没有设置 Expires
或 Cache-Control
header。
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 没有通过缓存 header 设置 TTL,所以使用 default_ttl
参数的值,默认为 120秒。
但是,您的 Google Chrome 开发人员工具屏幕截图显示带有 Age: 4
header 的 HTTP 响应。这意味着在这种情况下,页面是从缓存中提供的,并且已在缓存中存储了 4 秒。
可能因为生存时间短,您假设页面没有缓存,但事实并非如此。
有两种方法可以解决这个问题:
- 在您的 WordPress 或网络服务器中设置
Cache-Control: public, max-age=3600
响应 header 以增加 TTL - 写一些 VCL 来绕过 TTL。
这里有一些您可以添加到您的 VCL 文件中的 VCL:
sub vcl_backend_response {
set beresp.ttl = 1h;
}
对于缓存中存储的每种 object 类型,此代码段会将 TTL 设置为一个小时。 [1]: https://github.com/varnishcache/varnish-cache/blob/6.0/bin/varnishd/builtin.vcl