用Cache Rules打开Origin Range Requests：大文件首字节与回源体积怎么验

目标：对已经可缓存的大文件（点播分段、安装包），用 Cloudflare Cache Rules 打开 Origin Range Requests，并用前后对比确认首字节与回源体积确实改善。依据官方博文与 Cache Rules 设置文档。

准备工作

• 站点已接入 Cloudflare，且目标路径本身允许被缓存

• 账号具备编辑 Cache Rules（或 Rulesets API）的权限

• 准备一个足够大的可缓存对象 URL，以及可看源站流量/日志的方式

• 记录开启前的基线：TTFB、CF-Cache-Status、源站回源字节

操作步骤

1、写一条只匹配大文件路径的 Cache Rule

做什么：用主机名 + 路径前缀（例如 /media/*、/downloads/*）限定范围，动作设为缓存。
为什么：全站开关会让排错变难；先收敛到真正吃 Range 的路径，出问题也好回滚。
如何确认：规则列表可见匹配条件；用测试请求能看到命中该规则（规则分析或响应头侧证）。

2、打开 origin_range_requests

做什么：在规则参数里把 Origin Range Requests 设为 on（控制台开关，或 API 字段 origin_range_requests.mode=on）。
为什么：这是官方提供的「按缓存对齐字节范围回源」能力，用来替代手工调分段大小。
如何确认：保存后规则详情/导出 JSON 显示该模式为 on，规则版本更新。

3、用同一 URL 做开启前后对比

做什么：对同一对象发起带 Range 的请求，记录 TTFB、缓存状态，并对照源站侧流量或日志中的回源字节。
为什么：宣传点就是减少「客户端只要几 MB、源站却被拉走一大块」；没有数字对比就不知道有没有生效。
如何确认：开启后 TTFB 或回源体积相对基线下降，播放/下载内容完整且哈希一致。

4、确认没有误伤动态与不可缓存路径

做什么：对带登录态、Set-Cookie、明确 bypass 的路径再发请求。
为什么：文档写明该功能不会把不可缓存对象变成可缓存；避免把动态接口卷进规则。
如何确认：这些路径仍显示动态或绕过；业务登录与个性化响应正常。

注意事项

• 先在低风险路径试点，再扩到全站媒体域

• 若源站本身不支持 Range，需要先解决源站能力，而不是只开 CDN 开关

说明：于 2026-10-24 按 Cloudflare 博文与开发者文档整理。

若对比后几乎无变化，先确认路径是否真的命中规则、对象是否本身可缓存，以及源站是否返回 206/Accept-Ranges。排除这三项之前，不要急着判定功能无效。

来源

[1] https://blog.cloudflare.com/origin-range-requests/ [2] https://developers.cloudflare.com/cache/how-to/cache-rules/settings/

#Cloudflare #CacheRules #Range #全栈 #CDN