Cloudflare 於二〇二六年十月二十三日在官方部落格公布 Origin Range Requests 全面自助上線：大檔位元組範圍快取不必再調固定切片大小，可經 Cache Rules 開啟；內部先用於 R2 後，p99 首字節延遲約減半，分層快取流量亦約減百分之六。來源真實性已驗證。

Cloudflare／官方：推出 Origin Range Requests——大檔位元組範圍快取免調參；R2 首字節延遲 p99 約減半

Cloudflare 於 2026 年 10 月 23 日在官方 Blog 發布《Origin Range Requests: Serving large files without range-request tuning》，說明其邊緣快取如何處理 HTTP Range（位元組範圍）請求的架構重建，並把新實作以「Origin Range Requests」名義開放予所有方案自助啟用。本文核對自該官方頁面（作者 Matthew Gumport），來源真實性已驗證；下文重寫技術重點與對香港／亞洲企業的意涵，不轉載全文。

一、核心事件：大檔範圍請求的快取「免調參」

影片拖曳進度條、下載續傳、套件管理員只取一段產物、AI 訓練／推理只讀模型檔的某區段——這些場景都依賴客戶端送出帶 Range 標頭的 GET，伺服器回 206 Partial Content 與 Content-Range。Cloudflare 強調：客戶端的 Range 請求本身不會被改寫；改變的是邊緣如何滿足該請求。

舊式範圍快取以區域靜態設定、固定「range size」把客戶請求對應到檔案切片。切片太小會引發大量碎裂源站請求與記憶體聚合壓力；太大則一次拖回遠多於客戶所需的位元組，並在源站、分層快取與資料中心之間放大浪費。官方舉例：舊實作下，播放器只想讀幾 MB，邊緣卻可能從源站拉取 128 MiB 並在資料中心之間搬運，觀眾甚至已離開。R2 作為最大內部用戶時，設定的 range size 為 64 MiB，一次跨邊界的小讀取就可能造成 128 MiB 的跨 DC 傳輸。

新功能 Origin Range Requests 改為自助：經 Cache Rules（控制台 Caching → Cache Rules，或 API origin_range_requests: { "mode": "on" }）指定流量即可，無需再調 range size、亦不必聯絡支援。官方並表示有意讓特定檔案類型日後以類似方式作為網路預設行為，仍可由 Cache Rules 調整。該功能不改變一般快取資格：開啟並不會把原本不可快取的回應變成可快取。

技術細節

• 邊緣改以 Pingora 快取伺服器既有的固定大小磁碟 chunk 對齊源站範圍擷取，客戶端仍只收到其請求的位元組。
• 協調器可把「已在磁碟的前綴」「進行中的下載」「新從源站取得的後綴」組合成單一正確回應；熱門大檔突發時，第二個請求可掛接既有下載而非再開一條源站連線。
• 組裝前會驗證表示式一致性（範圍匹配、總長穩定、ETag 一致等）；無法安全組範圍時改回完整表示式。可滿足範圍回 206，不可滿足回 416。

二、技術原理深度解析

核心洞察是：既然 Pingora 為了續傳已把快取檔以固定 chunk 落盤，「range size」就不必再是客戶要懂的旋鈕——對齊 chunk 邊界即可。對小於 chunk 的請求，仍可能拉取整個對齊 chunk（額外工作有界、可預期），但不再由客戶自選、可達數十 KB 至數十 GB 的舊參數造成不可預測的源站與跨 DC 負載。

舊 nginx 快取路徑還有另一痛點：範圍快取難以與 concurrent streaming（寫入尚未完成時允許多客戶讀取）並用；兩者同時開啟會截斷回應，導致每個 range 必須整段下載完才能讀、熱門檔每個 range 各打一次源站。遷移至 Pingora 後的協調模型，讓「部分命中快取＋部分源站＋共享進行中下載」成為常態路徑。

對 R2 與類似工作負載，官方公布遷移後觀察：各 R2 儲存區域在快取命中與未命中兩種情況下，p99 首字節延遲（time to first byte）均約減半；後續改進讓協調器可在單一回應中合併「已在磁碟」與「剛從上游取得」的位元組後，R2 及類似工作負載的分層快取流量週比約下降 6%，相當於每日少搬運 PB 級資料。

四、日常應用場景

1. 開發者與技術團隊

軟體發行、容器／套件倉庫、磁碟映像與大型 archive，以及需傳輸大模型檔或只取模型某區段的 AI 訓練／推理管線，皆屬官方點名場景。團隊可用 Cache Rules 精準匹配「大檔路徑」開啟 Origin Range Requests，並以 API 納入基礎設施即程式碼，無需再為每個 zone 猜一個 range size。

2. 企業與隱私敏感行業

影音點播、企業檔案分發、內部套件鏡像若已把源站放在物件儲存或自建源，減少「小 Range 觸發巨大源站拉取」可降低頻寬帳單與源站壓力。功能本身處理的是快取協調，不取代零信任存取、WAF 或私有模型託管；敏感內容仍應搭配適當快取鍵、驗證與傳輸加密策略。

3. 一般用戶

終端使用者感受多半是：影片拖曳更不易「卡在邊緣傻等大切片」、下載續傳與大檔預覽更順。這些改善來自基礎設施，使用者無需改設定。

4. 香港與亞洲市場視角

香港企業常見混合架構：源站在 AWS／GCP／自建機房，邊緣用 CDN 服務亞太觀眾與員工。大檔與 AI 產物跨區傳輸成本高，減少無效跨 DC／跨層快取搬運直接影響延遲與支出。若同時在推進雲端遷移、高可用與邊緣防護，可一併檢視 Cache Rules 與源站範圍行為。

五、專業評價與潛在考量

優勢

• 把過去「專家級、易踩雷」的 range size 從產品表面拿掉，改為與內部 chunk 模型對齊，降低誤設定風險。
• 以 R2 生產數據支撐（p99 TTFB 約減半、分層快取流量約 -6%），說服力高於純行銷敘事。
• 全方案自助＋Cache Rules／API，符合基礎設施自動化習慣。

需要留意的地方

• 小於 chunk 的請求仍可能拉取整個對齊 chunk；非對齊範圍的額外工作由邊緣承擔，效益視檔案大小與存取模式而定。
• 開啟功能不會改變物件是否可被快取；源站快取標頭與規則仍是前提。
• 官方提到未來可能讓特定檔案類型預設走此路徑——營運團隊應關注預設行為變更與既有規則衝突。
• 本文數字均來自 Cloudflare 自述之內部觀察，不同客戶流量結構結果會有差異。

結語

Origin Range Requests 把「大檔 Range 快取」從難調的靜態切片，推進到以 Pingora chunk 為單元、可協調命中／進行中／源站的自助能力，並先在 R2 上交出可驗證的延遲與跨層流量改善。對正在亞洲部署影音、軟體分發或 AI 產物管線的團隊，這是值得在 Cache Rules 裡對大檔路徑做一次對齊檢查的更新。

若企業同時需要雲端遷移、高可用架構與網絡安全設計，可參考 YSK Limited 的香港雲端遷移與網絡安全（公開目標 99.99% uptime；外判方案另含美國獨立 IP VPS 預裝 YSK Server）。

參考來源

1. Cloudflare Blog（主來源）：https://blog.cloudflare.com/origin-range-requests/ （2026-10-23，Matthew Gumport）
2. 發現來源：Cloudflare 官方 RSS（rss-news-sources.json / official）
3. YSK 服務對照：https://ysk.hk/services/cloud-security ；事實核對 https://ysk.hk/llms.txt