Cache status BYPASS now returned for uncacheable responses
Cloudflare now consistently returns a BYPASS cache status for all uncacheable responses instead of the previous mix of BYPASS and MISS. This makes analytics clearer by reducing MISS rates, increasing BYPASS rates, and improving cache hit ratio calculations to reflect only truly cacheable traffic.
Cloudflare now returns a BYPASS cache status whenever a response is not cacheable, instead of the previous mix of BYPASS and MISS that depended on why Cloudflare chose not to cache the response.
There are multiple reasons Cloudflare may refuse to cache a response — for example, the response exceeds the maximum cacheable file size for your plan, the origin sends Cache-Control: no-cache, private, or max-age=0, the response includes a Set-Cookie header, or the request includes an Authorization header.
Previously, only some of these conditions returned BYPASS. Others — such as responses exceeding the maximum cacheable file size — returned MISS on every request, regardless of whether Origin Cache Control was on or off. Because the response could never be cached, every subsequent request also returned MISS, which looked indistinguishable from a broken cache and made it hard to tell whether Cloudflare was trying and failing to cache the asset or had deliberately chosen not to cache it.
BYPASS now consistently signals that Cloudflare refused to cache the response, regardless of the reason. MISS is reserved for cacheable responses that simply were not in the local cache at request time.
What to expect in your analytics
After this change rolls out, you should see:
- MISS rate decreases: Uncacheable responses no longer count as cache misses.
- BYPASS rate increases: These same responses are now reported as bypasses.
- Cache hit ratio increases: Hit ratio calculations no longer include uncacheable traffic that could never have been cached, giving you a more accurate view of cache effectiveness.
Your total request volume and origin traffic are unchanged — only the cache status label is different.
Browser cache TTL behavior is preserved
The cache status label is the only thing changing — browser cache TTL handling for any given response is identical to what it was before:
- Responses that historically returned
MISSbecause Cloudflare refused to cache them (for example, responses over the maximum cacheable file size) now returnBYPASS, but continue to have browser cache TTL applied — exactly as they did when they were labeledMISS. - Responses that historically returned
BYPASSand skipped browser cache TTL continue to skip browser cache TTL.
In both cases, the decision to apply browser cache TTL depends on the underlying reason Cloudflare did not cache the response, not on the new BYPASS label.
Source: original entry ↗
More from Cloudflare
Follow Cloudflare to get its new changes in your feed and email digest.
Cloudflare One Client for macOS 2026.8.2100.0
GA release for macOS Cloudflare One Client with improved split tunnel handling that no longer briefly blocks traffic during reconnects, support for non-RFC 1918 local IPv4 networks, faster connects with lower memory use, and numerous reliability fixes across DNS, reauthentication, and client stability.
Cloudflare One Client for Windows 2026.8.2100.0
This GA release improves split tunnel reliability, adds support for non-RFC 1918 local networks, optimizes connection performance with faster reconnections and lower memory usage, and includes numerous bug fixes for DNS, registration, and network handling. The client now features a service recovery mechanism that automatically restarts on system unlock and better handles large hosts files without blocking traffic.
Cloudflare One Client for Linux 2026.8.2100.0
New GA release for Linux with improved split tunnel handling that no longer briefly blocks traffic during reconnects, support for non-RFC 1918 local IPv4 networks, faster tunnel reconnections, and lower memory usage. Includes numerous stability and reliability fixes for DNS, reconnection behavior, and crash issues.