You open the same file through CloudFront twice, expecting the second response to say X-Cache: Hit from cloudfront. It still says Miss from cloudfront. Reopening a URL does not by itself prove that both requests looked up the same valid cached object.
What do Miss and Hit tell you?
CloudFront looks for a usable object at the edge location handling the request. A Hit means a matching, valid object was there; a Miss means it was not available for that request. “Matching” matters: requests that look similar can produce different cache keys.
The diagram assumes the same edge location and cache key. Without a valid copy, CloudFront follows a miss path; with one, it can respond from the edge. The URL alone does not guarantee a hit next time.
Suppose CloudFront serves S3 object assets/guide.txt. This illustrative sequence assumes the same edge receives both requests for the same cache key:
| Request | Edge cache state | Possible X-Cache |
|---|---|---|
| First request | No valid copy for the key | Miss |
| Repeat before TTL expires | Same key has a valid copy | Hit |
| Repeat after TTL expires | Prior copy is no longer fresh | Miss is possible |
These are conditions, not measurements of a live distribution.
Why might the same URL keep missing?
Compare the host and path, then inspect the cache policy for that behavior. Depending on its configuration, query strings, headers, and cookies can contribute to the cache key. If lang is included, ?lang=ko and ?lang=en occupy different cache entries. If query strings are excluded, changing only lang cannot explain a separate miss. AWS documents how the cache key is built.
Even with the same key, a request at another edge location may encounter another cache. A short TTL, eviction, or invalidation can also remove a usable copy. Check origin Cache-Control, distribution TTL settings, and the response Age where present. CloudFront's expiration guide explains how a stale copy is checked against the origin. A Miss alone does not prove that the origin sent the full file again.
Is a browser 304 the same signal as X-Cache?
No. 304 Not Modified is an HTTP response status involved in reusing a browser-held copy. X-Cache describes CloudFront's processing of a response. A developer-tools view may show 304 alongside either a CloudFront Miss or Hit, depending on the requests and caches involved.
For a 304, inspect conditional request headers such as If-None-Match and If-Modified-Since, and response validators such as ETag and Last-Modified. Keep browser revalidation separate from CloudFront cache effectiveness.
What order helps investigate repeated misses?
- Inspect the actual network response and
X-Cache, not just a browser “memory cache” label. Confirm host, path, and request method. - Compare the cache key defined by the policy, including relevant query strings, headers, and cookies.
- Check freshness using
Cache-Control, effective TTL, andAgewhere available. - Check whether requests reached the same edge. Use distribution logs and cache policy when evidence from two networks differs.
A Hit also does not guarantee the object is the latest desired version. If freshness matters, design the update and TTL policy deliberately.
Key takeaways
Miss means no valid edge response matched that request; Hit means one did. When a repeated URL misses, separate cache key, TTL, edge location, and browser revalidation instead of assuming every second visit must be a hit.
