Users can request the same CDN URL and receive different page or script versions. That does not necessarily mean an edge node is broken. Common causes include different cache keys, a partial invalidation, an upper-tier cache holding an older object, or origins that were not updated consistently.
The investigation needs to answer three questions: did the requests identify the same cache object, was that object expired or invalidated, and did every cache tier receive the same version? One curl result from one network is not enough to establish global consistency.
Identify where the difference comes from
Choose a resource with an explicit version signal, such as a content-hashed JavaScript filename, a response version header, or a temporary build identifier in a test page. Record the request time, resolved edge address, response headers, cache status, Age, ETag, and a content digest. Do not paste cookies, signed parameters, or complete private URLs into a public ticket.
Repeat the request from multiple networks and regions while keeping the method, Host, protocol, and request headers consistent. If one provider or region repeatedly receives the older object, inspect DNS steering, edge cache state, and deployment propagation. If one region changes between versions over a short period, inspect cache keys, tiered caching, and multiple origin versions.
A different cache key means a different object
A CDN may include query strings, selected cookies, request headers, Host, or path rules in its cache key. URLs that look identical to a person can map to different cache objects when query ordering, language signals, or device cookies differ.
Group the anomalous requests by:
the complete URL and query parameters;
Host, protocol, and port;
cookies or headers that enter the cache key;
case, trailing slashes, and URL encoding;
cache behavior assigned to pages, scripts, and APIs.
Do not remove login, cart, or authorization-related values from the cache key merely to improve the hit ratio. A cache key that combines private responses can expose one user's content to another user, which is a more serious failure than stale content.
Versioned assets are easier to validate than reused URLs
Static scripts and stylesheets are easier to deploy when their filenames contain a content hash or explicit version, such as app.7f3a1c.js. Publish the new HTML reference first, and retain the old object for a compatibility window so clients using older HTML do not immediately receive a 404.
If the same URL must be reused, confirm the invalidation scope, result, and completion time. A precise invalidation is usually easier to control than a site-wide purge, but it may not cover browser caches, service workers, upper-tier caches, or another hostname. Keep the object path, version identifier, invalidation request ID, and verification time in the deployment record.
Tiered caching can extend version differences
With multiple cache tiers, an edge miss may be served by an upper-tier cache. Refreshing an edge object does not necessarily update the upper tier; if the upper tier still holds the older object, several edges can refill from it.
Check the provider's definitions for upper-tier caching, request collapsing, invalidation propagation, and Age. Age describes the age of a response within one cache path; it does not prove that every edge uses the same version. Different cache-status values also do not directly tell you how many requests reached the origin.
If the CDN exposes origin response headers or request trace IDs, preserve them in controlled test requests. Origin logs should record the resource version, Host, request time, and trusted CDN trace information so a viewer request can be correlated with an origin fetch.
An inconsistent origin can look like a CDN problem
A cache object filled from different origins at different times can produce different versions for users. Check every origin behind the load balancer, object-storage replica, deployment directory, and container image.
For static assets, calculate a SHA-256 digest and compare it across origins and storage replicas. For HTML or API responses, compare a build ID or backend version marker rather than relying on visual inspection. Use read-only requests during testing; do not verify a deployment with an endpoint that has side effects.
After a deployment, verify that every origin can serve the new object before invalidating the CDN. Otherwise, the invalidation can refill different edges from different origin versions and the inconsistency will return.
A controlled verification command
The following example reads only a small public static file and saves response headers and content in a temporary directory. Replace the hostname and path, and do not use production credentials or private download URLs.
for i in 1 2 3; do curl -sS --max-time 10 \ -D "headers-$i.txt" -o "body-$i.txt" \ 'https://cdn.example.com/assets/app.7f3a1c.js' sha256sum "body-$i.txt" done
Compare the response headers and digests from different network environments. If you compare edge addresses, record DNS results but do not infer the edge identity from an IP alone; providers may use Anycast or dynamic routing.
Apply the smallest safe fix
If only an old URL is affected, move to versioned assets and retain the old files for a compatibility period. If the cache key distinguishes irrelevant values, remove only those values that have no business meaning. If it combines values that must remain isolated, restore the separation before considering any public caching.
If an upper-tier cache or invalidation delay is confirmed, make the deployment sequence explicit: all origins ready, origin versions verified, precise objects invalidated, then verified from multiple networks. Repeated site-wide purges add origin load and do not correct a bad cache key.
Change one rule or resource group at a time. Save the previous configuration and rollback procedure. Acceptance testing should cover at least two networks and two time points, while checking content, cache status, errors, and origin request volume. A deployment is consistent only when the expected version can be reproduced, not when one request happens to return it.
References
Sources reviewed November 9, 2026. The commands are controlled read-only examples and do not claim testing in the reader's production environment.
