Cloudflare has made Origin Range Requests a self-service feature on all plans. It changes how the cache handles requests for parts of large files. The company said customers no longer need to tune a range size or contact support, according to Cloudflare’s announcement of the feature. It is turned on with a Cache Rule.
Cloudflare said the rebuilt cache cut p99 time to first byte for R2, its object storage, by about half. A follow-up change cut tiered cache traffic for R2 and similar workloads by about 6%.
Why Range Requests Caused Waste
An HTTP range request asks for part of a resource instead of the whole file. A video player can request bytes around a seek position, and a download manager can resume after an interruption. If the server supports the request, it returns 206 Partial Content.

Cloudflare said its old range caching mapped each request to fixed-size ranges set per zone. Small ranges led to many small origin requests and memory pressure. Large ranges made Cloudflare download much more data than the client asked for.
The company gave one example. A request for a few megabytes in the middle of a movie could make Cloudflare pull 128 MiB from the origin and move it between data centers. Sometimes the viewer had already left. Changing the range size also invalidated cached entries, because the size was part of the cache key.
How Origin Range Requests Work
Cloudflare said its move from nginx to a Pingora-based caching server made the fix possible. Pingora already stores every cached file on disk in fixed-size chunks. The range size now matches those chunks instead of being a customer setting.
With Origin Range Requests, Cloudflare checks which bytes are already cached and serves them directly. It fetches missing bytes from the origin in chunk-aligned ranges, stores them, and returns only the bytes the client requested. A request can combine a cached prefix, an in-flight download and a newly fetched suffix.
The company said requests smaller than its chunk size can still require fetching a whole chunk. It described that extra work as bounded and predictable.
Before combining bytes, the system checks each origin response against the requested range. It also confirms the total size and entity tag stay consistent. If those checks fail, or if the response will be decompressed, Cloudflare serves the full file instead of a range.
Origin Range Requests Results On R2
R2 was the largest internal user of the old feature, with a configured range size of 64 MiB. Cloudflare said a small read crossing a range boundary could cost 128 MiB of transfer between data centers.
After the move, p99 time to first byte fell by roughly half on both cache hits and misses, the company said. A later change let one response combine bytes on disk with bytes fetched from upstream. Cloudflare said that cut tiered cache traffic for R2 and similar workloads by about 6% week over week.
What Site Operators Need To Know
Cloudflare said Origin Range Requests suit seekable video such as MP4, resumable downloads, package repositories, disk images and large AI model files. It does not make an otherwise uncacheable response cacheable. The origin must also support byte ranges for partial fetches to help.
Customers enable it with a Cache Rule that matches large-file traffic and sets Origin Range Requests to On. That works in the dashboard or through the API. Cloudflare said it intends to make this the default way certain file types are served.
Related coverage: how Vary rules affect cache efficiency, Cloudflare’s larger DNS cache and a fix to a Cloudflare Containers flaw.









