一句话结论
Cloudflare 官方上线对 HTTP Vary 响应头的完整支持，消除因缓存忽视内容协商导致不同用户获取错误格式响应的问题。
关键要点
- 该功能于 2026 年 9 月 23 日正式上线并生效。
- 支持前仅限于图像资源，现扩展至所有资产类型以匹配标准 HTTP 缓存协议。
- 彻底解决 Accept 头差异引发的缓存数据交叉污染。
- 提供按 User-Agent 和 Accept 协商返回异构内容时的准确缓存匹配机制。
背景与事实
Simon Willison 于 2026 年 9 月 23 日发布技术通告，宣布 Cloudflare 已正式推出针对 HTTP 协议中 Vary 响应头的完整缓存支持能力。这是开发者社区向 Cloudflare 提出多年需求后落地的重要基础架构升级。长期以来，在处理依赖客户端请求头进行内容协商的 Web 应用时，HTTP Vary 头是控制缓存边界的核心机制。例如，当同一个 URL 针对发送 Accept: text/html 请求头的用户代理返回 HTML 格式内容，而针对不发送该请求头的用户代理返回 JSON 格式内容时，服务端必须在响应头中声明 Vary: Accept，明确告知缓存系统该响应内容的变更取决于 Accept 头的取值。
此次功能上线的触发机制与 Cloudflare 底层缓存策略的重构直接相关。新机制将 Vary 头中声明的所有请求头变量纳入缓存键计算，确保不同协商条件的请求生成物理隔离的缓存条目。该调整直接覆盖此前存在数据污染风险的静态资产分发、API 网关前置缓存以及多端适配架构。值得注意的是，尽管该底层能力已具备通用生产可用性，部分开发者（包括通告作者本人）并未计划将基于 Vary 头的内容协商作为自身应用架构的标准实现模式。在工程实践中，更倾向通过 URL 路径后缀（如追加 .json 后缀）或独立的 API 端点来实现确定性内容分发，从而从根本上解耦 URL 唯一性原则与响应格式变化，降低对复杂缓存变量机制的依赖。
影响分析
对于中文开发者与从业者，此判断分析表明该更新直接简化了混合端应用的部署拓扑。对于需要同时维护 Web 端与移动端数据接口的工程团队，此功能降低了架构复杂度和线上事故率。此前开发者被迫在边缘侧使用复杂的 URL 重写规则、Nginx 反向代理脚本或自研网关中间件来模拟隔离缓存空间，以弥补 Vary 机制的缺失。这种绕行方案导致请求链路被不必要拉长，增加了首字节延迟与系统维护成本。当前更新意味着，团队可以放弃边缘侧的防御性编程策略，直接利用 HTTP 标准协议的原生能力完成多格式分发。开发者可以将原本用于解析和匹配 Accept 请求头的中间件逻辑安全地下沉至应用服务器内部，让 CDN 边缘节点承担纯粹的数据分发职责，从而将基础设施成本转化为更灵活的协议适配能力。同时，由于缓存策略与标准协议对齐，团队在评估缓存命中率与故障排查时，不再需要将非标准的边缘行为纳入故障树分析，显著降低了分布式系统的排障难度。
适用边界
此结论不适用于尚未升级至最新缓存策略配置的旧版边缘集群，或网络请求在传输过程中被多级反向代理篡改导致 Vary 声明丢失的场景。同时，针对静态资源（如 CSS 或 JS）基于 User-Agent 进行差异化构建与分发的场景不受此结论优化，因为该类场景通常直接依赖资源文件内容的独立版本化而非响应头协商。
孤本观察
该更新本质上宣告了 HTTP 规范在边缘计算层面长期存在的合规性缺口被正式填补，判断这一底层能力的完善将显著减少因协议理解偏差导致的线上缓存事故。基于本文事实可以明确，该功能在协议层面消除了对 Vary 头支持的分类型歧视，将边缘缓存的决策标准统一至完整的 HTTP 缓存模型之下。
常见问题
Cloudflare 的 Vary 响应头完整缓存支持功能何时正式上线？
该功能于 2026 年 9 月 23 日正式上线并生效。
此次更新中，Vary 头支持的资产类型有哪些变化？
支持范围从此前仅限图像资源扩展至所有资产类型，以匹配标准 HTTP 缓存协议。
新机制如何确保不同协商条件的请求缓存隔离？
新机制将 Vary 头中声明的所有请求头变量纳入缓存键计算，确保不同协商条件的请求生成物理隔离的缓存条目。
哪些场景不适用此 Vary 头缓存优化？
不适用于旧版边缘集群、传输中被篡改导致 Vary 声明丢失的场景，以及基于 User-Agent 对静态资源进行差异化构建分发的场景。
该功能解决了哪类缓存数据污染问题？
彻底解决了由 Accept 请求头差异引发的缓存数据交叉污染问题，即不同格式响应（如 HTML 与 JSON）被错误共享缓存条目的情况。