Проверяем новый сервер до переключения DNS: curl --resolve с настоящим именем

Новый сервер уже настроен, но DNS пока направляет пользователей на прежний адрес. Проверить HTTPS по IP неудобно: сертификат выпущен на доменное имя, а виртуальный хост выбирается тоже по имени. curl позволяет временно задать соответствие имени адресу для одной команды и пройти тот же именованный вход.

Сохраните имя в URL

curl --resolve shop.example:443:192.0.2.40 --connect-timeout 5 --max-time 15 -v https://shop.example/health

Замените имя и адрес параметрами стенда. resolve добавляет локальное соответствие для пары имя-порт внутри операции curl. URL остаётся shop.example, поэтому HTTP Host и TLS server name относятся к нему. Сертификат тоже проверяется на это имя. Обычная системная DNS-запись при этом не меняется.

Команда с URL по IP и отдельным заголовком Host не равнозначна: заголовок появляется внутри HTTP после TLS. Проблема выбора сертификата и его проверки возникает раньше. Именно сохранение имени в URL позволяет проверить реальную цепочку виртуального хоста без отключения проверки доверия.

Убедитесь, что попали на новый узел

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

Если окружение использует HTTPS-прокси, он может сам разрешать имя назначения. Для прямой проверки нужен разрешённый прямой путь. Можно добавить noproxy с точным именем только если политика сети допускает обход прокси. Иначе попросите сетевую команду организовать согласованный путь до нового адреса и зафиксируйте, какой участок тестируется.

Проверьте больше одного зелёного эндпоинта

Откройте ключевые безопасные для проверки пути: страницу, статический ресурс, авторизованный read-only API. Убедитесь, что сертификат содержит правильное имя, цепочка доверия проходит, а перенаправления остаются в ожидаемых границах. Первый ответ 301 может вести на другое имя, для которого понадобится отдельное соответствие resolve.

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

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

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

Подготовьте миграцию как последовательность проверок. В курсе Linux и Bash для DevOps-инженеров есть диагностика DNS, HTTP и доступности сервиса. Откройте программу, чтобы отработать на учебном сервере связь между именем, сетевым адресом и ответом приложения.

Ещё по теме

• Новую DNS-запись добавили, а NXDOMAIN остался: разбираем отрицательный кэш
• Что лежит в архиве релиза: проверяем tar до извлечения