How to Optimize High-Defense CDN Cache Strategy to Reduce Origin Server Pressure: A 5-Step Configuration

First, do step one: remove random query strings from the cache key so that the same resource maps to only one cached object. Optimizing high-defense CDN cache strategy to reduce origin server pressure involves five steps: cache key normalization → enable request collapsing → layered origin fetch → path-based partitioning → origin fetch whitelist. Each step below has actionable actions and verification metrics.

First, do the math: every 10 percentage points difference in cache hit ratio, how much more concurrency does the origin have to handle?

Assume your site's total request volume is 100,000 QPS. At a 90% cache hit ratio, origin fetch QPS is 10,000; at 80%, origin fetch QPS becomes 20,000—the origin's concurrent load doubles directly. This conversion relationship (origin fetch concurrency = total requests × miss ratio) is the starting point of the entire optimization strategy. The significance of cache hits isn't just saving bandwidth; it's keeping concurrency pressure at the edge. (Illustrative example, not measured data)

Why is the origin still overwhelmed even with CDN? Three sources of miss requests

The origin is still overwhelmed, usually through three paths:

1. Origin real IP leakage: Attackers scan the entire internet and bypass CDN to directly connect to the origin. This is the most common vulnerability in CDN security systems (AWS DDoS Resiliency Best Practices whitepaper, updated October 2025).
2. Cache penetration: Attackers craft massive requests with random parameters or malformed paths, each missing the cache and all going back to origin.
3. Missing rules: Static and dynamic paths are not properly distinguished, causing all requests to go back to origin.

For the first type, it's recommended to first refer to how to prevent origin real IP exposure to complete origin IP whitelisting. This is the prerequisite for all cache optimization.

Step 1: Cache Key Normalization – Stop Random Query Strings from Creating Independent Cache Objects

By default, CDN uses the full URL (including query string) as the cache key, causing each request with a different parameter to generate an independent cache object, diluting the hit ratio to near zero.

Action: In the CDN console's cache key settings, whitelist only the parameters genuinely needed by the business (e.g., pagination, language, version), and ignore marketing and tracking parameters; also normalize case and trailing slashes.

To prevent cache penetration from requests with random parameters, this step is the main solution.

Step 2: Enable Request Collapsing – Converge Concurrent Origin Fetches for the Same Resource into One

Request Collapsing mechanism: When multiple concurrent requests on the same edge node miss the same cache key simultaneously, these requests queue at that node, waiting for the first origin fetch result to return and share it, rather than each penetrating back to origin.

Action: Enable request collapsing in CDN configuration, set a reasonable origin fetch timeout, and enable stale-while-revalidate strategies (return stale content first, then update asynchronously in the background).

AWS, in the CloudFront chapter of "Best Practices for DDoS Resiliency," states that request collapsing combined with layered caching and a strict origin whitelist can effectively prevent CC attack penetration and reduce origin concurrent load.

Step 3: Layered Origin Fetch (Origin Shield) – Reduce the Amplification Effect of Multiple Nodes Fetching Individually

Without layering, N edge nodes each fetch the same resource once, and the origin sees N times the requests. After enabling layered origin fetch, all edge nodes first fetch to an intermediate layer, which consolidates before fetching to the origin.

Action: Choose a node close to the origin data center and aligned with the origin fetch route direction as the Origin Shield layer.

It has a cumulative effect with request collapsing: request collapsing merges concurrent requests at the same time, while Origin Shield reduces duplicate origin fetches across nodes.

Step 4: Path-Based Partitioning for Static, Semi-Static, and Pure Dynamic Paths – What to Use for Dynamic APIs Instead of Cache

Different paths should have separate cache policies:

Can dynamic APIs use CDN cache? What can be cached are read APIs that tolerate second-level staleness, such as configuration fetching; write APIs and personalized responses must never be cached.

Step 5: Fallback for Miss Requests – Origin Fetch Rate Limiting and Origin Whitelist Restriction

Cache strategies only reduce the miss volume, not eliminate it, so you must set an origin fetch concurrency/QPS limit on the origin and only allow CDN origin fetch CIDR ranges in the origin's security group, closing off public direct access. For rate limiting thresholds and connection controls on the origin side, refer to Nginx anti-CC rate limiting best practices.

At this point, the five actions for optimizing high-defense CDN cache strategy to reduce origin pressure are complete—cache reduces miss volume, and the whitelist blocks bypass paths. This restriction, combined with seamless high-defense CDN configuration process, truly blocks direct origin access. A strict origin whitelist is a necessary condition for forming a complete protection loop.

How to verify after configuration: hit ratio, origin fetch QPS, origin fetch bandwidth

To see if the optimization works, look at three metrics:

Use constructed requests with random parameters for penetration testing to confirm cache key normalization is effective. Look at trends and relative changes, not absolute values.

What cache strategies can't solve: sophisticated bots and second-level attack windows

Radware's 2026 Global Threat Report shows network-layer DDoS attacks grew 168.2% year-over-year, with most web DDoS attacks ending within 5 minutes, some even under 60 seconds; malicious bot traffic grew 91.8% year-over-year. This means cache and origin fetch rules must be pre-configured before attacks occur; manual adjustments won't keep up with attack rhythm.

Sophisticated bots and low-frequency distributed requests attack dynamic interfaces, requiring WAF and behavior identification to complement; cache optimization cannot replace traffic scrubbing.

How RockCloud fits in edge caching and origin fetch consolidation

Once you understand cache keys, request collapsing, layered origin fetch, and origin whitelist, RockCloud High-Defense CDN can be positioned on the chain like this: edge caching and Anycast proximity absorption handle the "keep concurrency at the edge" part; origin protection and origin whitelist handle the "block direct origin access" part; intelligent WAF and Anycast global network handle the "dynamic interfaces and second-level attack windows that cache can't manage" part.

It works in a layered collaboration with your own cache rule design, not replacing your strategy.

FAQ

What to do if the origin is still overwhelmed even with CDN?

Follow the troubleshooting sequence for optimizing high-defense CDN cache strategy to reduce origin pressure: first check if the origin IP is leaked, then check the cache hit ratio. If the hit ratio is low, prioritize cache key normalization and request collapsing; if the hit ratio is normal but origin fetch QPS is still high, check for direct connections bypassing CDN and tighten the origin whitelist.

Why is the CDN cache hit ratio low?

Common causes include cache key not being normalized (causing penetration from random parameters), cache rules not distinguishing paths (dynamic content forcibly cached but actually unusable), and TTL set too short leading to frequent origin fetches. Optimize according to steps 1 and 4 of this article.

How to prevent cache penetration from requests with random parameters?

Enable cache key normalization, whitelist only necessary parameters (such as page number, version), and ignore marketing tracking parameters. Also, enable request collapsing so concurrent misses combine into one origin fetch.

How to configure request collapsing?

Enable Request Collapsing in the CDN console, and enable layered origin fetch (Origin Shield). The former merges concurrent origin fetches at the same time, and the latter merges duplicate origin fetches across nodes; combining both yields the best effect.

How to reduce high CDN origin fetch bandwidth?

First, increase the cache hit ratio (focus on optimizing cache keys and TTL), then enable layered origin fetch (Origin Shield) and request collapsing to reduce duplicate origin fetches. Also, confirm the origin only accepts CDN origin fetches to avoid bandwidth consumption from direct connections.

How long should the cache TTL be?

Static resources can be set to 1 year with versioning; semi-static content is recommended around 60 seconds with background refresh; dynamic content should not be cached. Too long a TTL causes stale content, and too short increases origin fetch pressure.

It's recommended you first do a baseline test using the three metrics (hit ratio, origin fetch QPS, origin fetch bandwidth) from the "How to verify after configuration" section, and construct a request with random parameters to check if cache penetration exists; if you confirm that origin fetch concurrency can't be converged or the origin entry isn't yet restricted, contact RockCloud technical support to review cache rules and origin whitelist together.