Security & Threat Intelligence · 25.07.2026, 15:30 UTC
Introducing Cache Response Rules
| Schweregrad | info |
|---|---|
| Kategorie | Security & Threat Intelligence |
| Quelle | Cloudflare Blog ↗ |
| Veröffentlicht | 25.07.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
Today we’re excited to announce Cache Response Rules. These are a new rule type that runs after an origin server replies but before Cloudflare caches the content. If you've ever been irked watching something that should easily sail out of cache get dragged back to the origin by a stray Set-Cookie or wrong Cache-Control, headers that are sometimes hard or impossible to strip or change on the origin itself, then Cache Response Rules is that fix, applied at exactly the right moment. When and how caching decisions are madeA CDN cache and an origin server work as a pair. Their goal is to answer from the cache whenever possible and only go back to the origin when the edge can’t respond. Every point of cache hit ratio comes from getting that division of labor right. Check the cache when we shouldn't, and we waste a lookup that was always going to miss. Check it too rarely, the origin serves traffic the edge should have absorbed and the performance win evaporates.Importantly, the origin guides the cache. When it returns a cacheable asset, its response headers tell Cloudflare how long it’s OK to serve it, when and how to revalidate, and even whether to cache it at all. The cache is only ever as efficient as the origin allows. If the origin gets it wrong, cache becomes decoration while the origin infrastructure costs skyrocket.Most cache eligibility problems are not decided at request time. They manifest after the origin replies.A visitor asks for /static/app.js. Cloudflare checks cache, it misses, and forwards the request to the origin. The origin returns the file. Somewhere in …