A high CDN cache hit ratio can coexist with rising origin bandwidth. A request-based percentage does not tell you how many bytes the cache saved, and an edge miss does not necessarily reach the origin.

Start with three measurements over the same interval: viewer requests, requests reaching the origin, and bytes sent by the origin. Break them down by hostname, path, and status code. This usually makes it easier to distinguish large downloads, dynamic traffic, cache refills, and requests bypassing the CDN.

This workflow assumes access to CDN logs, origin logs, or object-storage access records. Field definitions and available metrics depend on your provider.

High request hit ratios can hide expensive misses

Consider an illustrative interval with 100,000 requests. Of these, 99,000 hit cache and each returns just 2 KB. The remaining 1,000 miss cache and each fetches 20 MB from the origin. The request hit ratio is 99%, yet those misses account for roughly 20 GB of origin data. This simplified calculation excludes protocol overhead, compression, retries, and cache tiers.

There is also a simpler explanation: if total requests double while the hit ratio stays constant, the absolute number of misses can double too. Percentages alone hide that growth.

Check whether the dashboard reports a request hit ratio, a byte hit ratio, or a ratio calculated only over cache-eligible traffic. Some charts may exclude dynamic requests from their denominator. Likewise, viewer delivery bytes, billable traffic, and origin-fetch bytes are different quantities.

Align the measurements before changing cache rules

Choose a short interval covering the increase and compare like with like.

A server-wide network counter cannot attribute traffic to the CDN by itself. Narrow the scope with virtual-host logs, load-balancer logs, or object-storage access records. Redact credentials, signed query parameters, and user identifiers before sharing evidence, and restrict access to exported logs.

An edge MISS is not proof of an origin fetch

With multiple cache tiers, an edge miss can be served by an upper-tier cache without fetching the full object from the origin. Changing the cache hierarchy or fetch path can therefore increase origin requests without a conspicuous change in the edge hit ratio.

AWS documents CloudFront Origin Shield as an additional caching layer between existing cache layers and the origin. It can also consolidate concurrent requests for the same object to reduce requests reaching the origin. This is a product-specific capability: check the distribution configuration, region selection, and current pricing before enabling it.[1]

Review recent changes to upper-tier caching, Origin Shield, origin selection, and path-specific cache behaviors. Do not count every response marked MISS as an origin request. Cache-status headers have provider-specific meanings and may describe only part of the delivery chain. Correlate CDN origin-fetch records with origin logs wherever possible.

Find the paths responsible for the additional bytes

Compare the incident interval with a representative baseline. Group requests by path or object prefix and calculate both request count and bytes actually sent. The largest increases often fall into a few recognizable categories:

• Downloads, video, and backup files. A small request count can generate substantial traffic. Examine 200 and 206 responses alongside object sizes.

• Uncached APIs. Growth reaches the origin directly. A high hit ratio for static assets does not explain API load.

• Conditional requests. A 304 response normally has no response content, but validation still creates an origin request and processing work. Separate request growth from byte growth.

• Errors and retries. An origin attempt may be retried, and the client may send another request as well. An origin request is not necessarily a new visitor.

• Invalidations and deployments. Broad invalidations cause cache refills. Frequent updates or synchronized expiration of popular objects can also create a fetch spike.

HTTP caching rules allow caches to validate stored responses before reuse. no-cache requires successful validation before reuse; it does not simply mean that storage is forbidden. no-store constrains storage.[2] Before changing these directives, check how they interact with your CDN's cache rules. Extending TTLs across all pages can expose authenticated or private content to shared caching and is not a safe bandwidth fix.

Capture a small, controlled response sample

Use an authorized, small static test object. Replace the example hostname and path, and avoid repeatedly downloading a large file in production.

curl -sS --max-time 15 \
  -D cdn-headers.txt -o /dev/null \
  -w 'code=%{http_code} downloaded=%{size_download} time=%{time_total}\n' \
  'https://cdn.example.com/test/small-versioned-file.txt'

This example assumes a Unix-like shell with curl. Record the execution time, status, Age, Cache-Control, ETag, and any provider-specific cache status or request ID. A missing Age header does not independently prove that caching was bypassed, and an existing one does not describe the entire fetch chain. curl's size_download measures response-body bytes transferred to that client, not origin-fetch bytes.

The command uses GET. Some systems handle HEAD differently, so it is not always an equivalent cache test. Avoid adding random query parameters just to create misses: query inclusion in the cache key depends on configuration, and the test itself may generate additional origin load. A request-side Cache-Control: no-cache header is not a universal forced-bypass switch for every CDN.

Check whether traffic is bypassing the CDN

If the increase in origin requests substantially exceeds the CDN's recorded origin-fetch increase, look for other entry points: old hostnames, public bucket endpoints, unproxied DNS records, monitoring systems, crawlers, or programs connecting directly to the origin.

An origin's client-address field may already have been rewritten by a real-IP module. Preserve both the actual network peer and the visitor address resolved through trusted proxies when possible. Otherwise, one rewritten field can lead to incorrect attribution. X-Forwarded-For can be forged and is not sufficient authorization evidence on its own.

Before restricting origin access, inventory health checks, administration paths, certificate validation, and required third-party callbacks. Where supported, consider origin authentication, private connectivity, or maintained CDN egress allowlists. Test a narrow change first. Blocking production requests solely because an address looks unfamiliar is unsafe.

Apply a targeted fix and keep a rollback path

When a few large files dominate the increase, check whether they can be cached safely, whether versioned URLs remain stable, and how the provider handles Range requests. A small requested range does not guarantee an equally small origin transfer. Check the provider's cache-fill behavior and the actual origin logs.

When cache refills dominate, inspect invalidation jobs, deployment frequency, and TTL distribution. Prefer versioned assets and precise invalidations over repeatedly purging the entire site. For eligible public resources, test upper-tier caching or request consolidation if the product supports it, taking scope and cost into account.

When dynamic endpoints or retries dominate, address application load, timeout budgets, and retry policies. Writes need idempotency protection; forcing them into a shared cache is not an appropriate remedy.

Change one identifiable rule or path group at a time. Save the previous configuration, record when the change took effect, and define how to revert it. Evaluate origin request count, origin bytes, errors, and latency over a business interval comparable to the incident. For billing verification, use the provider's billing definition: response-body sizes in logs may exclude chargeable overhead or use a different scope.

The investigation should identify which requests caused the increase, whether they passed through the CDN, whether they reached the origin, and whether the fix reduced requests, bytes, or both. A higher hit ratio alone does not answer those questions.

References

Sources reviewed November 6, 2026. This article provides troubleshooting guidance and illustrative examples; it does not claim testing in the reader's production environment.

1. AWS: Use Amazon CloudFront Origin Shield

2. RFC 9111: HTTP Caching