CDN-радар
Проверяем…
Результаты отражают вашу текущую сеть и правила маршрутизации.
Какой IP видит каждый сайт?Проверить скоростьЗадержка до 40 популярных сервисовСравнить цены CDN
Страница скачивает маленький файл с static.figma.com, который лежит на Amazon CloudFront. Поле Cdn-Pop в заголовке Server-Timing называет дата-центр, который ответил.
CloudflareCloudflare China NetworkAkamaiFastlyAzure Front DoorBunny CDNWikimediaGoogleAlibaba CloudTencent EdgeOneWangsu (CDNetworks)GcoreCDN77
Какой дата-центр каждого крупного CDN вас обслуживает, как далеко он и какая до него задержка.
CDN хранит копии сайтов в дата-центрах по всему миру; их ещё называют точками присутствия (PoP) или узлами. Чем ближе тот, что вас обслуживает, тем быстрее обычно открываются сайты на этом CDN. Но CDN не всегда отправляет вас в ближайший.
Ваш браузер скачивает с каждого CDN маленький файл — так же, как при открытии сайта, — и узнаёт, какой дата-центр ответил. Затем страница показывает расстояние, задержку и минимум, который допускает это расстояние.
Эти тестовые запросы идут напрямую из вашего браузера в CDN, минуя этот сайт.
Обычно дело не в вашем устройстве: этот маршрут выбрали CDN и ваш провайдер.
Почему: CDN выбирают дата-центр не только по расстоянию. Cloudflare и другие используют anycast — один и тот же адрес работает сразу из многих мест, а путь выбирает сеть вашего провайдера. Akamai, CloudFront и другие выбирают по тому, где находится ваш DNS-сервер. В материковом Китае сайты на бесплатном и дешёвых тарифах Cloudflare во многих сетях обслуживаются с западного побережья США или из других далёких дата-центров, потому что такие маршруты дешевле. Из материкового Китая или Гонконга обслуживает только платная China Network (с JD Cloud).
Чем это плохо: чем дальше дата-центр, тем дольше каждый запрос идёт туда и обратно. Страницы, картинки и видео грузятся медленнее, а в часы пик всё чаще подтормаживает.
Что можно сделать: с прокси или VPN CDN выбирает дата-центр по местоположению прокси — сравните с помощью «Проверить только напрямую или только через прокси». Если у вас публичный DNS вроде 8.8.8.8, возврат на DNS провайдера может дать более близкий дата-центр у тех CDN, что выбирают по DNS. Ещё можно сравнить с другой сетью, например мобильным интернетом и домашним. Какой CDN и тариф использует сайт, может изменить только сам сайт.
Каждый CDN пишет его в ответ, каждый по-своему:
Cloudflare: поле colo в /cdn-cgi/trace (HKG).
Amazon CloudFront: запись cdn-pop в Server-Timing или X-Amz-Cf-Pop (NRT57-P11).
Akamai: Akamai-Request-BC, где указан город (JP_13_TOKYO).
Fastly: X-Served-By (cache-nrt-…-NRT).
Azure Front Door: X-Azure-Ref (…C1TYO…).
Bunny: заголовок Server (BunnyCDN-JP1-…).
Wikimedia: X-Cache, где номер кеш-сервера указывает на дата-центр.
Браузер может прочитать это, только если ответ разрешает, поэтому каждый CDN проверяется на публичном файле, который это разрешает. Google, Alibaba Cloud, Tencent EdgeOne, Wangsu, Gcore и CDN77 не разрешают, поэтому для них измеряется только задержка.
Это самая низкая задержка, которую допускает расстояние. Реальное соединение не может быть быстрее.
Свет в оптоволокне проходит около 200 км за миллисекунду. Туда и обратно на расстояние d задержка не может быть меньше d ÷ 100 мс. Реальные маршруты обычно в 1,5–2 раза длиннее прямой.
Если задержка больше двух таких минимумов плюс 40 мс, она помечается «В обход»: маршрут петляет или стоит в очереди на перегруженном канале.
У CDN есть дата-центр ближе к вам, но он не был использован.
Для CDN, которые публикуют все свои дата-центры (Cloudflare, Bunny, Wikimedia), страница находит ближайший к вам. Если ответивший дальше него более чем на 1000 км и более чем вдвое, это помечается.
Это не сбой: CDN или ваш провайдер выбрали другой маршрут. Почему так и что можно сделать — в разделе «Почему меня обслуживает далёкий дата-центр и чем это плохо?».
Введите домен — и увидите, какой CDN он использует, какой дата-центр вас обслуживает и какая задержка.
Worker этого сайта запрашивает домен через DNS Cloudflare, чтобы локальный или подменённый ответ не сбил его с толку, и узнаёт CDN по тому, куда указывает CNAME. Ещё он запрашивает /cdn-cgi/trace на сайте, чтобы распознать Cloudflare, и, если сайт разрешает, читает дата-центр из заголовков его favicon. В конце измеряется задержка до сайта.
Домен уходит в Worker этого сайта и в DNS Cloudflare. Этот сайт его не хранит.
Из вашего IP-адреса — так, как его определяет Cloudflare (этот сайт работает на Cloudflare). Обычно город угадывается верно, но ошибка может быть в сотни километров, а с прокси это местоположение прокси.
«Точное местоположение» берёт координаты из браузера. Они используются только на этой странице и попадают в ссылку, с точностью около 10 км, только если вы отметите это при отправке.
Этот сайт не хранит результаты ваших проверок.
Тестовые запросы идут напрямую из вашего браузера в каждый CDN, и он видит ваш IP-адрес, как любой сайт, который вы открываете. Этот сайт помогает странице только в двух вещах: определяет ваше примерное местоположение по IP и подставляет названия городов к кодам дата-центров.
В ссылке, которой вы делитесь, есть дата-центры и задержка. Ваш город, его координаты (с точностью около 10 км) и провайдер добавляются, только если вы поставите галочку, а IP-адрес — никогда. Код открыт и лежит на GitHub.
Веб-страница не может выбрать, пойдёт запрос напрямую или через прокси: это решает ваш прокси-клиент по своим правилам маршрутизации. По умолчанию проверка показывает, как всё работает у вас каждый день.
Чтобы проверить только один вариант, поставьте эти правила в начало списка правил клиента и запустите проверку снова. Всё напрямую — проверка вашей собственной сети. Всё через прокси — проверка пути от прокси-сервера до каждого CDN. После проверки удалите правила.
Из материкового Китая при подключении напрямую некоторые CDN могут быть недоступны. Это тоже результат.
Всё работает в вашем браузере. Без регистрации, а результаты мы не собираем.
© 2026 1ms.dog