Иногда нужно выяснить, где размещен чужой или собственный сайт, но название хостинг-провайдера неизвестно. Такая ситуация возникает чаще, чем кажется. Владелец проекта может получить сайт от предыдущего разработчика без нормальной документации, компания меняет сотрудника, который занимался инфраструктурой, или просто хочется понять, каким хостингом пользуется интересующий проект.
На первый взгляд задача кажется простой: у каждого сайта есть IP-адрес, значит достаточно определить его и посмотреть владельца сети. На практике между доменом и реальным сервером могут находиться CDN, прокси, защита от DDoS и другие промежуточные сервисы. В результате найденный IP иногда принадлежит совсем не тому хостеру, на котором физически находятся файлы и база данных сайта.
Поэтому определить хостинг сайта можно, но достоверность результата зависит от устройства самого проекта. Для обычного сайта на виртуальном хостинге задача часто решается за несколько минут. Для ресурса, скрытого за CDN или распределенной инфраструктурой, потребуется проверить несколько источников и не делать вывод по одному IP.
Что именно мы пытаемся найти
Домен и хостинг — разные услуги. Домен представляет собой адрес сайта, а хостинг предоставляет инфраструктуру, на которой работают его файлы, база данных и серверное программное обеспечение.
При этом регистратор домена и хостинг-провайдер могут быть одной компанией, а могут совершенно не совпадать.
Например, домен зарегистрирован у одного регистратора, DNS обслуживает другой сервис, а сам сайт находится на сервере третьей компании. Почта при этом может работать вообще у четвертого поставщика.
Поэтому информация о том, где зарегистрирован домен, еще не отвечает на вопрос, где находится сайт.
Нам нужно пройти цепочку от доменного имени к серверу, который фактически обслуживает веб-запросы, а затем определить сеть или компанию, связанную с этим сервером.
Самый простой способ начинается с IP-адреса
Когда пользователь вводит адрес сайта в браузере, доменное имя должно быть преобразовано в IP-адрес. Эту задачу выполняет DNS.
Если домен напрямую указывает на сервер хостинга, найденный IP становится хорошей отправной точкой.
Узнать его можно разными способами. Подойдут сетевые утилиты операционной системы, DNS-сервисы и специализированные сайты для проверки доменов.
В Windows, например, можно открыть командную строку и использовать:
nslookup example.ru
В ответе обычно будет указан один или несколько IP-адресов.
Сам адрес еще мало о чем говорит. Следующий шаг — определить, какой организации принадлежит соответствующая сеть.
Для этого используются данные об IP-диапазонах и автономных системах. Сервисы проверки IP могут показать организацию, которой выделен адрес, номер автономной системы и другую сетевую информацию.
Если в результате появляется название известного хостинг-провайдера или его инфраструктурной компании, вероятность того, что сайт размещен именно там, довольно высокая.
Но останавливаться на этом шаге стоит не всегда.
Почему IP может привести не к хостингу
Современный сайт далеко не обязательно доступен из интернета напрямую.
Между посетителем и исходным сервером может работать CDN. Он принимает запрос, отдает кэшированный контент и при необходимости обращается к основному серверу.
С точки зрения DNS пользователь видит IP узла CDN, а настоящий адрес хостинга остается скрытым.
Похожая ситуация возникает при использовании reverse proxy и сервисов защиты от DDoS. Публичный адрес принадлежит защитной инфраструктуре, через которую проходит трафик.
Если определить владельца такого IP, результат будет технически правильным, но не ответит на исходный вопрос. Вы узнаете, через какую сеть открывается сайт, а не где находится его основной сервер.
Это важное различие.
Поэтому найденное название крупного CDN-провайдера нельзя автоматически считать названием хостинга.
DNS-записи могут рассказать больше чем один IP
Полезно посмотреть не только A-запись домена, но и всю доступную DNS-конфигурацию.
Особый интерес представляют NS-записи. Они показывают, какие DNS-серверы обслуживают доменную зону.
Иногда по их именам легко определить компанию. Например, в названии nameserver может присутствовать домен конкретного хостинг-провайдера.
Это хороший признак, но опять же не абсолютное доказательство.
Владелец сайта может использовать DNS своего регистратора, отдельный DNS-сервис или оставить старые NS после переноса инфраструктуры.
Поэтому логика NS принадлежит компании X, значит сайт точно находится у X работает не всегда.
Зато сочетание нескольких признаков уже значительно надежнее. Если IP принадлежит определенному хостеру, NS связаны с ним же, а другие технические данные не противоречат этой версии, результат можно считать достаточно уверенным.
Не путайте хостинг сайта с почтовым сервером
В DNS есть MX-записи, которые определяют маршрутизацию электронной почты.
Иногда при проверке домена человек видит знакомое название компании именно там и решает, что нашел хостинг.
Но MX относится к почте.
Сайт может находиться на виртуальном хостинге одного провайдера, а корпоративная почта обслуживаться специализированной платформой. Это совершенно нормальная схема.
То же относится к TXT-записям. В них могут находиться настройки проверки домена, почтовой безопасности и различных внешних сервисов. Наличие названия компании в TXT не доказывает, что она размещает сам сайт.
Для поиска веб-хостинга в первую очередь интересуют записи, которые участвуют в открытии самого сайта.
Можно ли определить хостинг через WHOIS
WHOIS часто вспоминают первым, когда нужно что-нибудь узнать о домене. Но для поиска хостинга его возможности ограничены.
Информация о домене в первую очередь относится к регистрации: регистратору, срокам и техническим данным доменного имени.
Хостинг там может вообще не фигурировать.
Если домен и хостинг приобретались у одной компании, результат иногда наводит на правильную мысль. Но это совпадение организационной схемы, а не надежный метод определения сервера.
Гораздо полезнее проверять данные самого IP-адреса, если удалось определить реальный адрес исходного сервера.
Для IP существуют сведения о выделенном диапазоне и организации, которой он принадлежит. Именно они помогают понять, через какую сеть работает сервер.
Иногда ответ находится прямо в HTTP-заголовках
При открытии сайта сервер отправляет не только HTML-код страницы, но и HTTP-заголовки.
В них может содержаться информация о веб-сервере, прокси, кэше или других компонентах инфраструктуры.
Иногда встречаются специфические заголовки, позволяющие предположить используемую платформу или сервис.
Однако это вспомогательный метод.
Администратор может скрыть или изменить часть заголовков. Многие сайты используют стандартный nginx или Apache, что вообще ничего не говорит о конкретном провайдере. А наличие заголовка CDN снова укажет только на промежуточный сервис.
Поэтому HTTP-заголовки лучше рассматривать как дополнительную улику, а не как основной способ.
Что делать если сайт использует CDN
Здесь задача становится интереснее.
Если текущий DNS ведет на CDN, публичный IP исходного сервера скрыт. Обычная проверка покажет только инфраструктуру CDN.
Для собственного сайта проблема решается легко: достаточно открыть панель хостинга, DNS-настройки или конфигурацию CDN и посмотреть адрес origin-сервера.
С чужим сайтом такой возможности нет.
Иногда помогают исторические DNS-данные. Если раньше домен указывал непосредственно на сервер, в истории может сохраниться старый IP. После подключения CDN сайт мог остаться на том же хостинге.
Но здесь появляется важное ограничение: старый адрес не обязательно актуален.
Сайт мог одновременно переехать на другой сервер, сменить провайдера или полностью изменить инфраструктуру. Поэтому исторический IP является подсказкой, а не доказательством текущего размещения.
Кроме того, не стоит пытаться обходить защиту сайта или искать способы получить скрытый origin вопреки настройкам владельца. Для обычной задачи определения хостинга достаточно открытых технических данных.
История DNS полезна при расследовании переездов
У домена за годы существования могут смениться несколько IP-адресов и хостинг-провайдеров.
Исторические данные позволяют увидеть эту картину.
Например, сегодня сайт работает через CDN, полгода назад домен указывал на один IP, а два года назад на другой. Проверка владельцев этих сетей позволяет приблизительно восстановить историю размещения.
Это полезно не только из любопытства.
При покупке старого сайта новый владелец может пытаться понять, где он находился раньше. При техническом аудите история помогает обнаружить старые серверы, которые могли остаться активными после миграции.
Но для ответа на вопрос где сайт находится сейчас приоритет всегда должен иметь текущая конфигурация.
Как узнать хостинг собственного сайта если потеряны доступы
Это отдельный и довольно распространенный сценарий.
Сайт работает, домен оплачен, но никто в компании уже не помнит, где находится хостинг. Разработчик перестал сотрудничать, старый сотрудник уволился или услуга оформлялась несколько лет назад.
Начинать лучше не с технических расследований, а с документов.
Проверьте корпоративную электронную почту по словам хостинг, сервер, домен, продление, счет, тариф и названиям известных провайдеров. Посмотрите банковские операции и бухгалтерские документы. Хостинг обычно оплачивается регулярно, поэтому платеж позволяет быстро определить поставщика.
Затем проверьте DNS домена.
Если NS или IP указывают на конкретную компанию, версия становится еще вероятнее.
После этого можно обратиться в поддержку провайдера. Но одного факта владения сайтом может быть недостаточно для получения доступа к чужому аккаунту. Компания должна убедиться, что обращается действительно владелец услуги.
Поэтому могут потребоваться данные аккаунта, информация о платежах и предусмотренная провайдером процедура восстановления доступа.
Если домен зарегистрирован у хостера задача упрощается
Многие владельцы покупают домен и хостинг в одном месте. Тогда обе услуги отображаются в одном личном кабинете.
Если доступ к регистратору сохранился, стоит сначала проверить его панель.
В ней может оказаться и действующий тариф хостинга.
Но рассчитывать на это нельзя. Возможна обратная ситуация: домен когда-то купили у хостера, затем сайт перенесли в другую компанию, а регистрацию домена оставили на прежнем месте.
Поэтому даже знакомое название провайдера в данных домена лучше подтверждать текущими DNS и IP.
Можно ли определить конкретный тариф
Обычно нет.
По открытым данным иногда удается достаточно уверенно определить компанию или сеть, где работает сайт. Но узнать название тарифа, объем выделенных ресурсов или сумму ежемесячной оплаты намного сложнее.
На одном IP могут находиться сайты разных тарифов. Более того, один адрес виртуального хостинга способен обслуживать множество клиентов.
Снаружи невозможно достоверно определить, сколько дискового пространства доступно конкретному аккаунту, какие у него лимиты CPU или сколько сайтов разрешено разместить.
Если речь идет о собственном проекте, эта информация находится в панели управления и документах.
Если сайт чужой, любые сервисы, обещающие точно определить тариф и ресурсы по одному домену, стоит воспринимать осторожно.
Можно ли узнать где физически находится сервер
По IP можно приблизительно определить географию сети, но здесь тоже легко получить ложную точность.
Базы геолокации IP не являются картой серверных стоек. Они могут показывать страну, город или место регистрации сетевого блока, но сервер физически способен находиться в другом месте.
Если используется CDN, найденная география вообще может относиться к ближайшему узлу сети доставки контента.
Для собственного проекта точную локацию лучше смотреть у провайдера. В характеристиках услуги обычно указан дата-центр или хотя бы страна размещения.
Для чужого сайта корректнее говорить о предполагаемой локации, если нет надежного подтверждения.
Почему несколько сервисов показывают разных хостеров
Это не обязательно означает, что один из них сломан.
Один сервис может определять владельца IP. Другой пытается сопоставить адрес с брендом хостинг-компании. Третий анализирует NS. Четвертый использует собственную базу доменов.
Кроме того, инфраструктура провайдера может принадлежать другому юридическому лицу или работать на арендованных сетевых ресурсах.
Например, небольшая хостинг-компания арендует серверы в крупном дата-центре. По IP определяется оператор сети дата-центра, тогда как клиент покупал услугу у совершенно другого бренда.
Поэтому результат автоматического сервиса лучше воспринимать как гипотезу.
Чем важнее точность, тем больше независимых признаков нужно сопоставить.
Надежная проверка выглядит как цепочка а не одна кнопка
Если требуется просто удовлетворить любопытство, достаточно одного сервиса определения хостинга. Для серьезной задачи лучше пройти несколько шагов.
- Определите текущие A и AAAA записи домена.
- Посмотрите владельца полученного IP и автономную систему.
- Проверьте NS домена.
- Убедитесь, что найденный IP не относится к CDN или сервису защиты.
- При необходимости посмотрите HTTP-заголовки.
- Если текущий адрес скрыт CDN, осторожно изучите исторические DNS-данные.
- Сопоставьте результаты, а не доверяйте одному признаку.
Если IP и NS связаны с одним провайдером и никаких промежуточных сервисов не обнаружено, обычно этого достаточно.
Если IP принадлежит CDN, а NS отдельному DNS-сервису, по открытым текущим данным определить реальный хостинг может быть невозможно.
И это тоже нормальный результат проверки.
Зачем вообще узнавать хостинг чужого сайта
Одна из причин — выбор площадки для собственного проекта.
Человек видит быстрый сайт конкурента и хочет узнать, где тот размещается. Технически хостинг определить иногда можно, но копировать решение вслепую не стоит.
Вы не знаете тариф, реальную серверную архитектуру, систему кэширования, наличие CDN и качество оптимизации самого сайта.
Два проекта на одном хостинге могут показывать совершенно разную скорость.
Поэтому найденный провайдер можно добавить в список кандидатов, но выбирать его только потому, что там работает известный сайт, не стоит.
Гораздо полезнее сравнить условия тарифа с требованиями собственного проекта.
Другая причина — технический аудит. Если компания получила сайт без документации, определение инфраструктуры становится первым шагом к восстановлению контроля над проектом.
В этом случае после нахождения хостинга стоит сразу разобраться с доступами, владельцем аккаунта, оплатой, резервными копиями и контактными данными.
Что делать после того как хостинг найден
Если вы искали хостинг собственного сайта из-за потерянной документации, на названии провайдера останавливаться не стоит.
Нужно выяснить, на кого зарегистрирован аккаунт, какой email используется для восстановления доступа, кто оплачивает услугу и когда заканчивается оплаченный период.
После восстановления доступа проверьте резервные копии и сохраните независимую копию сайта. Убедитесь, что компания контролирует домен, DNS и хостинг, а не зависит от личного аккаунта бывшего разработчика.
Заодно полезно посмотреть тариф. Старый сайт может много лет работать на услуге, которая уже не соответствует его потребностям. Или наоборот, компания продолжает оплачивать мощный сервер, хотя проект давно можно разместить на обычном виртуальном хостинге.
Если же вы определяли площадку чужого сайта перед выбором собственного хостинга, используйте результат только как один из ориентиров. Посмотрите тарифы найденного провайдера, ограничения ресурсов, резервное копирование, поддержку и условия продления. Затем сравните его еще с несколькими компаниями.
Можно ли всегда точно узнать хостинг сайта
Нет, и это важно учитывать.
Обычный сайт, домен которого напрямую указывает на сервер провайдера, определить сравнительно легко. IP, сведения о сети и NS часто дают достаточно понятный ответ.
Если используется CDN, reverse proxy, распределенная облачная инфраструктура или внешняя защита, открытые данные могут показывать только промежуточный уровень.
В таком случае не нужно пытаться превратить предположение в уверенный факт.
Правильный результат иногда звучит так: сайт использует инфраструктуру определенного CDN, но реальный origin-хостинг по публичным данным установить нельзя.
Для собственного сайта всегда надежнее идти от учетных записей, платежей и DNS-конфигурации. Для чужого — сопоставлять IP, владельца сети, NS и другие открытые технические признаки.
Именно такой подход позволяет не перепутать регистратора домена с хостером, почтовый сервис с веб-сервером, а CDN с площадкой, на которой на самом деле хранится сайт.
