CloudFront未在资源过期时向源站发送If-None-Match头问题排查

问题背景 #

我正在配置CloudFront，希望资源缓存过期后，CloudFront能向自定义源站发送If-None-Match请求头，这样源站在资源未变更时可以返回304状态码，但目前无法实现该功能。

源站响应头信息 #

源站返回的响应头如下：

HTTP/2 200 
content-type: application/json; charset=utf-8
content-length: 181691
access-control-allow-origin: *
cache-control: max-age=5
date: Fri, 17 Feb 2023 21:16:49 GMT
x-content-type-options: nosniff
x-frame-options: DENY
etag: W/"15-mbAPvGdFm9PuCZHJFTtrwm@3"
vary: Accept-Encoding

源站返回了max-age=5的cache-control头以及格式标准的弱ETag。

当前CloudFront配置 #

• 缓存策略：最小TTL为1，转发Origin及部分x-开头的请求头，转发所有查询字符串，不转发Cookie，开启压缩
• 源站请求策略：设置为AllViewer

请求路径 #

客户端→CloudFront→AWS经典负载均衡器→Kubernetes Pod（处理请求并返回响应）

问题细节 #

资源过期后，CloudFront从未主动向源站发送If-None-Match头。但手动通过curl向CloudFront发送带If-None-Match头的请求时，源站能正常接收并返回正确响应，说明中间节点没有移除该头，问题出在CloudFront未主动发起带该头的请求。

排查思路 #

• 检查缓存键配置：确认缓存键包含的内容（查询字符串、请求头等）是否会导致CloudFront将每次请求视为新缓存项。如果缓存键中包含频繁变化的内容，CloudFront会直接请求新资源，不会复用旧缓存的ETag。
• 验证ETag是否被CloudFront缓存：查看CloudFront返回给客户端的响应头是否包含源站的ETag，或通过CloudFront控制台查看缓存对象详情，确认ETag是否被正确缓存。若未缓存ETag，CloudFront无法发送If-None-Match。
• 排查Vary头的影响：源站返回vary: Accept-Encoding，需确认CloudFront缓存策略是否正确处理Accept-Encoding头。若未根据该头区分缓存，可能导致缓存的ETag与实际请求编码不匹配，跳过条件请求。
• 检查最小TTL的实际作用：当前最小TTL为1秒、max-age为5秒，需确认缓存过期后CloudFront是否触发重新验证流程。可通过CloudFront日志查看缓存过期后的请求是否携带条件请求头。
• 排查请求策略的冲突：AllViewer策略会转发所有Viewer请求头，需确认该策略是否干扰CloudFront默认的条件请求逻辑，比如是否存在限制If-None-Match发送的配置。
• 分析CloudFront访问日志：启用访问日志后，查看cs(If-None-Match)字段，直接确认CloudFront向源站发送的请求中是否包含该头，快速定位问题环节。
• 确认弱ETag兼容性：源站返回的弱ETag格式符合标准（以W/开头），但需确认CloudFront是否因其他原因（如缓存策略限制）未使用该ETag发起条件请求。

内容的提问来源于stack exchange，提问作者Chung Wu