Cloudflare CDN setup: where the cache breaks and where failure spikes come from
Cache on the edge network works only as precisely as the rules are described.
If the origin serves caching headers “by default,” and the cache key takes into account service tags and request parameters, static assets bypass the cache: every image and script is pulled from the origin again each time a page is opened.
Configuring Cloudflare CDN starts not with the “enable” toggle, but with an inventory of what should be cached, by which key, and for how long.
Then the second problem appears — a low cache hit ratio with an apparently working configuration.
Too short a response TTL, a different set of parameters in links to the same file, dynamic content following the same route as static assets — and the edge honestly passes the requests further.
The origin receives them all, and the bottleneck turns out to be not its capacity but the rules at the edge.
At peak, this looks like a wave of failures. The request queue grows, the origin response exceeds the edge’s waiting limit, clients retry and add load to the already overloaded origin.
The same file is requested by dozens of connections because the cache did not manage to store it or did not consider it cacheable. Failures at peak traffic almost always follow this chain, not because of a server that suddenly “went down.”
We troubleshoot such failures at the rules level: cache key, origin response caching, cache bypass for dynamic content, route separation, request rate limiting. Below is how this is addressed and what we check before making changes in production.
What managed cache provides: response time, hit ratio, resilience
The first thing that changes after enabling the rules is the cache hit ratio. For static assets and media it reaches 85–95% and stays steady, while only requests with personal data, cart, and forms go to the origin.
Page response time is reduced several times over: the response is served by the nearest node instead of a server located in one region.
The second effect is reduced load on the origin. When the edge handles nine out of ten requests, the application server stops serving images, scripts, and fonts and spends resources on dynamic content.
On a graph this looks like a flat plateau: traffic spikes no longer hit the ceiling and do not knock the service out of operation.
Hence the third result — resilience under load. A spike from a campaign or publication is absorbed by cache nodes, not by a single server, so pages do not return errors or queue up for processing.
A whole class of overload-related failures goes away: timeouts at peak, memory shortages, cascading restarts that turn a short spike into a long outage.
We measure the effect before and after: we take metrics before enabling the rules and compare the hit ratio, response time distribution by region, and the number of requests that reached the origin.
Then the rules live together with the site — cache TTL, keys, and forced purge are configured so that an urgent publication goes live immediately rather than waiting for expiration.
CDN operating modes: caching rules, dynamic content, protection
CDN operating mode is not a checkbox in the panel but a set of rules: what is served from the edge cache, what goes to the origin server, and what does not reach it at all.
In Cloudflare, such rules are assembled from three layers — caching static assets by paths and extensions, cache bypass for authenticated and API traffic, and execution of some logic at the edge. Let us examine real options and the limitations of each.
| Option | When it fits | Limitations |
|---|---|---|
| Full static asset caching | Catalog, landing pages, media: assets change rarely | Requires cache purge on every release; without file name versioning, users get the old build |
| Targeted rules by path | Mixed site: some pages are static, some personalized | Dozens of rules conflict by priority; rules must be versioned together with the application |
| Full cache bypass for dynamic content | Account area, API, payment, forms | All traffic goes to the origin server — a spike or bot attack lands directly on it |
| Dynamic content processing at the edge | Personalization, assembling a response from parts, experiments on part of the audience | Logic is duplicated between the edge and the server, and maintenance cost grows |
A separate layer is spike protection: request rate limiting and bot checks work on the same rules, so a peak is cut off before the origin server, not after.
In practice, modes are combined: static assets live in the cache, API and account area bypass it, and some dynamic content is assembled at the edge.
Mixing them without versioning the rules is risky — a mismatch between cache and release delivers stale data directly in the interface.
Implementation procedure: from traffic inventory to handover
We break the work into stages so that every change is based on data rather than assumptions.
We start with an inventory and only then touch the settings: if caching is enabled immediately, it is easy to cache personalized responses or break authorization, and troubleshooting takes more time than the implementation itself.
-
Traffic audit. We collect statistics by path over a representative period: what serves static assets, what serves dynamic content and API, which responses are marked private.
We break it down by geography and cache hit ratio — this is the baseline against which we later compare the result.
-
Request flow diagram. We document the request path from resolution to the origin server, mark where encryption terminates, which headers reach the backend, and which cookies must remain untouched. We agree on the diagram with your team before making changes.
-
Caching rule configuration. We define policy by content type: TTL for static assets, cache bypass for authenticated requests, a cache key without sensitive parameters, and correct response headers. We move some logic to edge server functions if different delivery is needed for user groups.
-
Security. We enable bot and spike filtering, per-endpoint rate limiting, and request filtering rules. We write exceptions narrowly so that legitimate scenarios are not blocked.
-
Load testing. We run a profile close to peak: we look at hit ratio, response time, and behavior when the origin fails. We separately check invalidation correctness — how quickly a stale object is removed.
-
Configuration handover. We provide a description of rules, policies, and access roles, the cache management procedure, and the rollback order. Plus a short instruction for the on-call shift: what to monitor and what to do in case of an anomaly.
After handover, you manage the configuration yourselves — we remain available for changes and further development of the scheme.
What remains in the project: configurations, policies, procedures
The result of the work is not access to the control panel but a set of artifacts in your repository by which the infrastructure can be reproduced, verified, and handed over to another engineer.
Everything we configure is recorded as code and text: CDN configuration is stored in files, changes go through review rather than being edited by hand in the web interface.
Each item covers its own class of issues — from traffic routing to the on-call engineer's actions during an incident. Below is what exactly remains in the project after delivery.
- CDN configuration files: caching rules by content type, object TTLs, cache keys, overrides for dynamic paths, enabled compression and optimization modes.
- Request flow diagram: from the client through the edge node to the origin — with cache points, header transformations, and where edge server logic triggers.
- Access policies: allowlists of origins, geographic and request-rate restrictions, automated traffic protection rules, client verification modes.
- Origin protection settings: blocking direct requests that bypass the CDN, verifying requests from the edge, and a list of trusted addresses.
- Maintenance procedure: change publication order, intermediate environment testing requirements, planned rollback procedure, and on-call actions during degradation.
- Infrastructure documentation: purpose of each rule, relationships between settings, failure points, and owners of individual areas.
- Monitoring instructions: which metrics are collected, trigger thresholds, where alerts go, and who responds to them.
The package is self-sufficient: a new engineer on your team can replicate the edge behavior from these materials without contacting us. Describe the task — we will return with an estimate and plan, including the set of artifacts for your environment.
Case study: traffic grew, but edge failures decreased
The client came with a typical picture: marketing brought traffic, and the origin could not cope. Over the quarter, peak load tripled, the cache hit ratio stayed at 61%, and all dynamic content and part of static assets went directly to the origin.
Edge failures reached 2.7% of requests, and a noticeable share of them were for pages that had not changed in weeks.
We started with an inventory: we analyzed what was actually cached and what bypassed it because of headers, request parameters, and bypass rules.
Then we rebuilt the logic in Cloudflare: normalized cache keys, separated rules for static assets, dynamic content, and personalized responses, and moved rare requests into a separate origin queue with rate limiting.
We separately configured edge filtering so that parasitic traffic was cut off before reaching the origin.
Result in metrics
Cache hit ratio grew from 61% to 93%, edge failures dropped to 0.4% — first at the same traffic, then at doubled traffic. Edge response time decreased almost fivefold, and origin load fell by about four times: the previous hard limit was no longer a bottleneck.
We verified with load behavior: we ran peak scenarios with a warm cache and with a cold cache, observed how queues behave and what happens when one of the nodes fails.
Manageability was built in advance — rules are versioned, and reverting to the previous configuration takes minutes.
How does edge cache differ from application cache?
These are two different layers, and confusing them is expensive. Application cache lives next to the data: the application computes a heavy response once and serves it from memory or disk.
Edge cache is copies on delivery network nodes: the request ends at the nearest node and does not reach the server.
The edge layer on Cloudflare handles static assets and public responses — images, scripts, styles, catalog pages for anonymous visitors. Application cache covers what cannot be served as is: aggregates from multiple sources, personalized blocks, responses from external services.
The former saves network resources and response time, the latter saves computation and database calls.
The main difficulty is desynchronization and stale content. An editor published a change, but the node still has an old copy of the page.
Therefore cache invalidation is designed together with the publication logic: tag-based purge at the edge, key versioning in the application, and a short TTL for frequently changing pages.
Two-tier caching works when the layers do not conflict. The edge serves quickly and can refresh a copy in the background while the previous one was sent to the user, and the application does not recompute what has not changed. The rule is one: each content type has its own cache owner and one purge scenario.
We make the choice based on the share of repeat requests and change frequency: a response that is the same for everyone and rarely changes is kept closer to the user, while a session-dependent one stays inside the application. On your traffic we will show which set of rules produces the effect.
Common technical concerns before starting work
Before starting, concerns are usually not about “will caching work”: more important is how to distinguish cache behavior from an application defect, who is responsible for the rules, and what happens to traffic at the moment of switching.
How can I tell whether the problem is in the cache and not in the application?
We look at responses at the edge level: whether the request hit the cache or went to the origin, how old the object is, and which nodes served it. If the origin directly returns correct data but the edge returns stale data, the issue is in the caching rule.
If it differs in both places, we fix the application. We start with one URL and a list of exceptions, not with a full cache purge.
Will the switchover happen without downtime?
First we inventory the current rules: some duplicate each other, some conflict. We move them in groups to a test domain, verify behavior, then change the domain records and shift traffic.
Rollback — restoring the records and the previous set of rules — takes minutes and does not bring down the service.
Where is the boundary of responsibility for the rules?
We design and configure caching rules, request rate limits, bot filtering, certificates, and security headers, and maintain configuration documentation. You approve which paths are not cached: account area, checkout, and responses from services with personal data. We make further changes on request — the rules do not diverge from reality.
What about edge network security?
The edge takes on filtering malicious traffic and protection against password brute force and domain spoofing. We hide the origin address so that protection cannot be bypassed directly, and enable mandatory encryption for all visitors. Policies are assembled into a single set rather than scattered manual edits.
Let's discuss the task and come back with an estimate and plan
To make the project estimate fact-based, we need source data for the audit. Send the list of domains and subdomains being served and access to the Cloudflare panel with read-only permissions for the configuration.
This is enough to see the current traffic delivery scheme and the areas where requests bypass the cache.
Next we look at what is served from the edge and what is pulled from the server on every request. We need the current caching rules and object TTLs, the list of dynamic routes, the cache purge procedure after release, and current security policies.
- Domain, subdomains, and current DNS records — zone export or list.
- Access with minimal permissions: read settings, without changing plans or payments.
- Caching rules, object TTLs, and purge procedure after release.
- Dynamic routes that must not be cached and the conditions for bypassing them.
- Security requirements: traffic filtering, bot protection, request limits.
- Origin server diagram and certificate issuance procedure.
- Requirements for logs, metrics, and alerts.
Describe the task in your own words — we will come back with a project estimate and CDN work plan.
In it, we will divide responsibilities: what we do and hand over (caching rules, security policies, diagrams, and documentation) and what remains on your side — DNS delegation, access, and release coordination.