--- 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. [How to use this tool](/blog/how-to-check-if-your-cdn-is-caching) Result No result yet Fill in the form above and run it — the result appears here. Monitor this 24/7 — get alerted when a failure is confirmed. [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. Get alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 monitors. No card. [Start free](/auth/sign-up) ## Frequently asked questions How is this different from just checking which CDN a site uses? Naming the provider is one line of the report. The rest measures whether the CDN is doing anything useful: three requests from every probe location, the cache decision each edge made, which edge answered, how the timings break down, whether every region serves the same bytes, and which regions are outliers against their neighbours. Why three requests instead of one? Because one request cannot distinguish "this is not cacheable" from "this is not cached yet". A sequence can: MISS → HIT → HIT is an edge working correctly, MISS → MISS → MISS is an object that never caches. That distinction is the single most useful thing in the report. Does it render the page or measure Core Web Vitals? No — deliberately. This is a network-level analysis: no browser, no JavaScript execution, no page rendering. That keeps it fast and focused on delivery. For rendering metrics use the Core Web Vitals checker, which is a separate tool. Why does it say "None" when I know the site uses a CDN? Usually one of three reasons: the CDN is in a transparent or DNS-only mode so it adds no proxy headers; the CDN fronts a different hostname than the one you checked (often static. or assets. ); or it is an edge network whose fingerprints we do not recognise yet. When we can see a caching layer but cannot name it, the report says that instead of guessing. The grade is lower than I expected. Why? Expand "How this grade was reached". Every category shows its score, its weight and the exact deductions in plain sentences. The most common surprises are an object that never caches despite cacheable headers, and one region that is far slower than its neighbours. Can it detect a WAF or DDoS-protection service? Indirectly — most WAF/DDoS services (Cloudflare, Akamai, Imperva) are also CDNs and share the same fingerprints, so they show up as the provider. It will not tell you which security features are enabled, only which edge network is in front. Is detecting a CDN a security risk for my site? No — the CDN identity is public by design (it is in your DNS and your response headers). The real risk is the opposite: if your origin server still answers on its own IP, attackers can bypass the CDN entirely. Detecting the CDN is the prompt to go verify your origin is locked down. Different regions reported different providers. Is that broken? Not necessarily — that is exactly what a deliberate multi-CDN setup looks like, and the report shows which locations saw which provider. It is only a surprise if you are not running multi-CDN on purpose, in which case a migration is probably still half-applied. ## Related web tools - [Software Exposure CheckerSee which software versions your website reveals in its headers and HTML — web server, PHP, CMS, JavaScript libraries — and whether any is outdated, past end of life or has known CVEs. Graded A+ to F, with the fix for each. One plain GET, no signup.](/software-exposure-checker) - [PHP Version CheckerCheck your PHP version, EOL date and known CVEs — php2shell (CVE-2026-109618, CVE-2026-109619) first — from the headers your server already sends. Graded A+ to F, with the exact version to upgrade to. Passive: plain GET requests only, no signup.](/php-version-checker) - [MCP Server CheckerTest a Model Context Protocol server the way an agent does — initialize handshake, protocol version, HTTPS, sign-in discovery and the full tool inventory — and get an A+ to F grade with the exact fix for every problem. Open servers are never marked down for being open.](/mcp-server-checker) - [SSL Certificate CheckInspect certificate validity, expiry, SANs, issuer and chain trust.](/ssl-checker) --- Canonical page: https://watchfor.io/cdn-checker · Site guide: https://watchfor.io/llms.txt