После изменения DNS одни посетители могут попадать на прежний адрес, а другие — на новый. Ошибка сертификата, отказ соединения и неправильный редирект имеют разные причины. Запишите точный адрес, время, сообщение браузера и сеть, в которой воспроизводится проблема.
Отделите DNS от HTTPS и приложения
- Если домен не разрешается, проверьте DNS-ответ. NXDOMAIN означает, что резолвер сообщает об отсутствии имени; SERVFAIL может быть связан с DNSSEC, делегацией или ошибкой DNS-сервиса.
- Если соединение устанавливается, но браузер сообщает об ошибке сертификата, проверьте имя в сертификате, срок действия и цепочку доверия.
- Если получен 5xx, проверьте исходный сервер и журнал прокси. Код не объясняет причину сам по себе: возможны таймаут, недоступность origin или ошибка приложения.
- При бесконечных перенаправлениях сравните настройки HTTPS и основного домена в приложении, исходном сервере и прокси.
Сверьте основной домен, www и IPv6
В проверке DNS-записей сравните A, AAAA и CNAME для нужных имён с согласованной схемой подключения. Если A ведёт на защитный узел, а AAAA — на прежний origin, посетители IPv6 могут идти другим маршрутом. Не удаляйте AAAA автоматически: сначала уточните поддержку IPv6 и план возврата.
Проверьте authoritative nameservers и ответы нескольких резолверов. Различия возможны из-за кеша и TTL. TTL — время кеширования записи, а не обещание, что все посетители переключатся одновременно. Локальный кеш браузера или ОС тоже может сохранять старый ответ.
Не меняйте MX и почтовые TXT-записи при переключении веб-трафика. Если включён DNSSEC, проверьте согласованность DS у регистратора и DNSKEY у провайдера. Публичная DNS-диагностика помогает сравнить сигналы, но не заменяет полноценную проверку цепочки доверия.
Проверьте сертификат на каждом HTTPS-участке
У браузера и прокси могут быть разные TLS-соединения: посетитель → защитный узел и защитный узел → origin. Убедитесь, что оба обслуживают правильное имя и доверенную цепочку. Проверка SSL показывает доступный публичный сертификат; сертификат скрытого origin нужно проверять отдельно средствами администратора.
Успешное открытие https://example.com не подтверждает работу https://www.example.com. Для HTTPS-редиректа сертификат должен быть корректным ещё до перенаправления. Не отключайте проверку TLS ради устранения ошибки: исправьте имя, срок, цепочку или конфигурацию сервера.
Разберите редиректы и доступность origin
В проверке цепочки редиректов сравните http/https и www/без www. Если приложение не распознаёт HTTPS после прокси, настройте доверенные заголовки по его документации; нельзя доверять таким заголовкам от любого отправителя.
При таймауте проверьте доступность origin с разрешённых узлов, порт, firewall и имя хоста. Не открывайте сервер всему интернету без необходимости. Сохраните журнал ошибки и идентификатор запроса для поддержки; пароли, ключи и cookie отправлять не нужно.
Когда возвращать прежнюю схему
Если недоступны важные сценарии и причина не устраняется в согласованное окно, восстановите сохранённые записи по плану подключения. Возврат DNS тоже зависит от кешей: повторите проверки из нескольких сетей. Зафиксируйте причину и подготовьте повторное переключение после её устранения.
- Проверьте главную, формы, вход и мобильную версию.
- Для магазина проверьте корзину, тестовую оплату и серверные уведомления.
- Проверьте robots.txt, sitemap и важные страницы в поисковых кабинетах.
- Сравните ответы для www и основного домена, HTTP и HTTPS.
Подготовка и порядок изменения записей описаны в руководстве по DNS и инструкциях платформ. Диагностика помогает восстановить доступность; сама по себе она не подтверждает защиту от ботов.