基于响应头配置CloudFront缓存时付费内容缓存异常问题咨询

该问题的核心根因为：CloudFront默认会将同一缓存键的并发请求合并为单个回源请求，若首个请求由未携带有效授权token的用户发起，源站返回的登录重定向响应会被当作公共结果返回给同批次所有并发请求，导致持有效token的用户也拿到错误结果。

方案1：调整缓存规则+关闭目标路径请求合并 #

• 在CloudFront对应缓存策略中，将Authorization请求头纳入缓存键，不同授权状态的请求会被识别为独立缓存条目，不会共享回源结果。
• 在/story/*路径的行为配置中，直接关闭*请求合并（Request Collapsing）*功能，从根源避免并发请求共用回源响应的问题。
• 保留源站原有Cache-Control规则即可：免费内容返回Cache-Control: max-age=3600会被正常缓存，付费内容返回Cache-Control: private, max-age=0, no-cache不会被CloudFront存储，不影响后续请求校验。
• 该方案无需修改业务逻辑，改造成本最低。

方案2：通过CloudFront Functions做边缘路由分流 #

• 编写轻量CloudFront Functions，在Viewer Request阶段处理请求：
  • 若请求携带Authorization头，直接标记为绕过缓存的请求，强制回源校验授权，不参与缓存合并流程。
  • 若请求未携带Authorization头，走正常缓存逻辑，未登录用户请求免费内容可正常命中缓存，请求付费内容会正常返回重定向。
• 该方案边缘函数执行延迟仅为毫秒级，几乎不会影响访问性能，同时能最大限度减少不必要的回源请求。

方案3：源站配置Vary响应头 #

• 所有/story/*路径的响应统一添加Vary: Authorization头，告知CloudFront需要根据Authorization请求头的差异存储不同的缓存副本。
• 付费内容返回的Cache-Control: private头会让CloudFront不存储该类响应，仅免费内容会生成公共缓存条目，缓存碎片化的影响可控。
• 该方案无需修改CloudFront核心配置，仅需调整源站响应头即可落地。

落地注意事项 #

• 配置调整后，建议分别用带有效token、带无效token、不带token三种身份请求同一篇付费文章，验证不会出现响应串用的情况。
• 若你的授权凭证存储在Cookie中而非Authorization头，将上述配置中涉及Authorization的部分替换为对应的Cookie名称即可。

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