CloudFront 控制台里有两个名字很接近的配置：Cache Policy（缓存策略）和 Origin Request Policy（源站请求策略）。两者都能选择 Headers、Cookies 和查询参数，但用途不同。缓存策略决定哪些请求值参与缓存键，也就是 CloudFront 用什么条件区分缓存对象；源站请求策略决定缓存未命中时，还要把哪些不参与缓存键的信息转发给源站。

配错后的表现很典型。把用户代理、会话 Cookie 或大量查询参数塞进缓存键，缓存会被切成许多小份，命中率随之下降。反过来，源站依赖某个 Header，CloudFront 却没有转发它，源站可能返回错误语言、错误设备版本，甚至直接拒绝请求。

先弄清楚缓存键和回源请求

访问者请求到达 CloudFront 后，CloudFront 会根据缓存策略生成缓存键。键值对应的对象已经在边缘缓存中时，CloudFront 直接返回缓存内容；没有命中时，它再向源站发起请求。

进入缓存键的 Headers、Cookies 和查询参数会自动包含在回源请求中。源站请求策略处理的是另一部分信息：源站需要看到，但不应该用来区分缓存版本的请求值。

举个例子。网站使用 lang=zh-CN 决定页面语言，同时携带 utm_source=newsletter 做流量统计。语言参数会改变页面内容，适合放进缓存策略；utm_source 不应制造新的页面副本，如果源站确实要记录它，可以通过源站请求策略转发。若统计由前端完成，连回源也没有必要。

两种策略分别控制什么

源站请求策略不能补救错误的缓存设计。假如源站根据某个 Cookie 返回不同内容，而这个 Cookie 只被转发、没有进入缓存键，CloudFront 仍可能把首次回源得到的版本缓存下来，再提供给其他 Cookie 值的请求。只要一个请求值会改变可缓存响应，它就应该进入缓存键，或者该响应应明确禁止共享缓存。

Headers 应该怎么选

Header 很容易造成缓存碎片。同一个浏览器请求中可能包含 User-Agent、Referer、追踪字段和大量客户端提示。把所有 Viewer Headers 都用于缓存区分，常常会产生数量惊人的缓存变体。

适合进入缓存键的 Header 通常满足两个条件：源站确实根据它返回不同内容，而且取值范围可控。图片服务根据规范化后的 Accept 返回 AVIF、WebP 或 JPEG，是一个常见例子。即便如此，也应先把原始值归并成少量类别，再参与缓存键，避免每种浏览器字符串都生成独立对象。

只供源站记录或鉴权、不会改变共享响应内容的 Header，可以放进源站请求策略。源站完全不需要的 Header 不应转发。这样既减少回源数据，也能降低无意泄露客户端信息的风险。

Authorization 需要单独检查。AWS 文档规定，不能把它作为单独 Header 加入 Origin Request Policy 的 allowlist。需要转发时，可采用包含该 Header 的缓存策略，或使用转发所有 Viewer Headers 的源站请求策略。授权响应通常包含用户差异，缓存前必须审查访问隔离，不能只解决“Header 有没有送到源站”。

Cookies 应该怎么选

不少站点为了方便，直接转发全部 Cookies。这个设置对缓存命中率很不友好。分析、广告、A/B 测试和会话系统可能不断增加 Cookie；其中任何一个进入缓存键，都会扩展缓存组合。

处理 Cookie 时可以逐项判断：

• Cookie 是否会改变响应正文、状态码、重定向位置或权限结果？会改变时，放入缓存策略，或让响应不进入共享缓存。

• Cookie 是否只供源站记录，返回内容始终相同？确有回源需求时，放入源站请求策略。

• Cookie 是否与源站处理无关？不要转发。

登录态页面尤其要谨慎。仅把会话 Cookie 转发给源站，却让不同用户共用一个缓存键，可能造成越权内容被缓存。账户、订单和控制台页面通常应关闭共享缓存，或建立经过安全验证的隔离方案。

查询参数应该怎么选

查询参数往往混合了内容参数和追踪参数。前者决定响应，后者只描述访问来源。

例如：

• ?page=2、?lang=en、?format=webp 可能改变返回内容，需要按业务逻辑进入缓存键。

• ?utm_source=、?utm_campaign=、?gclid= 通常不改变页面内容，不宜加入缓存键。

• 签名参数、临时令牌和用户标识涉及权限或私有内容，需要结合签名验证和缓存范围处理，不能套用普通追踪参数规则。

如果参数顺序和无关参数导致大量重复 URL，可以在 Viewer Request 阶段用 CloudFront Functions 做规范化，例如删除已确认无用的追踪参数，再执行缓存查找。上线前应确认被删除的参数没有参与页面渲染、跳转、授权或统计归因。

TTL 设置也在缓存策略里

Cache Policy 还负责 Minimum TTL、Default TTL 和 Maximum TTL。三者会和源站返回的 Cache-Control、Expires 一起决定对象保留时间。

Minimum TTL 最容易被忽略。当它大于 0 时，即使源站响应包含 Cache-Control: no-cache、no-store 或 private，CloudFront 仍可能至少缓存到 Minimum TTL 指定的时间。涉及个人数据、登录状态或实时权限的行为，应把 Minimum TTL 设为 0，并检查源站响应头和缓存行为。

Default TTL 用于源站没有提供有效缓存时间时，Maximum TTL 则限制 CloudFront 可采用的最长缓存时间。静态文件、HTML、API 不宜共用一组粗放的 TTL。按路径和内容类型拆分 Cache Behavior，通常更容易控制。

一个可复用的配置示例

假设商品列表页使用以下请求信息：

• lang 查询参数决定语言。

• currency Cookie 决定显示币种。

• utm_source 查询参数用于源站访问分析。

• session_id Cookie 只影响源站日志，不改变匿名列表内容。

• User-Agent 不参与内容生成。

可以先采用下面的设计：

这套配置会形成“语言 × 币种”的缓存组合。支持 4 种语言和 3 种币种时，每个 URL 最多产生 12 个主要版本；如果再把大量营销参数和原始 User-Agent 加进去，组合数会迅速扩大。

Managed Policy 还是自定义策略

AWS 提供多种 Managed Cache Policies 和 Managed Origin Request Policies。托管策略适合常见场景，也便于快速开始。使用前仍要打开策略详情，确认 TTL、Headers、Cookies、查询参数和压缩设置是否符合当前业务。

常见做法包括：

• 静态资源使用针对缓存优化的托管缓存策略，不转发无关 Cookies 和查询参数。

• 需要向源站发送全部 Viewer Headers 的场景，选择相应托管源站请求策略，同时检查缓存和隐私风险。

• API 或动态页面根据实际响应规则定制策略，不因名称看起来接近就直接套用。

托管策略由 AWS 维护，不能编辑。需要调整字段或 TTL 时，创建自定义策略，并通过名称和说明写清用途。多条 Cache Behavior 复用同一策略时，修改会同时影响所有关联行为，变更前要列出影响范围。

常见配置错误

把所有 Viewer Headers 放进缓存键

缓存版本会被浏览器、设备和网络环境不断切分。先确认源站使用哪些 Header，再把原始值规范化成有限类别。

只转发影响内容的值，却不让它参与缓存键

源站能收到参数，不代表 CloudFront 能区分响应。只要该值改变可缓存内容，就需要进入缓存键。

把追踪参数放进缓存键

utm_* 和广告点击标识通常会制造重复缓存。可在边缘删除、仅回源转发，或改由前端分析工具采集。

Minimum TTL 与私有响应冲突

Minimum TTL 大于 0 时可能覆盖源站的 no-cache、no-store 和 private 指令。用户相关路径应单独检查。

一个策略覆盖所有路径

静态资源、公开 HTML、匿名 API 和登录页面的缓存需求不同。按 Cache Behavior 分开设计更安全，也便于排查。

如何排查命中率下降或内容错乱

先查看 CloudFront 响应中的 X-Cache，再结合标准日志或实时日志确认请求路径、查询参数和缓存结果。若变更策略后命中率下降，可以按以下顺序检查：

1. 对比新旧缓存策略，找出新增的 Header、Cookie 和查询参数。

2. 统计这些值的基数。一个字段如果每天出现数千种取值，进入缓存键后通常会明显拆分缓存。

3. 确认源站是否真的根据这些值改变响应。

4. 检查 CloudFront Functions 或 Lambda@Edge 是否在缓存查找前修改了请求。

5. 核对 Minimum、Default、Maximum TTL，以及源站的 Cache-Control。

6. 对内容错乱问题，用不同 Cookie、Header 和查询参数重复请求，比较响应正文、Age、ETag 和 X-Cache。

策略调整后，已有缓存对象不会因为策略逻辑变化而自动变成新设计的一部分。必要时进行有范围的缓存失效，或使用版本化 URL。大范围失效会降低短期命中率，也可能产生额外费用。

上线前检查清单

• 列出所有会改变响应内容、状态码、跳转和权限结果的请求值。

• 这些值进入缓存键，或对应响应明确不使用共享缓存。

• 只供日志和源站处理的信息按需放入源站请求策略。

• 删除无用途的 Headers、Cookies 和查询参数。

• 检查 Authorization、会话 Cookie、签名参数和用户标识。

• 用户相关路径的 Minimum TTL 为 0，并验证源站缓存指令。

• 用多组请求值测试缓存隔离，同时观察命中率。

• 记录策略与 Cache Behavior 的关联关系，准备回滚方案。

常见问题

Cache Policy 和 Origin Request Policy 可以同时使用吗？

可以。一个 Cache Behavior 通常可以同时关联一项缓存策略和一项源站请求策略。进入缓存键的值会自动回源，源站请求策略再补充需要转发但不参与缓存区分的值。

Origin Request Policy 会降低缓存命中率吗？

它不会直接改变缓存键，因此不会像 Cache Policy 那样生成更多缓存变体。不过，额外转发的信息可能使源站返回不同内容。如果这些差异被存入同一个缓存键，可能出现内容错配。配置时仍要确认响应是否随请求值变化。

所有查询参数都转发给源站，是否等于所有参数都参与缓存？

不等于。源站请求策略可以转发参数而不把它们放进缓存键。缓存策略中的查询参数设置才决定缓存区分。

是否应该转发全部 Cookies？

很少有公开缓存页面需要全部 Cookies。逐项 allowlist 更容易控制缓存组合和隐私风险。动态私有页面应重新评估是否需要 CloudFront 共享缓存。

修改策略后需要立即清除缓存吗？

取决于变更内容和风险。如果旧缓存可能被错误复用，应执行有范围的失效或更换版本化 URL。仅增加源站日志字段时，通常没有必要清除所有对象。上线前应在测试分配或测试路径验证。

结论

缓存策略负责缓存键、TTL 和压缩缓存设置；源站请求策略负责回源时附加转发的信息。进入缓存键的请求值会自动发送给源站，因此无需在两项策略中重复配置。

配置时先列出会改变响应的请求值，再决定缓存隔离。日志、分析和源站辅助字段单独处理。这样做能控制缓存变体，也能降低不同用户或内容版本共用缓存对象的风险。

参考资料

1. AWS CloudFront Developer Guide: Understand the cache key，核查日期：2026-08-19
   https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/understanding-the-cache-key.html

2. AWS CloudFront Developer Guide: Control the cache key with a policy，核查日期：2026-08-19
   https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-the-cache-key.html

3. AWS CloudFront Developer Guide: Control origin requests with a policy，核查日期：2026-08-19
   https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.html

4. AWS CloudFront Developer Guide: Use managed cache policies，核查日期：2026-08-19
   https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-cache-policies.html

5. AWS CloudFront Developer Guide: Use managed origin request policies，核查日期：2026-08-19
   https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-origin-request-policies.html