Если сайт внезапно перенаправляет посетителя на рекламу, казино, чужую форму входа или неизвестный домен, это нельзя считать обычной ошибкой браузера. Причиной может быть неверное правило переадресации, забытая настройка CDN, сторонний скрипт или взлом. Важно не только вернуть правильную страницу, но и понять, где появился переход и не осталось ли механизма повторного заражения.
Ниже — безопасный порядок диагностики: что зафиксировать до изменений, как увидеть всю цепочку, почему редирект может срабатывать только у части посетителей и какие компоненты проверять владельцу сайта.
Что делать посетителю
Если чужой адрес просит пароль, данные карты, код подтверждения или установку файла, закройте страницу и ничего не вводите. Не пытайтесь обойти предупреждение браузера и не продолжайте оформление заказа на незнакомом домене.
Сообщите владельцу исходный URL, конечный адрес, примерное время и устройство, на котором произошел переход. Скриншот адресной строки полезнее фразы «сайт перекинул куда-то»: он помогает отличить подмену домена от рекламного окна или открытия новой вкладки.
Сначала сохраните доказательства
Не начинайте с очистки кеша, переустановки CMS или удаления всех правил. Сначала соберите факты, иначе редкий редирект исчезнет вместе со следами и вернется позже.
Запишите:
- исходный URL и адрес, на котором оказался посетитель;
- дату и время с часовым поясом;
- всю цепочку HTTP-кодов и промежуточных адресов;
- устройство, браузер, сеть и регион;
- был ли переход из поиска, рекламы, письма или по прямой ссылке;
- сработал ли редирект в приватном окне и при повторном открытии;
- какие релизы, плагины, DNS- или CDN-настройки менялись перед инцидентом.
Сохраните журналы веб-сервера, CDN, панели хостинга и CMS за соответствующий период. До массового удаления файлов сделайте резервную копию файлов, базы и конфигурации. Потенциально зараженную копию нельзя сразу возвращать в production или открывать как обычный сайт.
Как сайт может перенаправлять на другой адрес
Редирект создается на разных уровнях, поэтому проверка только одного файла часто ничего не дает.
HTTP-переадресация
Сервер, reverse proxy, CDN или приложение возвращает код 301, 302, 303, 307 либо 308 и заголовок Location. Браузер следует по указанному адресу. Такой переход виден в цепочке сетевых запросов.
Переход внутри HTML или JavaScript
Страница может сначала ответить кодом 200, а затем отправить пользователя через meta refresh или JavaScript. В этом случае проверка только первого HTTP-кода покажет «успех», хотя посетитель окажется на чужом домене.
Внешний скрипт, реклама или виджет
Скомпрометированный счетчик, рекламный код, чат, библиотека или тег-менеджер может выполнить переход уже в браузере. Удаление серверного правила не поможет, если команда загружается из внешнего ресурса.
DNS, CDN и чужая инфраструктура
DNS-запись сама по себе не содержит URL для перенаправления, но ошибочный A, AAAA или CNAME может привести пользователя на другой сервер. Уже этот сервер вернет чужую страницу или редирект. Отдельно проверьте правила перенаправлений на CDN и наличие неизвестных изменений в кабинетах регистратора и DNS-провайдера.
Service Worker и кеш браузера
Service Worker способен перехватывать запросы внутри области сайта, а браузер или CDN — хранить старый ответ. Но кеш нельзя автоматически объявлять причиной: сначала сравните результат в чистом профиле, на другом устройстве и при прямом запросе к URL.
Как отличить ошибочную настройку от возможного взлома
У обычной ошибки часто есть понятная связь с недавним изменением: переездом на HTTPS, сменой домена, запуском акции, правкой CMS или CDN. Переход воспроизводится стабильно для одного и того же URL и ведет на известный адрес компании.
Признаки, при которых нужно рассматривать компрометацию:
- переход ведет на рекламу, казино, поддельную форму или случайный домен;
- редирект срабатывает только у новых посетителей, на мобильных устройствах или после перехода из поиска;
- в CMS появились неизвестные администраторы, задания, плагины или фрагменты кода;
- изменились правила веб-сервера, шаблоны, база данных или внешние скрипты;
- после удаления одного правила переход возвращается;
- разные страницы ведут на разные посторонние адреса.
Ни один признак по отдельности не называет виновника. Например, переход только на мобильном устройстве может быть условием в легальном рекламном скрипте, ошибкой адаптивного шаблона или вредоносным кодом. Вывод делают после сравнения запросов, файлов, настроек и журналов.
Пошаговая диагностика неожиданного редиректа
Шаг 1. Воспроизведите переход в чистом сеансе
Откройте точный URL в приватном окне без активной сессии администратора. В инструментах разработчика включите сохранение сетевого журнала и посмотрите первый запрос, коды 3xx, заголовки Location, загрузку скриптов и конечный адрес.
Отдельно выполните внешнюю проверку URL, которая показывает HTTP-ответ и финальный результат. Для первичной диагностики можно использовать проверку сайта онлайн. Если браузер уходит на другой домен после ответа 200, изучайте HTML, JavaScript, Service Worker и внешние ресурсы, а не только серверные редиректы.
Шаг 2. Сравните разные условия
Проверьте сайт:
- с телефона и компьютера;
- из домашней и мобильной сети;
- по прямой ссылке и из поисковой выдачи;
- в обычном и приватном окне;
- при первом открытии и после повторного визита;
- с IPv4 и IPv6, если инфраструктура использует оба протокола.
Так выявляются условия по User-Agent, источнику перехода, cookie, региону или IP. Не делайте вывод о доступности для всех клиентов по одному рабочему браузеру администратора.
Шаг 3. Проверьте серверные правила
Сопоставьте правила во всех местах, где они могут задаваться:
- конфигурация веб-сервера и виртуального хоста;
- файлы правил в каталоге сайта;
- настройки reverse proxy;
- панель хостинга;
- правила редиректов CDN;
- маршруты приложения;
- SEO-, redirect- и security-плагины CMS.
Найдите источник конкретного перехода, а не удаляйте правила подряд. Похожая переадресация может быть нужна для HTTPS, основного домена или старых страниц. Если проблема ограничена переходами между собственными URL, пригодится отдельный разбор цепочек и петель редиректов.
Шаг 4. Проверьте CMS, файлы и базу
Сравните проект с заведомо чистой версией или резервной копией. Обратите внимание на недавно измененные исполняемые файлы, шаблоны, плагины, задания планировщика, записи с HTML или JavaScript в базе, неизвестные учетные записи и автозагрузку кода.
Не ограничивайтесь поиском адреса, на который ведет редирект. Вредоносный код может получать конечный домен из внешнего сервиса, хранить его в закодированном виде или менять адрес между визитами. Удаление видимого фрагмента без закрытия точки входа не предотвращает повторение.
Шаг 5. Сверьте DNS, CDN и доступы
Сравните A, AAAA и CNAME с ожидаемой инфраструктурой. Проверьте историю изменений у регистратора, DNS-провайдера, CDN и хостинга, список пользователей, активные токены и правила перенаправления.
Если один тип подключения попадает на правильный сервер, а другой — на старый или чужой, исследуйте IPv4 и IPv6 отдельно. Если DNS корректен, но CDN возвращает редирект, смотрите его правила, worker-скрипты, кеш и связь с origin-сервером.
Шаг 6. Проверьте внешние ресурсы
Временно отключайте подозрительные интеграции только контролируемо и по одной, фиксируя результат. Проверьте тег-менеджер, рекламу, аналитику, чат, виджеты, библиотеки и iframe. Загрузка скрипта с разрешенного домена не гарантирует, что его содержимое не менялось или учетная запись поставщика не была скомпрометирована.
Почему редирект видят не все
Злоумышленнику выгодно скрывать переход от владельца и проверяющих систем. Поэтому условие может учитывать первый визит, мобильный User-Agent, источник из поиска, отсутствие административной cookie, конкретный регион или промежуток времени.
Есть и безопасные объяснения: географическая посадочная страница, A/B-тест, старая DNS-запись у части провайдеров, различия IPv4 и IPv6, кеш CDN. Задача диагностики — записать условия и найти слой, который принимает решение.
Практический пример: забытое правило акции
После завершения рекламной кампании главная страница открывается нормально, но старый URL объявления перенаправляет на домен подрядчика. Цепочка стабильно воспроизводится, а в панели CDN находится временное правило. Исправление — удалить или заменить именно это правило, проверить все рекламные URL и сохранить прямой переход на актуальную страницу.
Практический пример: редирект только с телефона
Администратор с рабочего компьютера проблемы не видит, а новые мобильные посетители из поиска уходят на рекламу. В сетевом журнале первый документ отвечает 200, затем неизвестный скрипт выполняет переход. Нужно сохранить копию и логи, определить источник вставки, проверить шаблон, базу, тег-менеджер и доступы. Простая блокировка конечного домена в браузере не очищает сайт.
Как безопасно исправлять проблему
Порядок зависит от причины, но базовая последовательность такая:
- Сохраните файлы, базу, конфигурацию и журналы до очистки.
- При реальном риске ограничьте затронутую страницу или включите безопасную заглушку.
- Удалите ошибочное правило либо вредоносный код и механизм его восстановления.
- Обновите CMS, плагины, темы и серверные компоненты из доверенных источников.
- С чистого устройства смените скомпрометированные пароли, отзовите лишние сессии, токены и ключи.
- Проверьте права доступа, администраторов, DNS, CDN, задания и внешние интеграции.
- Очистите контролируемые кеши и повторите проверки при разных условиях.
- Сравните результат с эталонной версией и продолжайте наблюдение после восстановления.
Не заменяйте весь файл правил случайным примером из интернета и не восстанавливайте неизвестную по состоянию копию поверх production. Так можно потерять легальные маршруты, закрыть сайт или вернуть заражение.
Если редирект сопровождался предупреждением браузера или защитного сервиса, используйте также чек-лист для ситуации, когда сайт помечен как опасный или фишинговый. Снятие внешней метки запрашивают только после полной очистки и закрытия причины.
Что дает мониторинг и чего он не заменяет
Внешняя проверка помогает зафиксировать HTTP-код, доступность и изменение результата для выбранного URL. Регулярный контроль особенно полезен для главной, рекламных посадочных страниц, форм и старых адресов, на которых настроены переходы.
Web-Puls можно использовать для регулярной проверки доступности критичных страниц, чтобы быстрее заметить, что URL перестал отвечать ожидаемым образом. При этом одна успешная проверка не доказывает отсутствие скрытого редиректа: условие может зависеть от устройства, источника или cookie. Мониторинг дополняет, но не заменяет журналы, сравнение файлов, проверку CMS и расследование доступов.
Когда нужна профессиональная помощь
Обратитесь к специалисту, если переход ведет на опасный домен, сайт принимает платежи или персональные данные, редирект возвращается после очистки, неизвестна точка входа либо затронуты CMS, сервер, DNS и CDN одновременно.
Для технической диагностики можно оставить заявку через форму профессиональной поддержки или использовать контактную информацию. В первом сообщении достаточно указать домен, исходный и конечный URL, время, условия воспроизведения и уже выполненные проверки. Пароли отправлять не нужно.
Краткий чек-лист владельца
- Зафиксировать исходный URL, конечный домен, время и условия.
- Сохранить сетевую цепочку, логи, файлы, базу и конфигурацию.
- Проверить HTTP-редиректы, HTML, JavaScript и Service Worker.
- Сравнить мобильную и настольную версии, сети и источники перехода.
- Проверить сервер, CMS, CDN, DNS и внешние скрипты.
- Найти точку входа и механизм повторения, а не только удалить адрес.
- Обновить компоненты и доступы после сохранения доказательств.
- Повторить внешние проверки и настроить наблюдение.
Вывод
Если сайт перенаправляет на чужой домен, сначала сохраните маршрут и условия срабатывания, затем последовательно проверьте серверные правила, CMS, внешние скрипты, DNS и CDN. Стабильный переход после недавней настройки может оказаться ошибкой, а скрытый редирект на рекламу или поддельную форму требует полноценной проверки на компрометацию.
Безопасное исправление устраняет не только видимый переход, но и его источник. После восстановления проверяйте критичные URL извне и храните историю инцидента: это помогает быстрее заметить повторение и передать специалисту факты вместо догадок.