清漆，是什么导致了 hit-for-pass？
Varnish, What is causing hit-for-pass?
这是清漆日志（已编辑 - 已扩展以提供更多信息）：
* << Request >> 172651
- Begin req 172650 rxreq
- Timestamp Start: 1455791132.581465 0.000000 0.000000
- Timestamp Req: 1455791132.581465 0.000000 0.000000
- ReqStart 127.0.0.1 47991
- ReqMethod GET
- ReqURL /
- ReqProtocol HTTP/1.1
- ReqHeader X-Real-IP: x.x.x.x
- ReqHeader X-Forwarded-For: x.x.x.1, x.x.x.2
- ReqHeader X-Forwarded-Proto: https
- ReqHeader X-Forwarded-Port: 443
- ReqHeader Host: mydomain.com
- ReqHeader User-Agent: Go-http-client/1.1 (//benchmark app, but regular browser client happens the same
- ReqHeader Cf-Connecting-Ip: x.x.x.x
- ReqHeader Cf-Ipcountry: AND
- ReqHeader Cf-Origin-Https: off
- ReqHeader Cf-Ray: 27690752ab232e21-NRT
- ReqHeader Cf-Visitor: {"scheme":"https"}
- ReqUnset X-Forwarded-For: x.x.x.1, x.x.x.2
- ReqHeader X-Forwarded-For: x.x.x.ext, x.x.x.1, x.x.x.2
- VCL_call RECV
- VCL_return hash
- VCL_call HASH
- VCL_return lookup
- Debug "XXXX HIT-FOR-PASS"
- HitPass 393349
- VCL_call PASS
- VCL_return fetch
- Link bereq 172652 pass
- Timestamp Fetch: 1455791132.581733 0.000268 0.000268
- RespProtocol HTTP/1.1
- RespStatus 200
- RespReason OK
- RespHeader Server: nginx
- RespHeader Date: Thu, 18 Feb 2016 10:25:32 GMT
- RespHeader Content-Type: text/html; charset=utf-8
- RespHeader Vary: Accept-Encoding, Accept-Encoding
- RespHeader Etag: "1455788472-0"
- RespHeader Content-Language: ja
- RespHeader Cache-Control: no-cache
- RespHeader Last-Modified: Thu, 18 Feb 2016 09:41:12 GMT
- RespHeader X-Content-Options: nosniff
- RespHeader X-Micro-Cache: HIT
- RespHeader X-Varnish: 172651
- RespHeader Age: 0
- RespHeader Via: 1.1 varnish-v4
- VCL_call DELIVER
- VCL_return deliver
- Timestamp Process: 1455791132.581744 0.000279 0.000011
- RespHeader Accept-Ranges: bytes
- RespHeader Transfer-Encoding: chunked
- Debug "RES_MODE 8"
- RespHeader Connection: keep-alive
- Timestamp Resp: 1455791132.581794 0.000329 0.000049
- ReqAcct 336 0 336 436 57069 57505
- End
我读到这是在设置 set-cookie header 或 cache-control: max-age=0 时创建的。
好吧，我在我的子 vcl_backend_response 中有这个试图避免传球命中。这很粗鲁，但我不知道后端是什么导致了这次通过：
sub vcl_backend_response {
unset beresp.http.set-cookie;
unset beresp.http.expires;
set beresp.http.Cache-Control = "max-age=6000";
}
我正在摆脱 Expire，因为它被设置为时间戳 0。所以我认为可能是这样。然后我试着玩 Cache-control 但还是一样。我即将以这种速度取消所有 headers...
毕竟是304响应，为什么不缓存呢？
更多信息：后端是一个 Drupal 应用程序。
编辑 1：关于 vcl_recv
是的，我确实有一些东西，我正在返回某些路径的通行证（不是我正在检查的路径），我正在取消设置文件的 cookie，我正在取消所有非 drupal 的 cookie session对于其余的。它或多或少是 copy/paste drupal 默认子 vcl_recv。如果你想要我可以在这里复制。
顺便说一句，我更改了其他内容，现在我在响应 200 中也通过了测试（但是当我使用基准测试工具时）。有人删除了说可能是因为响应 304 的答案。我正在检查那个，但答案不见了:(
好的，这是 vcl_recv:
sub vcl_recv {
if (req.url ~ "^/status\.php$" ||
req.url ~ "^/admin/.*$" ||
[...]
req.url ~ "^.*\.js.*$" )
{
return (pass);
}
if (req.url ~ "^/admin/content/backup_migrate/export") {
return (pipe);
}
## COOKIES ##
if (req.url ~ "(?i)\.(css|js|jpg|jpeg|gif|png|ico|svg|map)(\?.*)?$") {
unset req.http.Cookie;
}
if (req.http.Cookie) {
set req.http.Cookie = ";" + req.http.Cookie;
set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|SSESS[a-z0-9]+|NO_CACHE)=", "; =");
set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");
if (req.http.Cookie == "") {
unset req.http.Cookie;
}
# if any of our cookies of interest are still there, we disable caching and pass the request
else {
return (pass);
}
}
}
它几乎总是在所有 http. 304 个响应和 200 个响应。我已经编辑了上面的 varnishlog 以显示完整示例以提供更多信息。
编辑：
所以这是在显示命中通过之前的请求日志。肯定是传球命中率的罪魁祸首：
- ReqHeader X-Forwarded-For: 127.0.0.1
- VCL_return hash
- VCL_call HASH
- VCL_return lookup
- VCL_call MISS
- VCL_return fetch
- Link bereq 3 fetch
- Timestamp Fetch: 1456731597.992472 0.099948 0.099948
- RespProtocol HTTP/1.1
- RespStatus 200
- RespReason OK
- RespHeader Date: Mon, 29 Feb 2016 07:39:57 GMT
- RespHeader Content-Type: text/html; charset=utf-8
- RespHeader Content-Encoding: gzip
- RespHeader Vary: Accept-Encoding
- RespHeader Etag: "1456730796-0"
- RespHeader Content-Language: ja
- RespHeader Cache-Control: no-cache
- RespHeader Last-Modified: Mon, 29 Feb 2016 07:26:36 GMT
- RespHeader Expires: Thu, 01 Jan 1970 00:00:01 GMT
- RespHeader X-Content-Options: nosniff
- RespHeader X-Micro-Cache: EXPIRED
- RespHeader X-Varnish: 2
- RespHeader Age: 0
- RespHeader Via: 1.1 varnish-v4
- RespUnset Etag: "1456730796-0"
- RespHeader ETag: W/"1456730796-0"
- VCL_call DELIVER
- RespHeader X-Cache: MISS
- RespHeader X-Cache-Hits: 0
- RespUnset X-Varnish: 2
- RespUnset Via: 1.1 varnish-v4
- VCL_return deliver
- Timestamp Process: 1456731597.992517 0.099993 0.000044
- RespUnset Content-Encoding: gzip
- RespHeader Accept-Ranges: bytes
- RespHeader Content-Length: 53980
- Debug "RES_MODE 42"
- RespHeader Connection: keep-alive
- Gzip U D - 12752 53980 80 101936 101946
- Timestamp Resp: 1456731597.992817 0.100293 0.000300
- ReqAcct 746 0 746 437 53980 54417
您的问题可能恰恰是 304 响应：
清漆 3 书说：
Only the following status codes will be cached by default:
200: OK
203: Non-Authoritative Information
300: Multiple Choices
301: Moved Permanently
302: Moved Temporarily
307: Temporary Redirect
410: Gone
404: Not Found
You can still cache other status codes, but you will have to set the
beresp.ttl to a positive value in vcl_fetch yourself.
令我惊讶的是，Varnish 4 书中还提到“304：未修改”是可缓存的。 http://book.varnish-software.com/4.0/chapters/VCL_Basics.html
这对我来说没有意义，因为如果 Varnish 正在缓存条件请求的 304 响应，那么对同一资源的每个非条件请求也应该得到没有响应主体的 304 响应，这似乎毫无用处。
这个问题太长了，恐怕对其他人也没有用。
感谢其他答案给出的 link 我看到了这个（vcl_backend_response 的默认实现）：
sub vcl_backend_response {
if (beresp.ttl <= 0s ||
beresp.http.Set-Cookie ||
beresp.http.Surrogate-control ~ "no-store" ||
(!beresp.http.Surrogate-Control &&
beresp.http.Cache-Control ~ "no-cache|no-store|private") ||
beresp.http.Vary == "*") {
/*
* Mark as "Hit-For-Pass" for the next 2 minutes
*/
set beresp.ttl = 120s;
set beresp.uncacheable = true;
}
return (deliver);
}
这就是所有命中传球的条件。多亏了它，我可以看到导致通过命中的原因正是这个 beresp.ttl <=0。
那么哪个值有 beres.ttl？在同一个 link 上，我们读到： beresp.ttl 被初始化为它在
中找到的第一个值
The s-maxage variable in the Cache-Control response header field
The max-age variable in the Cache-Control response header field
The Expires response header field
The default_ttl parameter.
修改vcl_backend_response中的header没关系，因为ttl已经设置好了！
很好，看看我的 headers 我可以从后端看到：
- RespHeader Expires: Thu, 01 Jan 1970 00:00:01 GMT
这是导致传球成功的原因。这就是我的问题的答案。现在，为什么我有这个 header 我不知道，那将是一个不同的问题。 （我用过期 30d 修改了 nginx；到所有位置都没有结果）
这是清漆日志（已编辑 - 已扩展以提供更多信息）：
* << Request >> 172651
- Begin req 172650 rxreq
- Timestamp Start: 1455791132.581465 0.000000 0.000000
- Timestamp Req: 1455791132.581465 0.000000 0.000000
- ReqStart 127.0.0.1 47991
- ReqMethod GET
- ReqURL /
- ReqProtocol HTTP/1.1
- ReqHeader X-Real-IP: x.x.x.x
- ReqHeader X-Forwarded-For: x.x.x.1, x.x.x.2
- ReqHeader X-Forwarded-Proto: https
- ReqHeader X-Forwarded-Port: 443
- ReqHeader Host: mydomain.com
- ReqHeader User-Agent: Go-http-client/1.1 (//benchmark app, but regular browser client happens the same
- ReqHeader Cf-Connecting-Ip: x.x.x.x
- ReqHeader Cf-Ipcountry: AND
- ReqHeader Cf-Origin-Https: off
- ReqHeader Cf-Ray: 27690752ab232e21-NRT
- ReqHeader Cf-Visitor: {"scheme":"https"}
- ReqUnset X-Forwarded-For: x.x.x.1, x.x.x.2
- ReqHeader X-Forwarded-For: x.x.x.ext, x.x.x.1, x.x.x.2
- VCL_call RECV
- VCL_return hash
- VCL_call HASH
- VCL_return lookup
- Debug "XXXX HIT-FOR-PASS"
- HitPass 393349
- VCL_call PASS
- VCL_return fetch
- Link bereq 172652 pass
- Timestamp Fetch: 1455791132.581733 0.000268 0.000268
- RespProtocol HTTP/1.1
- RespStatus 200
- RespReason OK
- RespHeader Server: nginx
- RespHeader Date: Thu, 18 Feb 2016 10:25:32 GMT
- RespHeader Content-Type: text/html; charset=utf-8
- RespHeader Vary: Accept-Encoding, Accept-Encoding
- RespHeader Etag: "1455788472-0"
- RespHeader Content-Language: ja
- RespHeader Cache-Control: no-cache
- RespHeader Last-Modified: Thu, 18 Feb 2016 09:41:12 GMT
- RespHeader X-Content-Options: nosniff
- RespHeader X-Micro-Cache: HIT
- RespHeader X-Varnish: 172651
- RespHeader Age: 0
- RespHeader Via: 1.1 varnish-v4
- VCL_call DELIVER
- VCL_return deliver
- Timestamp Process: 1455791132.581744 0.000279 0.000011
- RespHeader Accept-Ranges: bytes
- RespHeader Transfer-Encoding: chunked
- Debug "RES_MODE 8"
- RespHeader Connection: keep-alive
- Timestamp Resp: 1455791132.581794 0.000329 0.000049
- ReqAcct 336 0 336 436 57069 57505
- End
我读到这是在设置 set-cookie header 或 cache-control: max-age=0 时创建的。
好吧，我在我的子 vcl_backend_response 中有这个试图避免传球命中。这很粗鲁，但我不知道后端是什么导致了这次通过：
sub vcl_backend_response {
unset beresp.http.set-cookie;
unset beresp.http.expires;
set beresp.http.Cache-Control = "max-age=6000";
}
我正在摆脱 Expire，因为它被设置为时间戳 0。所以我认为可能是这样。然后我试着玩 Cache-control 但还是一样。我即将以这种速度取消所有 headers...
毕竟是304响应，为什么不缓存呢？
更多信息：后端是一个 Drupal 应用程序。
编辑 1：关于 vcl_recv
是的，我确实有一些东西，我正在返回某些路径的通行证（不是我正在检查的路径），我正在取消设置文件的 cookie，我正在取消所有非 drupal 的 cookie session对于其余的。它或多或少是 copy/paste drupal 默认子 vcl_recv。如果你想要我可以在这里复制。
顺便说一句，我更改了其他内容，现在我在响应 200 中也通过了测试（但是当我使用基准测试工具时）。有人删除了说可能是因为响应 304 的答案。我正在检查那个，但答案不见了:(
好的，这是 vcl_recv:
sub vcl_recv {
if (req.url ~ "^/status\.php$" ||
req.url ~ "^/admin/.*$" ||
[...]
req.url ~ "^.*\.js.*$" )
{
return (pass);
}
if (req.url ~ "^/admin/content/backup_migrate/export") {
return (pipe);
}
## COOKIES ##
if (req.url ~ "(?i)\.(css|js|jpg|jpeg|gif|png|ico|svg|map)(\?.*)?$") {
unset req.http.Cookie;
}
if (req.http.Cookie) {
set req.http.Cookie = ";" + req.http.Cookie;
set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|SSESS[a-z0-9]+|NO_CACHE)=", "; =");
set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");
if (req.http.Cookie == "") {
unset req.http.Cookie;
}
# if any of our cookies of interest are still there, we disable caching and pass the request
else {
return (pass);
}
}
}
它几乎总是在所有 http. 304 个响应和 200 个响应。我已经编辑了上面的 varnishlog 以显示完整示例以提供更多信息。
编辑： 所以这是在显示命中通过之前的请求日志。肯定是传球命中率的罪魁祸首：
- ReqHeader X-Forwarded-For: 127.0.0.1
- VCL_return hash
- VCL_call HASH
- VCL_return lookup
- VCL_call MISS
- VCL_return fetch
- Link bereq 3 fetch
- Timestamp Fetch: 1456731597.992472 0.099948 0.099948
- RespProtocol HTTP/1.1
- RespStatus 200
- RespReason OK
- RespHeader Date: Mon, 29 Feb 2016 07:39:57 GMT
- RespHeader Content-Type: text/html; charset=utf-8
- RespHeader Content-Encoding: gzip
- RespHeader Vary: Accept-Encoding
- RespHeader Etag: "1456730796-0"
- RespHeader Content-Language: ja
- RespHeader Cache-Control: no-cache
- RespHeader Last-Modified: Mon, 29 Feb 2016 07:26:36 GMT
- RespHeader Expires: Thu, 01 Jan 1970 00:00:01 GMT
- RespHeader X-Content-Options: nosniff
- RespHeader X-Micro-Cache: EXPIRED
- RespHeader X-Varnish: 2
- RespHeader Age: 0
- RespHeader Via: 1.1 varnish-v4
- RespUnset Etag: "1456730796-0"
- RespHeader ETag: W/"1456730796-0"
- VCL_call DELIVER
- RespHeader X-Cache: MISS
- RespHeader X-Cache-Hits: 0
- RespUnset X-Varnish: 2
- RespUnset Via: 1.1 varnish-v4
- VCL_return deliver
- Timestamp Process: 1456731597.992517 0.099993 0.000044
- RespUnset Content-Encoding: gzip
- RespHeader Accept-Ranges: bytes
- RespHeader Content-Length: 53980
- Debug "RES_MODE 42"
- RespHeader Connection: keep-alive
- Gzip U D - 12752 53980 80 101936 101946
- Timestamp Resp: 1456731597.992817 0.100293 0.000300
- ReqAcct 746 0 746 437 53980 54417
您的问题可能恰恰是 304 响应：
清漆 3 书说：
Only the following status codes will be cached by default:
200: OK 203: Non-Authoritative Information 300: Multiple Choices 301: Moved Permanently 302: Moved Temporarily 307: Temporary Redirect 410: Gone 404: Not FoundYou can still cache other status codes, but you will have to set the beresp.ttl to a positive value in vcl_fetch yourself.
令我惊讶的是，Varnish 4 书中还提到“304：未修改”是可缓存的。 http://book.varnish-software.com/4.0/chapters/VCL_Basics.html
这对我来说没有意义，因为如果 Varnish 正在缓存条件请求的 304 响应，那么对同一资源的每个非条件请求也应该得到没有响应主体的 304 响应，这似乎毫无用处。
这个问题太长了，恐怕对其他人也没有用。
感谢其他答案给出的 link 我看到了这个（vcl_backend_response 的默认实现）：
sub vcl_backend_response {
if (beresp.ttl <= 0s ||
beresp.http.Set-Cookie ||
beresp.http.Surrogate-control ~ "no-store" ||
(!beresp.http.Surrogate-Control &&
beresp.http.Cache-Control ~ "no-cache|no-store|private") ||
beresp.http.Vary == "*") {
/*
* Mark as "Hit-For-Pass" for the next 2 minutes
*/
set beresp.ttl = 120s;
set beresp.uncacheable = true;
}
return (deliver);
}
这就是所有命中传球的条件。多亏了它，我可以看到导致通过命中的原因正是这个 beresp.ttl <=0。
那么哪个值有 beres.ttl？在同一个 link 上，我们读到： beresp.ttl 被初始化为它在
中找到的第一个值The s-maxage variable in the Cache-Control response header field
The max-age variable in the Cache-Control response header field
The Expires response header field
The default_ttl parameter.
修改vcl_backend_response中的header没关系，因为ttl已经设置好了！
很好，看看我的 headers 我可以从后端看到：
- RespHeader Expires: Thu, 01 Jan 1970 00:00:01 GMT
这是导致传球成功的原因。这就是我的问题的答案。现在，为什么我有这个 header 我不知道，那将是一个不同的问题。 （我用过期 30d 修改了 nginx；到所有位置都没有结果）