How to check if a minimal page uses a CDN

A page containing only a “Click here to proceed” link can still sit behind a content delivery network. CDNs distribute copies of files across edge servers, terminate secure connections and often relay requests to an origin server. The sparse page therefore reveals almost nothing about the invisible layer delivering it.

A useful check combines DNS records, HTTP response headers, browser network information and response times. Australian comparisons are especially helpful: a visit over an NBN connection in Sydney or Melbourne may behave differently from a 4G or 5G hotspot in Perth, Brisbane or Adelaide.

The goal is evidence of network delivery, not a guess based on speed or a provider logo. Delivery infrastructure says nothing about who controls the destination, whether its promises are accurate or whether an Australian business behind it meets its legal obligations.

Separate the page from the delivery layer

Start by distinguishing three things: the HTML document, the link’s destination and the infrastructure serving either one. A static placeholder may be hosted on a CDN, while a redirect service may only accelerate the first page. In other cases, an ordinary origin server sends both the placeholder and the final destination.

Check whether the link uses a redirect or loads another page in place. In the browser, hover over it to read the target URL, then open the Network panel and select the request. A 301, 302, 307 or 308 response identifies a server redirect; client-side JavaScript can produce a similar journey without those status codes.

A third-party script, font or image service does not prove the whole page uses a CDN. It can improve delivery while the HTML remains on a single origin. Conversely, a CDN can proxy the document without caching it, so “uses a CDN” and “serves a cached copy” are related but different findings.

Read DNS for provider clues

Run a DNS lookup for the page’s domain, starting with dig +short CNAME example.com. Also check dig +short A example.com and dig +short AAAA example.com. A CNAME ending in a hostname associated with a CDN or hosting platform can be a strong clue, particularly when the resulting addresses belong to a known edge network.

CNAME flattening can replace an alias with an address, so the absence of a CNAME is not decisive. Many CDN addresses use Anycast: one announced IP reaches different edge servers depending on the visitor’s network and location. A shared hosting address can also sit on a platform that offers CDN options, so an IP lookup alone remains incomplete.

Compare the answers with the domain’s broader DNS configuration using dig +short NS example.com. The nameservers, canonical hostname and address pattern help separate hosting from delivery. A parked domain may use a redirect service, and registration under .com.au or .au says nothing by itself about where the page is cached or whether a CDN is present.

Inspect HTTP response headers

Fetch the headers without following redirects using curl -sS -o /dev/null -D - "https://example.com/". Look for server, via, age, cache-control, x-cache, x-served-by, cf-ray, cf-cache-status, fastly, x-amz-cf-id and x-akamai-transformed. Well-known CDNs add identifiers like these, but none is universal, and administrators can remove or alter some headers.

An Age: 0 value is not proof of a cache hit; it is commonly returned for a miss or revalidation. A HIT, MISS or STALE value from a provider-specific header is more useful, provided the header identifies the caching layer. A generic x-cache label needs supporting evidence.

A second Server header may be removed at the edge. A Location header identifies a redirect destination, which may be on another provider entirely. Compare the placeholder’s headers with those of the final page so that an accelerated destination is not mistaken for acceleration of the landing page.

Use browser developer tools

Open developer tools in Chrome, Edge, Safari or Firefox, choose Network, reload the page and select the main document. The request list can reveal redirects, third-party hosts, remote addresses and the edge location returned by some providers. The Headers panel shows the raw response, while the Timing panel separates DNS lookup, connection setup, TLS negotiation, time to first byte and download time.

The favicon can offer an identity clue, although it is not infrastructure evidence. An explainer on favicons describes how browsers retrieve that small icon. A shared-platform favicon may reveal a hosting or publishing service, but the icon can be cached, delegated or supplied separately from the page itself.

Keep the Network panel open while following the link. A blank document loaded from one hostname may hand you to another hostname with entirely different headers and timings. Record both sides of that journey, and use the browser’s Disable cache option for one controlled reload without confusing a local browser cache with a CDN edge cache.

Compare timings on Australian connections

Measure time to first byte, not merely how quickly the visible link appears. Make several requests over the same connection, compare the first request with later ones and repeat from a second Australian network. An NBN plan, fixed-wireless service, mobile hotspot and office Ethernet can each produce different routing and latency profiles.

Sydney and Melbourne have dense internet exchanges and extensive peering, while Perth and Brisbane are geographically farther from many northern-hemisphere origins. Adelaide connections can also take different paths. A low-latency result in one city may reflect a nearby edge or simply a good peering agreement, so timing supports other evidence rather than replacing it.

Watch for misleading comparisons. Compression, HTTP/2 or HTTP/3, warm browser caches and a nearby origin can all make a page feel fast. A CDN cache miss may still beat a slow origin, while a cache hit may be delayed by a congested mobile network. If results fluctuate, collect more samples rather than declaring a verdict from one fast load.

Separate delivery evidence from trust checks

Before following an unfamiliar redirect, inspect the destination URL, the final page and its privacy information. If you operate an Australian service, customer IP addresses and account identifiers remain personal information under the Privacy Act 1988 and the Australian Privacy Principles. Keep test logs limited, secure them appropriately and avoid promising that data stays in Australia merely because a CDN edge was detected.

If the destination is promotional, check the claims rather than assuming that a known platform has vetted it. The Australian Consumer Law prohibits misleading conduct, and gambling advertising rules vary by state and territory. For example, a page about progressive jackpots needs clear terms; reading progressive jackpot odds can help a reviewer identify missing explanations, but it cannot verify the site’s licence, identity or payout record.

Also check whether the page requests payments or personal information through an unrelated domain. A familiar favicon or Cloudflare header offers no assurance. Verify the business independently, consult the Australian Communications and Media Authority’s scam advice where appropriate and treat a “proceed” link as a prompt for caution rather than evidence of legitimacy.

Confirm and document the result

Repeat the DNS and header checks, then look for a coherent chain of evidence: a provider-associated CNAME or Anycast address, identifiable CDN headers, edge timings and requests served from the same network. A single feature can have another explanation. If the evidence is mixed, report “no CDN confirmed” rather than turning a weak clue into a definite claim.

Save the exact URL, test time, Australian connection type, DNS answers and raw headers. If an announcement is provided, check service news updates for context while keeping your own measurements as the primary record. Service changes can alter CNAME targets or cache behaviour overnight, so repeat the checks before an audit or purchase.

Open the minimal page in a private window on your usual Australian connection, run the DNS, header and Network panel checks, and record whether the main document is served by a CDN. If you operate the page, repeat the test from a mobile network and keep the evidence with your hosting records before changing a provider or making claims about data location.