使用Managed-CachingOptimized的CloudFront/S3缓存失效率达60%，是什么原因？

核心原因定位 #

你的问题90%以上概率来自以下三个常见配置/机制问题：

1. 缓存键包含Accept-Encoding头，不同客户端请求头差异导致多份缓存副本 #

CloudFront官方Managed-CachingOptimized策略默认会将Accept-Encoding请求头纳入缓存键计算：

• 浏览器发起请求时携带的Accept-Encoding一般为gzip, deflate, br等多压缩格式组合
• 原生curl默认不会携带Accept-Encoding头，或仅携带gzip
  两者的Accept-Encoding值不同，会被CloudFront判定为两个不同的缓存对象，因此浏览器命中的缓存副本，curl发起请求时会判定为Miss，需要重新回源拉取生成新的缓存副本。
  对于你存放在thumbs路径下的jpg格式图片，本身已经是压缩后的二进制文件，CloudFront不会对其进行二次压缩，Accept-Encoding头对这类资源完全无意义，纳入缓存键只会导致不必要的多副本缓存，拉低命中率。

2. CloudFront边缘节点缓存相互独立 #

CloudFront全球数百个边缘节点的缓存是完全独立的，不同地域、不同运营商的客户端会被DNS路由到不同的边缘节点。如果你的浏览器请求和curl请求的网络出口不同，会被分配到不同的边缘节点，自然无法共享缓存，出现一端命中一端Miss的情况。
你可以通过响应头中的x-amz-cf-pop字段确认请求命中的边缘节点ID，两次请求该值不同即可验证该问题。

3. 路径匹配行为配置差异 #

CloudFront的分发行为按路径优先级匹配，如果你单独为/thumbs/*路径配置了更高优先级的独立行为，且该行为的缓存策略和默认行为不同（比如转发了额外的请求头、查询字符串或Cookie），也会导致该路径下的资源命中率远低于其他路径。

解决方案 #

• 优先检查分发行为配置：确认/thumbs/*路径对应的缓存策略是否和其他路径一致，有没有额外配置需要纳入缓存键的参数
• 自定义缓存策略移除无用请求头：针对图片类静态资源，新建自定义缓存策略，将Accept-Encoding从缓存键中移除，所有客户端请求共享同一份缓存副本，可直接大幅提升缓存命中率
• 验证Accept-Encoding影响：执行以下curl命令模拟浏览器请求头，测试是否能命中缓存：
  curl -I -H "Accept-Encoding: gzip, deflate, br" <你的CloudFront缩略图访问链接>
  如果返回x-cache: Hit from cloudfront即可确认问题根源。

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