Cloudflare 上线 Origin Range Requests：用固定缓存分块替代按 zone 调参

• 核心更新：Cloudflare 将 Origin Range Requests 作为自助功能开放给所有套餐，通过 Cache Rule 开启；用户不再需要设置 range size 或联系支持。该功能改变 CDN 满足 HTTP Range 请求的方式，客户端请求本身不被修改。
• 机制变化：旧实现把客户端请求映射到按 zone 配置的固定 range，range 大小参与缓存键，调整会失效缓存；新实现复用 Pingora 按固定大小分块存储缓存文件的做法，缺失字节按缓存分块边界回源，只向客户端返回请求的字节范围。响应可组合已缓存前缀、正在下载的数据与新抓取后缀；同一对象的在途下载可被其他请求附着，共享回源工作。
• 生产数据：Cloudflare 将旧 range 缓存用户迁到新实现，优先处理高并发大文件负载。R2 原配置 range size 为 64 MiB，小范围读取跨边界可能造成 128 MiB 跨数据中心传输；迁移后 R2 各存储区域 p99 首字节在缓存命中与未命中时均约减半。协调器把磁盘已有字节与上游抓取字节合并进同一响应后，R2 及类似工作负载的 tiered cache 流量周环比下降约 6%，官方口径为每天少移动数 PB 数据。
• 正确性边界：组合范围响应只允许来自同一表示；协调器校验每个源站响应匹配请求范围、总资产大小稳定、ETag 在各子请求间一致。If-Range 不匹配时返回完整表示；对即将解压的表示不组合范围。可满足范围返回 206 与准确 Content-Range，不可满足返回 416，无法安全范围化的响应返回完整表示。小于分块大小的请求仍可能触发整个分块回源，官方称这部分额外工作有界且可预测。
• 行业意义：对象存储、软件分发、视频拖拽，以及 AI 训练与推理中传输大模型文件或读取模型工件局部区域，都会产生大量 Range 请求。把 range 大小从客户配置项改为缓存内部分块，并把缓存、在途与回源数据拼接放在同一次请求内，减少了跨层重复传输；对自建 CDN 或对象存储的团队，这提供了一个以固定分块为缓存单位、避免按文件类型反复调参的实现取舍。

🔗 Cloudflare 官方博客