--- title: Free Global CDN Checker description: Analyse how a URL is actually delivered worldwide — which CDN serves it, which edge answers in each region, whether it is really being cached, and which regions are behaving differently. Three requests from every probe location, one graded report. canonical: https://watchfor.io/cdn-checker --- [Back to all free tools](/free-tools) # Global CDN Checker Analyse how a URL is actually delivered worldwide — which CDN serves it, which edge answers in each region, whether it is really being cached, and which regions are behaving differently. Three requests from every probe location, one graded report. Result No result yet Enter the inputs above and press Run. Results appear here in a moment. Monitor this 24/7 — get alerts on the first failure. [Start free](/auth/sign-up) Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms). ## What is Global CDN Checker ? A CDN sits between your origin server and the rest of the internet — caching content at the edge, terminating TLS, absorbing traffic spikes, and (often) shielding your origin's real IP. Most of the time you never think about it, until the day a cache won't purge, one region serves stale content, or a page that should be instant is slow for half a continent and fast everywhere else. Knowing which CDN you are behind is the easy part, and usually the part you already know. What is hard to see from one machine is whether the thing is doing its job: whether your object is genuinely being cached rather than fetched from your origin every time, which edge answers in each part of the world, whether every region gets the same bytes, and which regions are behaving differently from their neighbours. That is what this tool measures. Paste a URL — a page, a script, an image, anything public — and WatchFor requests it three times in a row from every one of its probe locations, then reads what the edges said. You get a CDN Health grade from A+ to F, a world map, the cache behaviour per region, and a plain-language list of what is worth fixing. No login, no agent on your server, no browser rendering: just the network, measured from many places at once. ## How it works Every location runs the same short sequence, and the sequence is the point: - 1 Three requests, not one — A single request can tell you the edge missed its cache. It cannot tell you whether the object is uncacheable or simply was not cached yet. Three requests in a row can: MISS → HIT → HIT is an edge populating its cache exactly as intended, while MISS → MISS → MISS means the object never became cacheable at that location. Each request opens its own connection, so you also get an honest DNS, TCP, TLS and time-to-first-byte breakdown for each one. - 2 From every region at once — The same URL is requested in parallel from all of WatchFor's public probe locations across the Americas, Europe, Africa, Asia and Oceania. A problem that only exists in São Paulo is invisible from a laptop in Berlin, and the only way to see it is to ask from São Paulo. - 3 Identify the provider from several angles — The DNS chain (a CNAME to *.cloudflare.net , *.akamaiedge.net , *.fastly.net , *.cloudfront.net , *.b-cdn.net …), the network the edge address is announced from, the provider-specific response headers ( CF-Ray , X-Amz-Cf-Id , X-Served-By , Cdn-PullZone …), and the Server and Via headers. Each signal is weighed separately, and the report shows you which ones matched so you can disagree with it. - 4 Read the edge's own verdict — Every provider publishes its cache decision in its own words — Cloudflare's cf-cache-status , Akamai's TCP_MEM_HIT , CloudFront's Hit from cloudfront , Bunny's cdn-cache . These are normalised to one vocabulary so regions can be compared, while the original wording is kept next to it. Where a provider identifies its edge, that is shown too: the RIX in a Cloudflare ray, the FRA56 in a CloudFront POP. - 5 Compare, then explain — Response bodies are hashed so you can see whether every region is serving the same file. Latency is compared against the median of comparable locations rather than a fixed threshold, so an evenly slow site is not scolded and a single slow region cannot hide. Then a fixed set of rules — not a language model — turns the measurements into findings, each with the numbers behind it. Where the data cannot settle a question, the report says so rather than guessing. A provider that publishes no cache header gets unknown , not a failing grade; a region we could not reach over IPv6 is reported as untested rather than as your fault. A confident wrong answer would be worse than no answer. ## When you'd use it ### Your CDN is on, but is it actually caching? The most common CDN problem is not an outage — it is an edge that dutifully forwards every request to your origin because a cookie, a query string or a Vary header quietly made the object uncacheable. Three requests from twenty places make that obvious in seconds. ### One region is slow and you cannot reproduce it A customer in Mumbai says the site is slow; it is fast for you. The report compares each location against its regional neighbours and tells you whether the slow one is also missing its cache (your origin) or hitting it and still slow (routing or the edge itself). ### Cache / purge debugging Stale content will not go away after a deploy. See which regions still hold the old copy, what their cache status says, and what your own Cache-Control actually permits — the gap between "may be cached" and "never is" is usually where the answer lives. ### Migration and multi-CDN verification Moving from CloudFront to Fastly, or splitting traffic between two providers. The report names the provider per region, so a half-applied migration or an unintended split shows up as a finding instead of as a mystery. ### Origin-exposure audit A CDN only protects your origin if the origin IP is not reachable directly. Identifying the edge is step one; the dangerous follow-up is whether the bare origin still answers on its own IP — a common DDoS-bypass hole. ## Reading the result ### CDN Health grade A letter from A+ to F over six weighted categories: availability (25%), cache (25%), latency (20%), consistency (15%), edge health (10%) and protocols (5%). Every deduction is listed with the reason, so the grade is arguable rather than mysterious. Any location that cannot load the URL caps the grade at C, however tidy everything else is. ### The cache sequence Three chips per location, in request order. MISS HIT HIT is healthy — the edge fetched once and served from cache after. HIT HIT HIT means it was already cached. MISS MISS MISS means it never cached at this location. BYPASS or DYNAMIC means the edge deliberately did not cache, which is a configuration choice rather than a fault. ### Edge The point of presence that answered, where the provider names one — RIX , FRA56 , SIN . Blank is normal for providers such as Akamai that publish no edge identifier; it is not a failure. ### TTFB and total Time to first byte is how long the edge took to start answering; total includes downloading the body. Compare them across regions rather than against an absolute number — the report already does, against each location's regional median. ### Content consistency A SHA-256 of each region's response body, taken after decompression so brotli and gzip regions compare equal. For a static asset, two different hashes mean two different files are being served — a partial purge, a stale edge, or origins on different builds. For HTML, differing content is usually just personalisation, and the report says so instead of raising an alarm. ### Findings What the measurements imply, worst first, each with the numbers behind it and an action when there is one. They are produced by fixed rules, so the same measurements always produce the same findings. ## Reading cache headers: HIT, MISS, EXPIRED and the rest Every provider reports its cache decision in its own words. The checker normalises them into one vocabulary so regions can be compared, and keeps the original wording beside it so you can still recognise your own provider's dialect. Status What it means HIT Served from the edge cache. No request reached your origin. MISS Not in this edge's cache, so it was fetched from your origin. One miss is not a fault — it may be the first request for that object at that edge. What matters is whether the next one hits. EXPIRED Found in cache but past its TTL, so the edge revalidated with your origin before serving it. STALE Served from cache while it was refreshed in the background — stale-while-revalidate doing its job. REVALIDATED The edge asked your origin whether its copy was still good and was told yes, so no body was transferred. BYPASS The edge was configured to skip its cache for this request — a page rule, a cookie, a no-cache directive. A choice, not a fault. DYNAMIC Not eligible for caching at all, which is normal and correct for personalised HTML and most API responses. UNKNOWN The response carried no cache verdict we could read. That does not mean there is no CDN — several providers simply publish nothing. We report it as unknown rather than counting it as a miss. ## The provider headers behind it Each of these is read directly, so a value like Akamai's TCP_MEM_HIT is understood as a hit rather than shrugged at. Over sixty providers are recognised in total, including hosting platforms that run their own edge — Hostinger, Kinsta, SiteGround, Wix — and where a platform sits in front of a CDN the report names both rather than picking one. CDN Header Example value Cloudflare cf-cache-status HIT , DYNAMIC , BYPASS Amazon CloudFront x-cache Hit from cloudfront Fastly / Varnish x-cache HIT , MISS, HIT Akamai x-cache TCP_MEM_HIT , TCP_REFRESH_MISS Bunny CDN cdn-cache HIT Vercel x-vercel-cache HIT , STALE , PRERENDER Netlify (RFC 9211) cache-status "Netlify Edge"; hit Azure Front Door x-cache TCP_HIT , CONFIG_NOCACHE Anything else age + cache-control A non-zero age means a shared cache has been holding the response, which only happens on a hit. ## Checking the headers yourself The report is a lot of machines doing this at once. For a single location from your own terminal: curl -sI https://example.com/static/app.js \ | grep -iE 'cf-cache-status|x-cache|cdn-cache|x-vercel-cache|cache-status|age|cache-control|vary|set-cookie' Worth knowing what that will and will not tell you: it is one request from one place on a warm-ish connection, so it can confirm a header exists and cannot tell you whether the object stays cached, whether another continent agrees, or whether one region is four times slower than its neighbours. ## Common pitfalls ### The path matters more than the hostname Caching rules are set per path far more often than per host. example.com/ may be uncacheable HTML while example.com/static/app.js is cached for a year — checking only the apex tells you about the least cacheable thing on the site. Paste the URL you actually care about. ### A first MISS is not a problem We cannot know whether an edge held your object before we asked, so we never call the first request a cold cache. What matters is what happens on the second and third. ### Cloudflare in "DNS-only" (grey cloud) mode If a record is grey-clouded, Cloudflare is only doing DNS — not proxying — so none of the proxy headers appear and the site is served direct. That is a configuration choice, not a detection failure. ### Quiet providers Some edges can be configured to suppress their identifying headers, and a few publish no cache status at all. Detection then leans on the DNS chain and the edge's network. When nothing is conclusive the report says the provider could not be identified reliably — and an absent cache header is reported as unknown rather than counted against you. ### We measure from data centres, not from sofas Our probes sit in well-connected networks. Real users on mobile or residential links see higher latency than these numbers. What transfers accurately is the comparison between regions, which is what the report is built on. ## Run Global CDN Checker on every change, not just once. … --- Canonical page: https://watchfor.io/cdn-checker · Site guide: https://watchfor.io/llms.txt