Cloudflare支持HTTP Vary头：编程缓存
My comment on We just shipped support for the ugliest part of HTTP: Vary — Hacker News. I've been wanting this from Cloudflare for years . \n The classic problem here is if yo
Full article body is primarily in Chinese for SEO depth; key points above are localized. Use the language switcher and deep links for global navigation.
Cloudflare支持HTTP Vary头：编程缓存
Cloudflare最近在Cache Rules中上线了HTTP Vary头完整支持。这项功能让开发者能精确控制缓存行为，避免API响应被错误缓存，同时保持高命中率。特别适合需要同时提供HTML和JSON响应的应用场景，比如轻量级编程工具或AI辅助开发环境中的API层级中转。
谁适用？任何使用Cloudflare做边缘缓存的编程项目都会受益，尤其是那些通过Accept头进行内容协商的场景。决策时，核心看两个点：一是是否已有多个有效响应（比如文本/html vs 应用/json），二是对缓存命中率和源站负载的权衡。之前Cloudflare对Vary头支持有限（主要图像场景），现在彻底可用，但必须在规则中明确配置，否则仍可能出现抖动。
这个特性由Cloudflare团队2026年9月推出，来自官方博客和Simon Willison的Hacker News评论区讨论。目前支持所有计划，不再受限于旧版限制。
什么是HTTP Vary头？
HTTP Vary头是标准缓存控制机制，告诉中间缓存（如Cloudflare）哪些请求头会影响源站响应。常见用于内容协商：浏览器请求Accept: text/html可能得到HTML页面，而API客户端用Accept: application/json得到结构化数据。
源站通过Vary: Accept来声明差异，缓存才知道不能简单用URL作为唯一键。之前Cloudflare对Vary的支持不完整（忽略其他头），导致缓存错用问题——例如HTML版先进入缓存，API客户端就拿到错误的响应。
如今Cloudflare在Cache Rules中提供了精细控制：normalize（规范化）、passthrough（透传）和bypass（绕过）。这解决了“正确但冷”的缓存问题，让相同逻辑的请求共享缓存条目。
为什么编程缓存需要Vary头？
编程环境下的API需求与网页不同：一个URL可能返回不同格式，用于不同客户端（如浏览器HTML vs 工具JSON）。如果忽略Vary，缓存会把先进入的内容强行服务给所有人，导致解析失败或不兼容。
Simon Willison在2026年9月23日的Hacker News评论中提到：“我多年来一直希望Cloudflare有这个支持。”他举例说明了Accept头带来的风险，并提到自己选择添加.json后缀来避免这种模式。
在GrokCode这类AI编程中转场景下，类似问题更突出：本地部署工具或模型API调用时，用户可能同时用浏览器查看示例和用API查询结构化数据。如果缓存冲突，体验直接中断。
Cloudflare Vary头支持如何配置？
开启方式很简单：在Cloudflare仪表板找到对应页面（Cache Rules > Vary设置）。以下是典型操作流程：
- 创建或编辑Cache Rule，匹配你需要Vary的URL模式。
- 在Vary配置面板中，逐个选择源站返回的头（Accept、Accept-Language等）。
- 为每个头设置动作：默认用normalize，对个人化头用bypass。
完整说明参考Cloudflare官方文档。
常见动作详解与适用场景
| 动作 | 作用描述 | 推荐场景 | 示例头 |
|---|---|---|---|
| normalize | 规范化请求头，让等价请求共享缓存 | 内容协商头（Accept等） | Accept、Accept-Language |
| passthrough | 严格透传原始值，精确匹配 | 源站明确区分的头 | X-View |
| bypass | 永远绕过缓存，防止碎片化 | 个性化或高基数头 | Cookie、User-Agent |
normalize是默认推荐起点，尤其适合Accept头：它把en-US和en-GB等价为en，让HTML和JSON请求能命中同一缓存。
实际编程缓存配置示例
假设你的站点用Vary: Accept, Accept-Language，Cache Rule设为：
- Accept：normalize
- Accept-Language：normalize
- Cookie：bypass（如果需要个性化）
请求流程：
- 第一请求（Accept: text/html）触发源站，Cloudflare记录Vary头并按规范值缓存。
- 后续相同Accept请求直接命中，避免重复源站调用。
- Vary: * 会强制bypass，适合不可预测的个性化内容。
这比之前只能用Worker或全bypass的方案更高效，减少源站压力，同时保证客户端拿到正确格式。
延伸阅读
风险与边界
过度使用Vary可能导致缓存条目爆炸，增加内存和带宽消耗。某些个人化或高基数头（如Cookie、User-Agent）建议直接bypass，避免碎片化。Vary: * 会强制绕过缓存，不适合生产环境。
本文非法律意见，仅基于公开技术文档和开发者实践总结。请以Cloudflare官方文档和当前政策为准，建议在非关键生产流量上先测试规则效果。
English summary
Cloudflare has now added full support for the HTTP Vary header in Cache Rules, released around September 22, 2026. This feature lets developers precisely control how request headers like Accept influence caching, preventing wrong responses from being served to different clients while maintaining high cache hit rates.
It is ideal for programming projects that serve multiple valid representations from one URL, such as HTML for browsers and JSON for API clients in AI coding tools or model transit layers. The issue was previously common because Cloudflare only partially supported Vary (mainly for images), leading to cache collisions.
Key actions include normalize (recommended default for negotiation headers to merge equivalent requests), passthrough (for headers with exact semantic differences), and bypass (for personalized or unpredictable ones like cookies).
In GrokCode-style scenarios involving API transit and local deployment, this avoids caching conflicts that break tool workflows. Configuration is straightforward via Cache Rules, with built-in normalization handling common cases like language preferences.
Test thoroughly in staging—while it improves efficiency, misconfiguration can still fragment cache. Official documentation provides the authoritative details.
适用于 GrokCode 倍率榜。信息仅供参考，不构成购买、投资或法律意见。