Vary 响应头的双刃剑效应

Vary 是标准 HTTP 响应头，用于告知中间缓存（如 CDN）哪些请求头字段可能影响源站响应。例如同一 URL 可根据 Accept 头返回 HTML 或 JSON。缺少 Vary 会导致错误内容被缓存并发送给不匹配的客户端；但过度使用 Vary 会带来缓存碎片化：不同请求头值的微小差异（如语言标签顺序、空格）会被视为不同变体，导致大量低复用率的缓存条目，拉低命中率并增加源站负载。

Cloudflare 的精细化管控方案

Cloudflare 近期在 Cache Rules 中全量开放 Vary 支持。核心思路是：源站仍通过 Vary 头声明可能影响的请求头，而用户可在缓存规则中决定每个头的具体处理动作。提供三种动作：

  • normalize（归一化）：对已知协商头进行标准化，合并等效值，推荐作为默认。
  • passthrough（透传）：保留原始头值的精确差异（大小写、空格、顺序），仅当差异确实改变响应时使用。
  • bypass（绕过缓存）：对高基数或个性化头（如 Cookie、User-Agent）直接回源，避免无效缓存。

若源站返回 Vary: *，则始终绕过缓存，因为任意请求特征都可能影响响应。此外，规则可在回源前对配置字段归一化，再结合响应中的 Vary 决定变体键。

实际配置建议

对于多语言站点，可对 Accept-Language 使用 normalize，将 en-US,en 与 en 视为等同；对于图像格式协商，Accept 头可归一化常见类型。仅当业务必须区分细微差异时才用 passthrough。Cloudflare 数据显示，近 5 万热门站点中约 3000 个在 4 个以上字段启用 Vary，部分甚至达 47 个字段，极易造成缓存冷却，因此合理设置动作至关重要。

对读者的意义与技术解读

对于运维、SRE 与站长，该能力意味着可在不修改源站逻辑的前提下，直接通过边缘规则平衡「响应正确性」与「缓存效率」。实践中，建议先以 normalize 为默认策略，配合缓存命中率、源站请求数等监控指标逐步调优；对确实无复用价值的动态内容采用 bypass，防止碎片化挤占缓存容量。理解 Vary 的契约——源站声明「可能变」，边缘决定「如何变」——有助于构建既合规又高性能的 CDN 加速架构，尤其适用于跨境链路中需按地域或客户端协商内容的场景。