По домену открывается другой сайт: DNS, хостинг или редирект

Если по вашему домену открывается другой сайт, сначала посмотрите на адресную строку: имя осталось прежним или браузер перешёл на новый адрес? В первом случае исследуйте назначение DNS и выбор приложения на сервере, во втором — цепочку переходов. Сам факт чужой страницы ещё не доказывает взлом.

Два похожих экрана с разными причинами

Владелец видит чужой логотип и просит убрать редирект. Однако адрес в браузере может вообще не меняться: нужный сервер получил запрос, но выбрал другое приложение. Если сразу искать вредоносное перенаправление, можно пропустить обычную ошибку настройки после переезда.

Обратная ситуация тоже возможна: DNS ведёт на правильную площадку, но приложение переводит посетителя на старое имя. Поэтому сохраните исходный адрес, конечный адрес и последовательность переходов из сетевой панели браузера. Не ограничивайтесь фотографией чужой главной страницы: она показывает результат, но почти ничего не говорит о маршруте.

Составьте паспорт одного наблюдения

• Какой полный адрес был введён, включая протокол и вариант имени.
• Какой адрес остался после загрузки страницы.
• Какое время и подключение использовались при проверке.
• Какой сетевой ответ и переход видны для основного документа.
• Какой сервер должен обслуживать это имя по плану размещения.

Отдельное наблюдение не распространяйте на все устройства и адреса компании. Основное имя, вариант с www и поддомен могут обслуживаться по-разному. Если проблему видят только на одном компьютере, добавьте сравнение с другим разрешённым подключением; не объявляйте результат первой проверки общим состоянием DNS.

Развилки по месту расхождения

Таблица задаёт порядок исследования, а не устанавливает диагноз по одному признаку. Например, прежнее имя в браузере не позволяет без проверки обвинить именно Nginx: перед приложением может находиться другой обслуживающий узел. Укажите, какой компонент действительно виден в вашей схеме размещения.

Когда IP правильный, а приложение чужое

В описании обработки запросов Nginx показано, как имя Host участвует в выборе виртуального сервера. При отсутствии подходящего имени запрос может попасть в сервер по умолчанию для соответствующей точки прослушивания. Совпадение IP поэтому не доказывает правильность выбора сайта.

Сверьте ожидаемое доменное имя с конфигурацией обслуживающего проекта. Проверять надо действующую схему, а не только файл, который когда-то подготовили для переноса. Если доступна панель хостинга, начните с её назначения доменов; при ручном управлении попросите администратора подтвердить используемую конфигурацию без публикации её секретов.

Для HTTPS есть дополнительный этап: в документации Nginx о TLS объясняется передача имени через SNI при установлении соединения. Проверка голого IP не воспроизводит обычное обращение по домену. Исправление только HTTP-настройки не подтверждает, что HTTPS обслуживает тот же проект.

Что проверить у регистратора и хостера

Рег.ру в своей инструкции о чужом сайте рассматривает случай A-записи, ведущей на другую площадку. Это полезная конкретная причина, но не объяснение всех подобных экранов в интернете. При обращении провайдеру нужно назвать услугу, с которой ожидается правильный сайт.

Если домен недавно куплен или восстановлен, выясните, какие прежние назначения сохранились. Право управления именем и состояние чужого старого проекта — разные вопросы. Для поддержки сервера подготовьте ожидаемую схему, время появления проблемы и результат сопоставления адресов, чтобы специалист проверял конкретное направление.

Меняйте одно подтверждённое звено

1. Сохраните текущее назначение имени и свидетельство неправильного результата.
2. Определите границу расхождения: DNS, HTTPS, выбор сайта, переход или само приложение.
3. Согласуйте изменение именно этого участка и способ возврата прежней настройки.
4. Повторите исходный запрос тем же способом и сравните сохранённые наблюдения.
5. Проверьте остальные согласованные варианты домена и критичные пользовательские страницы.

Не отключайте делегирование как стандартный способ лечения. Рег.ру отдельно предупреждает, что это затрагивает все сервисы домена, включая почту. Когда требуется лишь направить сайт на нужный проект, потеря остальных сервисов не помогает выяснить причину и расширяет проблему.

Когда обращаться к специалисту по безопасности

Если найдено неизвестное правило перехода, неподтверждённое изменение DNS или чужая правка приложения, зафиксируйте признаки и ограничьте дальнейшие изменения до разбора. Проверка безопасности сайта должна опираться на события и доступы, а не только на чужое изображение на экране. Не удаляйте подозрительные файлы до сохранения материалов для анализа.

После обычного исправления маршрута проверьте, кто и как будет поддерживать схему размещения. Через техническую поддержку сайта можно закрепить список доменов и ожидаемых проектов. Такая опись особенно полезна, когда одна компания держит основной сайт, тестовую версию и старый лендинг на общей инфраструктуре.