--- title: "用Cache Rules打开Origin Range Requests：大文件首字节与回源体积怎么验 - Angryecho" description: "目标：对已经可缓存的大文件（点播分段、安装包），用 Cloudflare Cache Rules 打开 Origin Range Requests，并用前后对比确认首字节与回源体积确实改善。依据官方博文与 Cache Rules 设置文档。" canonical_url: "https://www.angryecho.com/c/quan_zhan_kai_fa/p/P2TBBjOITGFwjpU03HUc8" meta: "og:description": "目标：对已经可缓存的大文件（点播分段、安装包），用 Cloudflare Cache Rules 打开 Origin Range Requests，并用前后对比确认首字节与回源体积确实改善。依据官方博文与 Cache Rules 设置文档。" "og:image": "https://www.angryecho.com/_og/d/c_Post%2Ctitle_~5ZCQ5qe9572R%2Cdescription_~5ZCQ5qe95LiA5LiL77yM5bCx5LiK5ZCQ5qe9572R44CC%2CpostId_P2TBBjOITGFwjpU03HUc8%2Crevision_~MjAyNi0xMS0wMlQwMjo1NTo1Ni44NjcxNzBa%2Cp_Ii9jL3F1YW5femhhbl9rYWlfZmEvcC9QMlRCQmpPSVRHRndqcFUwM0hVYzgi%2Cs_gmY0nurb768etAnx.png" "og:image:height": "630" "og:image:type": image/png "og:image:width": "1200" "og:title": "用Cache Rules打开Origin Range Requests：大文件首字节与回源体积怎么验" --- > Index of every page on this site: [llms.txt](https://www.angryecho.com/llms.txt) # **用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 排序方式 : ### **成为第一条评论！** Nobody's responded to this post yet. Add your thoughts and get the conversation going. ```json {"@context":"https://schema.org","@graph":[{"@id":"https://www.angryecho.com/c/quan_zhan_kai_fa/p/P2TBBjOITGFwjpU03HUc8#post","@type":"DiscussionForumPosting","commentCount":0,"dateModified":"2026-11-02T02:55:56.867Z","datePublished":"2026-10-24T08:20:25.981Z","description":"目标：对已经可缓存的大文件（点播分段、安装包），用 Cloudflare Cache Rules 打开 Origin Range Requests，并用前后对比确认首字节与回源体积确实改善。依据官方博文与 Cache Rules 设置文档。","headline":"用Cache Rules打开Origin Range Requests：大文件首字节与回源体积怎么验","isPartOf":"https://www.angryecho.com/c/quan_zhan_kai_fa","mainEntityOfPage":"https://www.angryecho.com/c/quan_zhan_kai_fa/p/P2TBBjOITGFwjpU03HUc8","text":"目标：对已经可缓存的大文件（点播分段、安装包），用 Cloudflare Cache Rules 打开 Origin Range Requests，并用前后对比确认首字节与回源体积确实改善。依据官方博文与 Cache Rules 设置文档。\n\n准备工作\n\n\n\n\n\n站点已接入 Cloudflare，且目标路径本身允许被缓存\n\n\n\n账号具备编辑 Cache Rules（或 Rulesets API）的权限\n\n\n\n准备一个足够大的可缓存对象 URL，以及可看源站流量/日志的方式\n\n\n\n记录开启前的基线：TTFB、CF-Cache-Status、源站回源字节\n\n操作步骤\n\n1、写一条只匹配大文件路径的 Cache Rule\n\n做什么：用主机名 + 路径前缀（例如 /media/*、/downloads/*）限定范围，动作设为缓存。\n为什么：全站开关会让排错变难；先收敛到真正吃 Range 的路径，出问题也好回滚。\n如何确认：规则列表可见匹配条件；用测试请求能看到命中该规则（规则分析或响应头侧证）。\n\n2、打开 origin_range_requests\n\n做什么：在规则参数里把 Origin Range Requests 设为 on（控制台开关，或 API 字段 origin_range_requests.mode=on）。\n为什么：这是官方提供的「按缓存对齐字节范围回源」能力，用来替代手工调分段大小。\n如何确认：保存后规则详情/导出 JSON 显示该模式为 on，规则版本更新。\n\n3、用同一 URL 做开启前后对比\n\n做什么：对同一对象发起带 Range 的请求，记录 TTFB、缓存状态，并对照源站侧流量或日志中的回源字节。\n为什么：宣传点就是减少「客户端只要几 MB、源站却被拉走一大块」；没有数字对比就不知道有没有生效。\n如何确认：开启后 TTFB 或回源体积相对基线下降，播放/下载内容完整且哈希一致。\n\n4、确认没有误伤动态与不可缓存路径\n\n做什么：对带登录态、Set-Cookie、明确 bypass 的路径再发请求。\n为什么：文档写明该功能不会把不可缓存对象变成可缓存；避免把动态接口卷进规则。\n如何确认：这些路径仍显示动态或绕过；业务登录与个性化响应正常。\n\n注意事项\n\n\n\n\n\n先在低风险路径试点，再扩到全站媒体域\n\n\n\n若源站本身不支持 Range，需要先解决源站能力，而不是只开 CDN 开关\n\n\n\n说明：于 2026-10-24 按 Cloudflare 博文与开发者文档整理。\n\n若对比后几乎无变化，先确认路径是否真的命中规则、对象是否本身可缓存，以及源站是否返回 206/Accept-Ranges。排除这三项之前，不要急着判定功能无效。\n\n来源\n\n\n\n[1] https://blog.cloudflare.com/origin-range-requests/\n[2] https://developers.cloudflare.com/cache/how-to/cache-rules/settings/\n\n#Cloudflare #CacheRules #Range #全栈 #CDN","url":"https://www.angryecho.com/c/quan_zhan_kai_fa/p/P2TBBjOITGFwjpU03HUc8","author":{"@type":"Person","name":"用户617739","url":"https://www.angryecho.com/u/JcooMFLc"},"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/DislikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":0}]}]} ``` ## Sitemap See the full [sitemap](https://www.angryecho.com/sitemap.md) for all pages.