Проверили сайт конкурента — а в результатах Cloudflare, или DDoS-Guard, или «Amazon Web Services»? Это не значит, что сайт хостится именно там.
Любая проверка хостинга опирается на цепочку: домен → DNS → IP → владелец IP (ASN) → имя хостера. Пока вся цепочка ведёт к одному провайдеру, результат точный. И так устроено примерно 80% сайтов на обычном виртуальном хостинге или VPS. Но между доменом и сервером может стоять прослойка — CDN, файрвол, DDoS-фильтр, которая подставляет свой IP вместо хостерского. Инструмент видит только прослойку. Что стоит за ней — из открытых данных не видно.
Ниже — семь конкретных ситуаций и что с каждой из них делать.
Почему результаты бывают неточными
1. CDN: Cloudflare, Fastly, Akamai и прочии
Самая частая причина. Cloudflare при полном проксировании подменяет сразу три сигнала: NS-серверы (*.ns.cloudflare.com), A-запись и ASN. Около 20% сайтов в мире работают через Cloudflare — и ни по одному из трёх сигналов определить реального хостера нельзя.
Fastly, Akamai, KeyCDN, BunnyCDN работают похоже, но есть нюанс в механике. Cloudflare забирает себе и NS, и IP. Часть CDN работает только через CNAME-проксирование — NS-серверы хостера остаются на месте. Тогда инструмент может определить хостинг по NS, даже увидев чужой IP.
В Рунете после рекомендаций РКН (ноябрь 2025) многие ушли с Cloudflare на DDoS-Guard, Stormwall, Servicepipe — с тем же эффектом для проверки. Подробнее — в рейтинге CDN.
2. WAF и DDoS-защита
WAF (Sucuri, Imperva, AWS WAF) и сервисы anti-DDoS (DDoS-Guard, Stormwall, Qrator) — технически одно и то же с точки зрения определения хостинга: обратный прокси, подмена IP. Разница в задачах — WAF фильтрует вредоносные запросы, DDoS-защита отсекает мусорный трафик. Но для проверки хостинга это не важно.
WAF при этом сложнее обнаружить. Cloudflare оставляет заголовок CF-Ray, по нему сразу все понятно. Sucuri Firewall может отдавать стандартный Server: nginx, ничем не выдавая себя. DDoS-Guard обнаруживается проще — по характерным IP-диапазонам.
В Рунете облачные WAF менее популярны, зато DDoS-Guard стал почти стандартом. Причём часть хостинг-провайдеров включает его в тариф автоматически. Владелец сайта уверен, что прослоек нет, а инструмент показывает DDoS-Guard. На shared-хостинге такое встречается регулярно.
3. Обратный прокси
Еще вариант — nginx или HAProxy перед основным сервером. Фронтенд на дешёвом VPS в Москве, бэкенд во Франкфурте — инструмент покажет хостера фронтенда.
4. Облачные платформы
«Amazon Web Services» в результатах проверки — технически правда, но не тот уровень ответа, ради которого проверяют хостинг. У AWS десятки сервисов (EC2, S3, Lambda, Lightsail), для инструмента всё это одно имя. А часть хостеров строит инфраструктуру поверх чужих облаков — ASN укажет на Amazon или Yandex, а не на конечного хостера с VPS-тарифами.
5. Нестандартные NS-серверы
Хостер использует сторонний DNS (Cloudflare DNS-only, dns.he.net, ClouDNS) — или пользователь сам перенёс DNS: домен на Reg.ru, DNS через Cloudflare, сайт на Beget. NS и IP указывают в разные стороны. Но в отличие от полного проксирования, IP здесь «чистый» — проверка по A-записи даст правильный ответ.
6. Выделенные серверы и аренда стоек в ДЦ
Если ASN принадлежит дата-центру (DataLine, Selectel, Hetzner и тп.), кто обслуживает сервер — владелец, аутсорсер, managed-провайдер — из IP и DNS не определить.
| Причина | Что видит инструмент | Хостинг скрыт? | Можно обойти? |
|---|---|---|---|
| CDN (Cloudflare и др.) | IP и NS CDN-провайдера | Да, полностью | Частично: история DNS, MX |
| WAF (Sucuri, Imperva) | IP WAF-сервиса | Да, полностью | Частично |
| DDoS-защита (DDoS-Guard) | IP защитного сервиса | Да, полностью | Частично |
| Обратный прокси (nginx) | IP прокси-сервера | Частично | Зависит от настройки |
| Облако (AWS, GCP, Yandex Cloud) | ASN облачной платформы | Нет, но имя обобщённое | Нет |
| Сторонний DNS | NS стороннего провайдера | Нет, IP верный | Да, по IP |
| Выделенный сервер | ASN дата-центра | Нет, но хостер не определяется | Нет |
Как узнать хостинг, если в результате проверки — CDN или WAF
Ни один из способов ниже не гарантирует результат, но в связке они срабатывают в 60–70% случаев.
MX-записи — почтовый сервер редко стоит за CDN. dig MX domain.com может вернуть mx1.beget.com, и хостинг определён. Не поможет, когда почта на Google Workspace или Яндекс 360 — MX покажет почтовый сервис.
История DNS через SecurityTrails или ViewDNS: старые A-записи за несколько лет. До подключения CDN домен указывал на реальный IP — он может быть в архиве.
Поддомены. ftp.domain.com, cpanel.domain.com часто указывают на реальный сервер, потому что не все владельцы проксируют служебные записи. На shared-хостинге cpanel.domain.com почти всегда ведёт на реальный IP.
HTTP-заголовки — X-Powered-By, X-Server, X-Hosted-By. Заголовки легко скрыть, поэтому это зацепка, а не ответ. curl -I domain.com покажет, что отдаёт сервер.
Наш Определитель хостинга комбинирует несколько из этих сигналов автоматически: DNS, ASN, HTTP-заголовки. И на из основе показывает уровень уверенности в результате. При обнаружении CDN или WAF инструмент предупреждает об этом в результатах, а не выдаёт имя CDN как «хостинг-провайдера».
Итого
Сервисы определения хостинга ошибаются не из-за плохого алгоритма. CDN, WAF, DDoS-защита намеренно скрывают реальный сервер — это их прямая задача. Прямое определение через DNS и WHOIS возможно не всегда, и точность растёт только при комбинации нескольких сигналов.
