Что проверить на сайте после переезда на российский хостинг

Переезжают файлы, а ломается всё остальное

Перенос сайта — это обычно копирование файлов и базы данных. Всё, что вокруг, переезжает отдельно и вручную: записи DNS, сертификат, правила веб-сервера, доступ к панели, фаервол. Часть этого настраивает новый хостер по-своему, часть остаётся у старого, а часть не настраивает никто.

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

Ниже — семь мест, которые ломаются чаще всего, с симптомом и командой для проверки. Команды рассчитаны на терминал Linux или macOS; в Windows их выполнит WSL или Git Bash.

Сначала: не верьте своему браузеру

Главная ловушка первых суток — фраза «у меня всё открывается». Ваш компьютер почти наверняка врёт, и сразу по трём причинам.

Во-первых, DNS кешируется — операционной системой, роутером, провайдером. Вы можете ещё несколько часов ходить на старый сервер и не подозревать об этом. Во-вторых, браузер держит собственный кеш и, если сайт когда-то отдавал заголовок HSTS, будет принудительно ходить по HTTPS — даже если редирект на сервере отвалился, вы этого не увидите, а новый посетитель увидит. В-третьих, вы наверняка заходили в панель управления со своего адреса, и он может оказаться в списке разрешённых, пока для всех остальных она закрыта — или, что хуже, открыта.

Поэтому спрашивайте не свой компьютер, а посторонний резолвер:

dig +short A example.ru @8.8.8.8
dig +short A example.ru @77.88.8.8

Если два публичных резолвера отвечают разными адресами, распространение записей ещё не закончилось — и проверять остальное рано: половина результатов будет относиться к старому серверу.

Ещё одна забытая мелочь — поддомены. Записи A для mail, lk, api, old при переезде обычно никто не трогает: они продолжают указывать на выключенный или, наоборот, уже чужой сервер. Пройдитесь по списку поддоменов в панели DNS и уберите те, которые никуда не ведут.

1. Почта: адрес сайта переехал, почтовые записи — нет

Симптом: письма о регистрации и заказах перестали доходить или попадают в спам. Причём не у всех сразу — сначала у Gmail, потом у остальных.

Запись A при переезде меняют обязательно, иначе сайт не откроется. А вот MX, SPF и DKIM менять никто не заставляет — сайт и без них работает. В результате SPF продолжает разрешать отправку со старого IP, письма уходят с нового, проверка не сходится. Если при этом в DMARC стоит p=reject, письма не просто помечаются, а отбрасываются молча.

dig +short MX example.ru
dig +short TXT example.ru
dig +short TXT _dmarc.example.ru

В ответе должно быть: MX указывает на почтовый сервис, которым вы пользуетесь сейчас; в SPF перечислен новый отправитель; запись _dmarc существует и её политика строже, чем p=none.

Тише всего теряется DKIM. Подпись выпускается на конкретный почтовый сервис, и её открытая часть лежит в TXT-записи по адресу вида selector._domainkey.example.ru, где селектор у каждого сервиса свой. При смене отправителя старая запись остаётся, новую никто не добавляет — и письма уходят вообще без подписи. Ошибки при этом не показывает никто: почта просто медленно сползает в спам. Селектор смотрите в настройках почтового сервиса, а потом проверяйте так же, через dig +short TXT.

Отдельная ловушка — DNSSEC. Если у зоны он был включён, а при смене делегирования записи DS у регистратора не обновили, домен перестанет открываться у части провайдеров — и выглядеть это будет как «у меня всё работает, а у клиента нет».

2. Сертификат: выпущен не на то имя

Симптом: часть посетителей видит «Подключение не защищено», остальные ничего не замечают.

Новый хостинг почти всегда выпускает свой бесплатный сертификат — но иногда только на example.ru, без www, или наоборот. Домен, которого нет в сертификате, отдаёт ошибку. Старый сертификат при этом может быть ещё действующим, и пока не истечёт, проблему видно не всем.

echo | openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

Сверьте subjectAltName со списком имён, по которым сайт реально открывают, — вместе с www и поддоменами.

3. Редирект на HTTPS остался в старом конфиге

Симптом: сайт открывается и по http://, и по https://, отдавая одно и то же.

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

curl -sI http://example.ru | head -n 5
curl -sI http://www.example.ru | head -n 5

Ожидаемый ответ — 301 с Location: на https://. Заодно посмотрите, не выстроилась ли длинная цепочка: www → без www → HTTPS → снова www. Каждое звено — потерянное время загрузки и лишний шанс ошибиться.

4. Панель управления хостера открыта всему интернету

Самая частая находка после переезда и самая опасная: через панель управляется весь сервер, а её доступность с любого адреса — приглашение к перебору паролей.

У нового хостера панель включена по умолчанию и слушает свой порт:

• ISPmanager — порт 1500, иногда путь /ispmgr
• FastPanel — порт 8888
• cPanel — порты 2083 и 2082
• Plesk — порты 8443 и 8880

curl -skI --max-time 5 https://example.ru:1500/ | head -n 1
curl -skI --max-time 5 https://example.ru:8443/ | head -n 1

Важная оговорка: открытый порт сам по себе ничего не доказывает. За CDN и балансировщиком «отвечает» много чего. Мы считаем панель найденной, только если в теле ответа есть её собственные признаки — иначе получилась бы ложная тревога на каждом крупном сайте.

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

5. Наружу торчат порты баз данных

Актуально для переезда на VPS, где сервисы ставят руками. База, поднятая «пока для теста», нередко слушает внешний интерфейс, а Redis и MongoDB в конфигурации по умолчанию ещё и не спрашивают пароль.

Проверять стоит: 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 5601 Kibana, а также 21 FTP, 23 Telnet и 3389 RDP.

Правильный ответ на всё это — фаервол, разрешающий только нужное. Не «сменить порт» и не «поставить сложный пароль»: база данных не должна быть видна из интернета вообще.

6. Заголовки безопасности не переехали

HSTS, Content-Security-Policy, X-Frame-Options и флаги кук задаются в конфигурации веб-сервера. На старом хостинге их когда-то настроили, при переносе конфиг остался там же.

curl -sI https://example.ru

Смотрите, чего не появилось: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy. И наоборот — чего появилось лишнего: строка Server: nginx/1.18.0 с точной версией избавляет сканирующих ботов от необходимости угадывать, что у вас стоит.

7. robots.txt приехал с тестового стенда

Два противоположных, одинаково неприятных исхода. Либо в корне оказался Disallow: / со стенда — и сайт спокойно выпадает из поиска, что замечают через месяц по трафику. Либо в файле аккуратно перечислены закрытые разделы — готовая карта административных путей для того, кто их ищет.

curl -s https://example.ru/robots.txt

Robots.txt — не средство защиты: всё, что в нём перечислено, вы публикуете. Закрывать разделы нужно авторизацией, а не строчкой Disallow.

8. У нового IP-адреса своя история

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

Отдельно проверьте, не оказался ли новый адрес в реестре блокировок: тогда часть провайдеров просто не пустит посетителей, а из вашей сети всё будет открываться прекрасно.

Чек-лист

Чего такая проверка не покажет

Всё перечисленное — то, что сайт рассказывает о себе сам: заголовки, сертификат, записи DNS, ответы на публичных портах. Пассивная проверка этим и ограничена, и честнее сказать заранее, чего в ней нет.

Она не найдёт забытый каталог .git или дамп базы в корне — для этого нужен перебор путей, а это уже не наблюдение, а попытка что-то нащупать. Не найдёт уязвимости в коде и плагинах, не проверит права на файлы и настройки PHP: снаружи этого не видно. И не заменит нормальный пентест, где человек проверяет логику приложения руками.

Зато всё, что видно снаружи, видно и тем, кто ищет лёгкие цели, — а после переезда таких находок обычно больше всего.