如何配置CloudFront实现max-age有效期本地缓存并解决miss问题

接入自定义源站，目标实现浏览器本地缓存效果：

• 当前源站默认返回的Cache-Control响应头为no-store, no-cache, must-revalidate，pre-check与post-check参数均设置为0，与缓存需求完全相反
• 预期缓存规则：浏览器缓存资源，在max-age设定的24小时（即86400s）有效期到期前不发起重验证；因业务涉及用户私有数据，需确保不同用户间不会出现数据泄露

已完成配置：通过响应头策略将Cache-Control覆盖为private, max-age=86400，但测试中仅收到HTTP 200响应（预期为304响应），且响应头x-cache字段始终显示miss from cloudfront。

• 协议匹配策略：Match Viewer
• SSL配置：TLSv1.1（使用AWS托管的自定义证书）
• 支持的HTTP方法：GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
• 访问权限：Unrestricted viewer access
• 旧版缓存规则：Headers(None)、Query strings (ALL)、Cookies (None)
• 对象缓存策略：Use origin headers
• 响应头策略：自定义Cache-Control值为private, max-age=86400
• 其余规则：仅针对无需缓存的文件夹设置了CachingDisabled规则

核心根因 #

1. 配置逻辑顺序错误：CloudFront的对象缓存判定发生在拉取源站响应之后、执行响应头修改策略之前。你设置的Use origin headers策略会让CloudFront优先遵从源站返回的no-store规则，直接不在边缘节点存储任何资源，每次请求全量回源，因此x-cache永远显示miss from cloudfront。后续响应头策略修改Cache-Control的操作，仅作用于返回给用户的最终响应，不会改变CloudFront自身的缓存判定逻辑。
2. 缓存规则存在数据泄露风险：当前旧版缓存规则将Headers、Cookies均设置为不纳入缓存键，即使开启边缘缓存，CloudFront会将不同用户的同路径请求判定为同一资源，直接把A用户的私有数据返回给B用户，不符合私有数据的安全要求。
3. 测试预期存在误区：当max-age=86400生效时，浏览器在24小时有效期内会直接读取本地缓存，不会向服务端发起任何请求，此时根本不会产生服务端响应，自然看不到304状态码。304仅在浏览器发起条件请求（如强制刷新、缓存过期后重验证）、服务端判定资源未修改时才会返回。

修复步骤 #

1. 调整对象缓存策略，弃用Use origin headers配置：
   • 如果你仅需要浏览器本地缓存，不需要CloudFront边缘缓存私有数据：直接将对应路径的缓存策略TTL全部设置为0（即禁用CloudFront边缘缓存），保留现有响应头的private, max-age=86400配置即可。此时CloudFront每次回源拉取最新内容，将正确的缓存头返回给浏览器，浏览器首次加载拿到200响应后，24小时内直接读本地缓存，不会发起重复请求。
   • 如果你需要CloudFront边缘缓存私有内容以降低回源压力：将默认TTL、最大TTL均设置为86400，最小TTL设置为0；同时调整缓存键规则，将用户鉴权相关的Cookie（如会话Cookie）、请求头（如Authorization及业务自定义的用户身份标识头）全部纳入缓存键，Query strings保留全量转发配置，确保每个用户的缓存资源独立隔离，不会出现跨用户数据泄露。注意此场景下要把Cache-Control里的private指令去掉，private会告知所有共享缓存（含CDN节点）禁止存储响应，会导致边缘缓存不生效。
2. 清理冲突响应头：在响应头策略中删除源站返回的Pragma: no-cache、Expires: 0等和缓存规则冲突的头，避免浏览器识别到冲突头后不执行本地缓存。
3. 正确验证效果：首次访问资源拿到200响应后，关闭浏览器开发者工具的「禁用缓存」选项，二次访问同资源时优先看浏览器开发者工具的网络面板，若请求显示「(from disk cache)」或「(from memory cache)」即代表本地缓存生效；等24小时缓存过期后，或手动按F5普通刷新，才会触发条件请求，此时才可能返回304状态码。

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