我正在使用 Next.js 自定义服务器，默认情况下，它会在每个页面 GET 请求上发送强大的 ETag 标头。对于每个请求，我还手动添加 Cache-Control 标头 res.setHeader('Cache-Control', 'public, max-age=${60 * 60}, s-maxage=${60 * 60 * 24}, must-revalidate')
我还在使用 Cloudflare 的负载平衡和缓存机制。根据此文档https://support.cloudflare.com/hc/en-us/articles/218505467-Using-ETag-Headers-with-Cloudflare，我满足了与强 ETag 相关的每个要求。页面规则配置如下： page rule configuration screenshot。
第一个奇怪的行为是在头文件中的客户端上，我注意到由于某种原因弱 ETag。缓存的行为也有点奇怪。如果我要打开一个新的站点帖子，我通常会遇到 cf-cache-status: HIT 标头，这意味着 Cloudflare 已经为此特定帖子准备了缓存。我的期望是在同一个选项卡中的 page reloading 之后，页面将重新创建表单 disk cache，但由于某种原因它发出请求，其结果是状态 304（未修改）。但是，如果我将复制 url 并在新选项卡中打开相同的帖子，它将从磁盘缓存中重新创建（应该如此），并且在页面重新加载后，它会发出响应 304（未修改）的请求。
直接源服务器请求-响应：
General:
Request URL: ...
Request Method: GET
Status Code: 200 OK
Remote Address: ...
Referrer Policy: strict-origin-when-cross-origin
Response headers:
cache-control: public, max-age=3600, s-maxage=86400, must-revalidate
connection: keep-alive
content-encoding: gzip
content-type: text/html; charset=utf-8
date: Thu, 28 Jan 2021 13:02:42 GMT
etag: "62e33-f1yLCVYVUzVH67UMp/2WOxQqfC8"
transfer-encoding: chunked
vary: Accept-Encoding
x-powered-by: Next.js
Request headers:
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
Accept-Encoding: gzip, deflate, br
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7,uk;q=0.6
Cache-Control: no-cache
Connection: keep-alive
Cookie: _ga=GA1.1.1009400285.1608315387; _gid=GA1.1.1795438935.1611755271; _gat=1
Host: ip_here
Pragma: no-cache
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
Cloudflare 代理请求-响应：
General:
Request URL: ...
Request Method: GET
Status Code: 200
Remote Address: ...
Referrer Policy: strict-origin-when-cross-origin
Response headers:
age: 44448
cache-control: public, max-age=3600, s-maxage=86400, must-revalidate
cf-cache-status: HIT
cf-ray: 618ac665c984351f-KBP
cf-request-id: 07ea9a539d0000351f0faf7000000001
content-encoding: br
content-type: text/html; charset=utf-8
date: Thu, 28 Jan 2021 12:39:13 GMT
etag: W/"62e33-vLyavPBB7axQJnhj/OKdPyUNp+A"
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
nel: {"max_age":604800,"report_to":"cf-nel"}
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=4ASHxxkyb8necnQhGaz8th4W%2FcFEwzrBwYiidFGsHK5ZZJ%2BGEYWbmOlDSC2Uep2TYw8vYUm0DL4WkrdC9xsIK%2F6j0G1QF%2BK5817fQQ%3D%3D"}],"max_age":604800,"group":"cf-nel"}
server: cloudflare
vary: Accept-Encoding
x-powered-by: Next.js
Request headers:
:authority: ...
:method: GET
:path: ...
:scheme: https
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
accept-encoding: gzip, deflate, br
accept-language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7,uk;q=0.6
cache-control: max-age=0
cookie: _ga=GA1.2.33365049.1592837735; __cfduid=d58947d60ae6adfce59e944d190e702ae1610627770; _gid=GA1.2.788163791.1611406644; connect.sid=s%3AfLFtBQSejs6Jf0gkdqiRhyzAnu8ImE_J.KukkQj15FMXkfcW6alO6BPUYT8SgPWRqtu2xo2QRe8U; __cflb=0H28urhoa5eNWhDb7XVCL24Hq5fwW5bc37oc693mgWx; _gat=1
sec-fetch-dest: document
sec-fetch-mode: navigate
sec-fetch-site: same-origin
sec-fetch-user: ?1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
为什么会这样？理想情况下，我想在最近一小时内从磁盘缓存重新创建页面，并在它发出重新验证请求之后。并每天从源服务器重新验证 Cloudflare 的缓存。
您可以在标头中看到源服务器和 cloudflare 的 ETag 不同