CDN Radar
Testing…
These results reflect your current network and routing rules.
Test all 14 CDNs and see which is closest
Which IP does each site see?Test your speedLatency to 40 popular servicesCompare CDN prices
The page downloads a small file from res-1.cdn.office.net, which is on Akamai and lets other sites read its response. The Akamai-Request-Bc header names the data center that answered.
CloudflareCloudflare China NetworkAmazon CloudFrontFastlyAzure Front DoorBunny CDNWikimediaGoogleAlibaba CloudTencent EdgeOneWangsu (CDNetworks)GcoreCDN77
It shows which data center of each big CDN serves you, how far away it is, and your latency to it.
A CDN keeps copies of websites in data centers around the world, often called PoPs or edge locations. The closer the one that serves you, the faster sites on that CDN usually load. But a CDN doesn't always send you to the nearest one.
Your browser downloads a small file from each CDN, just as it would when you open a website, and reads which data center answered. The page then shows the distance, your latency, and the fastest that distance allows.
These test requests go straight from your browser to the CDNs. They don't pass through this site.
Usually nothing is wrong with your device. The CDN and your internet provider chose that route.
Why: CDNs don't simply pick the nearest data center. Cloudflare and others use anycast, where the same address works from many places at once, and your provider's network decides which path you take. Akamai, CloudFront and others choose by where your DNS resolver is. In mainland China, sites on Cloudflare's free and cheaper plans are often served from the US west coast or other far-off data centers on many networks, because those routes cost less. Only the paid China Network (with JD Cloud) serves from mainland China or Hong Kong.
What it means: the farther the data center, the longer every request takes to go there and back. Pages, images and videos load more slowly, and things can stall more at busy times.
What you can do: if you use a proxy or VPN, the CDN serves you based on where the proxy is, so compare with "Test only direct or only through a proxy". If you use a public DNS resolver such as 8.8.8.8, switching back to your provider's may get you a closer data center from CDNs that choose by DNS. You can also compare another network, such as mobile data and home broadband. Which CDN and plan a site uses is up to the site.
Each CDN writes it into its response, each in its own way:
Cloudflare: the colo field of /cdn-cgi/trace (HKG).
Amazon CloudFront: the cdn-pop entry of Server-Timing, or X-Amz-Cf-Pop (NRT57-P11).
Akamai: Akamai-Request-BC, which names the city (JP_13_TOKYO).
Fastly: X-Served-By (cache-nrt-…-NRT).
Azure Front Door: X-Azure-Ref (…C1TYO…).
Bunny: the Server header (BunnyCDN-JP1-…).
Wikimedia: X-Cache, where the cache server's number identifies the data center.
A browser can only read these when the response allows it, so each CDN is tested with a public file whose response does. Google, Alibaba Cloud, Tencent EdgeOne, Wangsu, Gcore and CDN77 don't allow it, so they're only timed.
It's the lowest latency the distance allows. A real connection can't be faster.
Light in fiber travels about 200 km per millisecond. Going there and back over a distance d, latency can't be lower than d ÷ 100 ms. Real routes are usually 1.5 to 2 times longer than a straight line.
When latency is more than twice that, plus 40 ms, it's marked "Long way round": the route detours, or waits on a congested link.
The CDN has a data center closer to you but didn't use it.
For the CDNs that publish all their data centers (Cloudflare, Bunny, Wikimedia), the page finds the one nearest to you. When the one that answered is more than 1,000 km farther and over twice as far, it's marked.
It isn't a fault: the CDN or your provider chose another route. For why, and what you can do, see "Why am I sent to a data center far away, and does it matter?"
Enter a domain to see which CDN it uses, which data center serves you, and your latency.
This site's Worker looks up the domain with Cloudflare's DNS, so a local or tampered answer can't mislead it, and recognizes the CDN from where its CNAME points. It also requests /cdn-cgi/trace on the site to spot Cloudflare and, when the site allows it, reads the data center from its favicon's headers. Then it measures the site's latency.
The domain is sent to this site's Worker and to Cloudflare's DNS. This site doesn't keep it.
From your IP address, as Cloudflare places it (this site runs on Cloudflare). It's usually right to the city, but can be off by hundreds of kilometers, and with a proxy it's the proxy's location.
"Use precise location" uses your browser's location instead. It's used only on this page. It goes into a share link, to about 10 km, only if you tick the box when sharing.
This site doesn't keep your test results.
The test requests go straight from your browser to each CDN, which sees your IP address like any website you visit. This site only helps the page with two things: your rough location from your IP address, and city names for data center codes.
A share link contains the data centers and your latency. Your city, its coordinates (to about 10 km) and your provider are added only if you tick the box, and your IP address never is. The code is open source on GitHub.
A web page can't choose whether a request goes direct or through a proxy. Your proxy client decides that, using its routing rules. By default, the test shows how things are for you every day.
To test only one way, put these rules at the top of your client's rule list, then run the test again. All direct tests your own network. All through the proxy tests the route from the proxy server to each CDN. Remove the rules when you're done.
From mainland China with everything direct, some CDNs may not connect. That's a result too.
Runs entirely in your browser. No account, and we don't collect your results.
© 2026 1ms.dog