CloudFront 如何配置按查询参数区分的缓存302重定向

问题根因 #

• 当前遇到的缓存错配（不同code参数的请求命中同一旧重定向），核心原因是CloudFront生成的缓存键没有将code、country这两个直接影响重定向结果的查询参数纳入计算范围。
• 现有配置下，只要请求路径为/path，无论后续携带的查询参数是什么，都会被匹配到同一个缓存条目。因此第一次请求生成的、带code=1234的302响应，会被复用到所有同路径的后续请求上。

可落地的配置方法（无需强制每次请求触发重定向Lambda） #

只要缓存键和请求的参数组合完全匹配，CloudFront完全可以直接返回存储的302响应，不需要回源调用Lambda，具体配置分为两步：

1. 调整关联的缓存策略（Cache Policy）
   • 在缓存策略的查询参数配置项中，明确将code、country两个参数加入缓存键的计算范围。不要使用无差别转发全部查询参数的粗放配置，也不要将和重定向逻辑无关的参数纳入缓存键，否则会因为参数组合过多大幅拉低整体缓存命中率。
   • 确认策略允许缓存3xx类响应：只要重定向生成端返回的响应携带合规的Cache-Control头（例如public, max-age=86400），CloudFront就会按照规则将302响应存储到对应缓存键下，不会默认跳过3xx响应的缓存。
2. 校准重定向生成端的返回逻辑
   • 返回302时，必须从当前请求的查询参数中提取code值，动态拼接到目标重定向URL上，不要硬编码固定的参数值。
   • 按照传入的country参数匹配对应目标域名：无country参数时默认跳转abc123.com，country=CA时跳转abc123.ca，country=MX时跳转abc123.mx。
   • 所有302响应统一添加可缓存的Cache-Control头，不要返回no-store、private这类禁止节点缓存的响应头。

需要强制将请求转发到重定向Lambda的场景 #

这类场景不是CloudFront的配置强制要求，是业务逻辑本身的特性导致的，常见情况包括：

• 重定向判断依赖的信息没有纳入缓存键：比如需要根据访客IP、Cookie、User-Agent动态决定跳转域名，这类信息如果没有作为缓存键的组成部分，存储的缓存响应无法适配不同访客的判断结果，就必须每次请求触发Lambda实时生成重定向。
• 业务参数组合量级过大：如果code、country的参数取值是完全无重复的海量值，即使配置了正确的缓存键，也会因为绝大多数请求都是首次出现的参数组合，导致缓存命中率极低，表现为几乎每次请求都要回源触发Lambda，但这是业务场景导致的命中率问题，不是配置层面的限制。

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