摘要： Cloudflare 在 2026 年 10 月 23 日推出 Origin Range Requests，讓所有方案的使用者透過 Cache Rules 自助啟用 range request 快取，不再需要調整 range 大小或聯絡客服。新實作把 range 對齊到快取磁碟的固定 chunk，R2 的 p99 time to first byte 約降一半，tiered cache 流量也少了約 6%。
舊設計把內部限制轉嫁給客戶
HTTP range request 是大檔案分發的基礎：影片播放器 seek 到中間只抓幾 MB，下載管理器靠它續傳，套件管理器只取 artifact 的一部分。問題在於快取這些請求的方式。
Cloudflare 舊的 range caching 類似 nginx 的 cache slicing：每個請求被映射到固定大小的 range，而 range 大小與適用的副檔名要逐 zone 設定。這個大小本身就是一個兩難——設太小，origin 請求變成一長串小請求，合併時造成記憶體壓力；設太大，Cloudflare 抓回的資料遠超過客戶端實際要求。更麻煩的是，range 大小屬於 cache key，改設定就會讓快取全部失效。
根據 Cloudflare 的說明，有些設定過大的案例，一個填不滿一張軟碟的請求，竟讓網路從 origin 抓了相當於幾片 DVD 的資料，而且在客戶端早已放棄之後還在資料中心之間搬移。
解法：range 對齊 chunk，而不是設定值
轉折來自 Cloudflare 從 nginx 遷移到 Pingora 快取伺服器。Pingora 為了支援續傳，本來就把每個快取檔案以固定大小的 chunk 存在磁碟上。既然快取已經以 chunk 思考，range 大小乾脆直接等於 chunk，不再需要設定。
收到 range request 時，edge 會檢查哪些位元組已有快取、直接回應；缺少的部分則以對齊 chunk 邊界的 range 向 origin 抓取，存回同一套 chunk 結構，下游只收到客戶端要的位元組。小於 chunk 的請求仍可能多抓整個 chunk，但浪費是有界的、可預測的，不再取決於某個客戶選的設定值。
實作上這不是單純的快取查詢，而是一個協調器：一個請求可能同時用到快取的前綴、還在下載中的資料、以及新抓的尾段。如果另一個請求的位元組已被現行下載涵蓋，它可以直接附掛上去，熱門大檔案的突發流量因此共享同一份 origin 工作。正確性方面，協調器會驗證各段屬於同一個 representation、檔案總大小穩定、ETag 一致，不安全組合時改回完整的 200 回應，符合標準 HTTP 行為。
實際成效與適用場景
R2 是舊功能最大的內部使用者，設定的 range 大小是 64 MiB——跨到邊界的小讀取可能付出 128 MiB 的資料中心間傳輸。遷移到新實作後，Cloudflare 公布的數據是：R2 各儲存區域的 p99 TTFB 在命中與未命中都約降一半；協調器學會把磁碟上的位元組與上游新抓的位元組合進同一個回應之後，R2 與類似工作負載的 tiered cache 流量週減約 6%，換算是每天在資料中心之間少搬幾個 PB。
想試用的話，開關相當單純：在 dashboard 的 Caching > Cache Rules 建一條符合大檔案流量的規則，把 Origin Range Requests 設為 On，或用 API 傳 origin_range_requests: { "mode": "on" }。官方列出的適用對象包括可 seek 的 MP4、可續傳的大檔下載、軟體發布與套件庫、磁碟映像等數 GB 物件，以及會抓取模型檔案特定區域的 AI 訓練與推論工作負載。Cloudflare 也計畫讓這成為某些檔案類型的預設服務方式。
兩個前提要記住：這不會改變快取資格，本來不可快取的回應不會因此變得可快取；origin 也必須支援 byte range，部分抓取才有意義。如果你在排查大檔案服務的行為，可以搭配我們之前介紹過的 Cloudflare Traces，把請求在網路上的完整路徑一次看清楚。
參考來源
在 X 上查看原貼文