Как проверить сайт перед переключением DNS

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

Самая полезная проверка — открыть сайт под настоящим доменным именем на новом IP, проверить сертификат, пройти основные пользовательские сценарии и убедиться, что копия не выполняет реальные внешние операции. Просмотра главной страницы по временному адресу недостаточно.

В примерах используется example.com и документальный IP 203.0.113.20. Подставьте свои значения. Если вы готовите весь переезд, начните с плана переноса сайта без потери данных: тестирование — только один из его этапов.

Почему обычное открытие IP не проверяет сайт

На одном сервере может работать несколько сайтов. Веб-сервер выбирает нужный по доменному имени в запросе, а при HTTPS имя также участвует в установлении защищённого соединения через SNI. Если открыть просто https://203.0.113.20, вы можете увидеть другую страницу или предупреждение о сертификате, которое не относится к реальной настройке домена.

Временный адрес провайдера тоже полезен не всегда. CMS может перенаправить его на основной домен, куки будут работать для другого имени, абсолютные ссылки приведут на старую площадку, а внешняя авторизация откажет из-за несовпадения callback URL.

Поэтому проверка должна сохранять доменное имя и менять только направление соединения. Для командной строки подходит curl --resolve, для браузера — локальная запись hosts. Эти способы действуют на вашей стороне и не переключают посетителей.

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

Подготовьте тестовую копию

Загрузите файлы, импортируйте базу и настройте окружение нового хостинга. Сверьте версии PHP, расширений и СУБД, пути к каталогам, параметры подключения и доменные настройки приложения. Для PHP-проекта полезно пройти проверку выбора версии PHP.

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

Загрузите базу с учётом конфиденциальности. Если тестирование выполняет внешняя команда, по возможности используйте обезличенный набор данных. Ограничьте доступ к копии и не оставляйте SQL-дамп в публичном каталоге.

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

Способ 1. Проверка через curl --resolve

Эта команда направляет соединение для указанной пары «домен:порт» на выбранный IP, сохраняя имя в URL, HTTP-запросе и TLS:

curl --resolve example.com:443:203.0.113.20 \
  -sS -o /dev/null -w 'HTTP: %{http_code}\nIP: %{remote_ip}\n' \
  https://example.com/

Ожидаемый результат — нужный HTTP-код и IP новой площадки. Успешное соединение само по себе ещё не подтверждает правильность содержимого. Для просмотра HTML уберите -o /dev/null или сохраните ответ в локальный файл:

curl --resolve example.com:443:203.0.113.20 \
  -sS https://example.com/ -o checked-page.html

Параметр описан в официальном руководстве curl. Он действует для конкретного вызова и не меняет DNS компьютера.

Не используйте -k как способ «успешно пройти» проверку HTTPS. Этот флаг отключает верификацию сертификата. Он может помочь при узкой диагностике, но положительный результат с ним не означает, что сайт откроется у посетителей без предупреждения.

Как проверить редиректы

Сначала посмотрите начальный ответ без перехода по редиректам:

curl --resolve example.com:80:203.0.113.20 \
  -sS -D - -o /dev/null http://example.com/

Убедитесь, что Location ведёт на правильное имя и путь. Затем проверьте HTTPS и внутренние страницы. Для полного пути через несколько имён добавьте отдельный --resolve для каждого из них:

curl --resolve example.com:80:203.0.113.20 \
  --resolve example.com:443:203.0.113.20 \
  --resolve www.example.com:443:203.0.113.20 \
  -sS -L -o /dev/null \
  -w 'HTTP: %{http_code}\nURL: %{url_effective}\nIP: %{remote_ip}\n' \
  http://example.com/

Если редирект уводит на имя, для которого нет локального переопределения, следующий запрос может попасть на старый сервер. Поэтому смотрите конечный URL и IP, а не только код 200.

Способ 2. Локальный файл hosts для браузера

Файл hosts позволяет сопоставить домен с IP на конкретном компьютере. После временной записи браузер сможет открыть новый хостинг под привычным адресом.

На Windows файл обычно расположен здесь:

C:\Windows\System32\drivers\etc\hosts

На Linux и macOS:

/etc/hosts

Откройте файл с необходимыми административными правами, сохраните копию исходного содержимого и добавьте строку:

203.0.113.20 example.com www.example.com

В ней не нужны https://, пути страниц и порты. Запись относится к именам, а не к отдельным URL. Если сайт использует static.example.com, добавьте его отдельно с корректным адресом соответствующего сервера.

Полностью перезапустите браузер после изменения. Если результат не меняется, проверьте локальное разрешение имени, кеш, VPN, прокси и настройки защищённого DNS. Их поведение может влиять на маршрут. Надёжнее подтвердить адрес фактического соединения в DevTools или отдельным curl --resolve, чем предполагать, что hosts точно применился.

После завершения обязательно удалите временные строки и снова проверьте обычное открытие сайта. Иначе спустя несколько недель вы можете продолжать видеть старый тестовый сервер и принимать решения по неверной копии.

Как убедиться, что проверяется новая площадка

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

Можно создать безопасный текстовый маркер с нейтральным содержимым и случайным именем в каталоге сайта, проверить его через домен и затем удалить. Не используйте для маркера секреты, номер аккаунта или конфигурацию сервера. Не оставляйте диагностические файлы после работы.

В приложении с динамическими страницами убедитесь, что оно подключено к новой базе. Добавьте безвредную тестовую запись в тестовом окружении и проверьте её через панель этой базы. Не проводите такую проверку реальной оплатой или письмом клиенту.

Копия главной страницы из CDN-кеша может скрыть ошибку origin. Поэтому проверьте и некешируемый разрешённый сценарий, а также журналы нового приложения. Не добавляйте произвольный секретный query-параметр: он может попасть в логи и системы аналитики.

Проверка HTTPS до переключения

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

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

Проверьте основной домен, www и используемые поддомены. Если посетители заходят по www, сертификат нужен для этого имени даже тогда, когда сервер сразу перенаправляет на адрес без www: TLS устанавливается раньше HTTP-редиректа.

После успешной проверки сертификата откройте Console и Network. Заблокированные HTTP-ресурсы требуют отдельного исправления: это смешанный контент, а не недостаток самого сертификата.

Что проверить на страницах

Начните с набора типовых URL, а не с полного случайного просмотра. Выберите главную, рубрику, обычную статью, страницу с таблицей или галереей, поиск, форму, файл для скачивания и заведомо отсутствующий адрес.

Проверка	Признак исправной работы
Главная и внутренние страницы	Правильный контент, HTTP 200, рабочие стили
Несуществующий URL	Настоящий 404, а не случайная успешная страница
Редиректы	Правильный конечный домен, нет циклов
Картинки и документы	Открываются без 403 и 404
Поиск и фильтры	Дают ожидаемый результат и сохраняют параметры
Формы	Валидируют данные и показывают понятный результат
Вход и выход	Сессия создаётся и завершается корректно
Загрузка файлов	Файл сохраняется и доступен в разрешённом месте

Проверяйте вложенные адреса. Главная может работать, а /catalog/item/ — возвращать 404 из-за отсутствующих правил маршрутизации. Это особенно часто проявляется при переходе между Apache и Nginx или изменении корневой папки.

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

Проверка форм, почты и магазина

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

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

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

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

Фоновые задания и время

Сверьте расписание cron и часовой пояс. Одинаковая запись расписания на серверах с разным часовым поясом может запускаться в другой момент. Проверьте путь к PHP, рабочий каталог, переменные окружения и права на запись.

Не включайте повторно реальные задачи до финального переключения, если они ещё работают на старой стороне. Два обработчика одной очереди могут создавать дубли писем, импортов или заказов. Для проверки используйте ограниченный тестовый набор и отдельные учётные данные.

Сравните время сервера и приложения. Ошибочные часы мешают сессиям, проверке подписей и установлению TLS. Если время неверно на виртуальном хостинге, это вопрос к провайдеру; на VPS проверьте синхронизацию времени.

Индексация и защита тестовой копии

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

Если тестируете под тем же доменом через hosts, публичный сайт продолжает работать как раньше. Но новый сервер всё равно может быть доступен извне по IP или служебному имени. Проверьте виртуальный хост по умолчанию и правила доступа к тестовым адресам.

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

Сверьте canonical и sitemap: там не должно быть временного домена. Также проверьте абсолютные ссылки в меню, изображениях, JSON-LD и настройках CMS. Тестовая копия иногда выглядит правильно именно потому, что тянет значительную часть ресурсов со старого сайта.

Производительность без опасного нагрузочного теста

Измерьте несколько типовых страниц в одинаковых условиях. Разделяйте первый запрос после очистки кеша и повторные обращения. Сравнивайте одинаковый контент, один маршрут и одинаковый режим авторизации.

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

Если новая площадка явно медленнее, выясните этап задержки: соединение, TLS, ожидание HTML, загрузка медиа или выполнение JavaScript. Порядок диагностики разобран в статье как найти причину медленной загрузки сайта.

Как оформить приёмку

Сделайте таблицу со столбцами «сценарий», «ожидаемый результат», «фактический результат», «дата», «ответственный». Это особенно полезно, если перенос проверяют разработчик, редактор и владелец магазина: каждый смотрит свою часть проекта.

Исправление нужно подтверждать повторным прохождением того же сценария. Фраза «изменили настройку» не равна результату «форма сохранила запись, письмо доставлено, журнал не содержит новой ошибки».

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

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

Пример карты проверки для редакционного сайта

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

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

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

Проверьте также длинный заголовок и текст с кириллицей. Это помогает обнаружить проблемы кодировки и ограничения полей до появления настоящей публикации. Не вводите в тестовые формы реальные пароли других сервисов или личные данные клиентов.

Если есть видео, начните просмотр и перемотайте ближе к концу. Убедитесь, что браузер получает подходящий ответ и не обязан предварительно скачивать весь большой файл. Посмотрите, что происходит при паузе и повторном запуске. Доступность одного постера не подтверждает работу видео.

Как отличить дефект переноса от старой ошибки

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

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

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

Для каждого дефекта сохраните минимальный сценарий воспроизведения. Важно не «картинки иногда пропадают», а «в публикации X второй вариант srcset возвращает 404 на мобильной ширине». Такое описание превращается в проверяемую задачу.

Отдельная проверка доступа и файлов

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

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

Проверьте временные диагностические файлы. Страницы с информацией PHP, тестовые маркеры и случайные архивы должны исчезнуть после приёмки. Не оставляйте доступный редактор базы «на всякий случай».

Передача результата владельцу проекта

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

В отчёте разделите «проверено», «не используется» и «ещё не проверено». Не отмечайте сценарий успешным только потому, что функция не понадобилась в тесте. Например, если webhook нельзя было проверить через локальный hosts, укажите отдельный способ его финальной проверки после переключения.

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

Частые вопросы

Можно ли просто открыть временный адрес хостинга?

Для первичного осмотра — да. Для полной проверки доменных редиректов, куки и HTTPS нужен настоящий домен, направленный на новую площадку локально или в отдельном тестовом окружении.

Почему curl работает, а браузер показывает старый сайт?

Проверьте hosts, кеш браузера, прокси, VPN, защищённый DNS и service worker. curl --resolve переопределяет адрес только для самого curl. Он не меняет настройки браузера.

Почему новый сайт не принимает уведомления об оплате?

Локальная запись hosts не действует на сервер платёжной системы. Её запросы идут по публичному DNS. Проверьте тестовый сценарий у интеграции и используйте песочницу, если она доступна.

Можно ли проверить сайт без сертификата?

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

Когда удалять запись из hosts?

Сразу после проверки и обязательно перед оценкой результата публичного переключения. После удаления подтвердите адрес соединения обычным способом, чтобы не смотреть на принудительно выбранную копию.

Что проверить после удаления локальных настроек

Когда тестирование закончено, удалите записи hosts и закройте временные окна браузера. Затем откройте сайт обычным способом и подтвердите, что запросы снова следуют публичному DNS. Это отдельная проверка, особенно если вы используете VPN или прокси.

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

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

Назначьте один канал фиксации результатов. Разрозненные сообщения «у меня открывается» не заменяют таблицу, в которой видно, какие операции пройдены и какие ещё требуют проверки. Если работой занимается один человек, короткий журнал всё равно помогает не забыть редкий сценарий.

Итоговый список перед сменой DNS

• Подтверждено, что запросы попадают на новый сервер.

• Сертификат проверяется без отключения верификации.

• Работают внутренние страницы, формы и загрузки.

• Тестовые операции не затрагивают клиентов и деньги.

• Внешние интеграции проверены с учётом ограничений локального DNS.

• Cron и очереди не создают дубли на двух площадках.

• Сохранены нужные правила доступа и индексации.

• Есть свежая копия, финальная синхронизация и план возврата.

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

Команды в Windows

Многострочные команды с обратной косой чертой в этой статье рассчитаны на Bash в Linux и macOS. В PowerShell используйте curl.exe; простой пример в одну строку:

curl.exe --resolve example.com:443:203.0.113.20 -I https://example.com/

example.com — пример домена, 203.0.113.20 — пример нового IP. Подставьте свои значения. Проверка HTTPS сохраняет проверку сертификата.

После переключения DNS повторите проверку сайта по публичному адресу, уже без локального переопределения имени.