如何排查CloudFront重复触发Lambda@Edge缓存请求问题

我配置了如下CloudFront与Lambda@Edge架构：

1. 用户向CDN发起请求（路径不影响，当日结果需保持一致）
2. CloudFront向源站发起请求（调用Lambda确定需获取的S3资源）
3. CloudFront接收响应（调用Lambda写入UTC时区的Expires头部）
4. 用户接收响应

缓存行为设置如下：

• Min TTL：0
• Max TTL：86400（24小时）
• Default TTL：0
• 启用旧版设置以避免Cookie、查询字符串和请求头破坏缓存

已知CloudFront按区域缓存，且每日请求量最多5次，预期单日内每个区域仅触发1次源站请求，但有时会出现当日内间隔数小时的2次请求。

我的疑问：写入当日截止UTC时间的Expires头部（如4月29日写入2025-04-30 00:00:00 UTC）后，此现象是CloudFront缓存机制的正常表现，还是缓存配置存在问题？是否有工具可测试缓存配置？

一、现象是否正常？ #

这种当日内多次触发源站请求的情况并非正常预期，大概率是缓存配置或Lambda@Edge逻辑存在潜在问题，核心原因分析如下：

1. 头部优先级冲突
   CloudFront优先遵循Cache-Control头部的缓存指令，若响应同时存在Expires和Cache-Control，后者优先级更高。如果Lambda@Edge仅写入Expires，但源站S3返回的响应自带Cache-Control（比如默认的no-cache或max-age=0），会直接覆盖Expires的作用，导致CloudFront不缓存或缓存时长极短。
2. 缓存键或Lambda逻辑异常
   • 若在Origin Request阶段的Lambda中修改了请求参数（比如添加自定义头部），会导致CloudFront生成不同的缓存键，即使路径相同也会被视为不同请求，触发重复回源。
   • 需确认Lambda写入Expires的逻辑是否正确：比如是否存在时区转换错误，导致Expires时间被设置为过去或极近的时间，强制CloudFront重新回源。
3. 极端缓存清理（概率极低）
   CloudFront边缘节点可能因故障、缓存空间不足主动清理缓存，但这种情况不会规律地当日内多次出现，可排除为主要原因。

二、缓存配置排查方向 #

1. 校验响应头部
   查看CloudFront返回给用户的响应头部，确认是否同时存在Cache-Control和Expires，以及Expires时间是否正确设置为当日UTC午夜。如果Cache-Control存在，建议在Lambda@Edge中同时写入Cache-Control: max-age=xxx（xxx为当前时间到当日UTC午夜的秒数），确保CloudFront遵循预期缓存时长。
2. 验证缓存键规则
   在CloudFront控制台的「缓存行为」中，确认「缓存键和源请求设置」仅包含路径（旧版设置下应忽略Cookie、查询字符串、请求头）；同时通过CloudFront访问日志的cs_uri_query、cookies字段，确认请求是否携带意外参数导致缓存键不一致。
3. 检查Lambda执行日志
   在CloudWatch中查看Lambda@Edge的执行日志，确认Expires头部是否被正确写入，以及是否存在执行错误导致头部未生效。

三、缓存配置测试工具 #

1. CloudFront访问日志
   开启标准访问日志，通过分析x_edge_result_type字段：Hit表示命中缓存，Miss表示未命中触发回源。统计同一区域内每日的Miss次数，定位异常请求的时间和参数。
2. curl命令行测试
   发送请求并查看响应头部，重点关注缓存相关字段：

   curl -v https://your-cloudfront-domain/path
   

   需检查X-Cache（显示Hit/Miss）、Expires、Cache-Control字段的内容。
3. CloudFront控制台监控
   在控制台「监控」选项卡中，查看「缓存命中率」指标和「边缘请求」分布，判断是否存在异常的缓存未命中情况。

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