Если у домена опубликовано несколько AAAA-записей, каждую нужно проверить отдельно. Обычный браузер или команда curl -6 https://example.com/ могут попасть на исправный адрес, поэтому один успешный ответ ещё не доказывает, что IPv6 работает для всех посетителей.
Надёжная приёмка выглядит так: получить полный набор AAAA, направить HTTPS-запрос на каждый адрес с сохранением имени домена, проверить сертификат, статус, редиректы и содержимое, а затем сравнить результат с IPv4. Проверку стоит повторить из внешней сети с рабочим IPv6, чтобы не спутать дефект сайта с ограничением своего подключения.
Почему браузер может скрыть неисправный IPv6
Современный клиент может выбирать между несколькими адресами и семействами IP, а после первого успешного соединения отменять остальные попытки. Такой подход уменьшает задержку для пользователя, но маскирует ситуацию, когда один IPv6-узел не отвечает, а IPv4 или другая AAAA-запись работает.
DNS-кэш и повторное использование соединения тоже мешают приёмке: несколько обновлений страницы могут снова идти на уже выбранный узел. Поэтому задача проверки — не просто открыть домен, а доказать работоспособность каждой опубликованной точки.
Подготовьте ожидаемый результат
До команд зафиксируйте, что именно считается нормой для проверяемого имени:
- Какой код должен вернуть исходный URL: успешный ответ или запланированный редирект.
- Какой адрес должен стать конечным после редиректов.
- Какое имя обязано быть в сертификате.
- Какой безопасный маркер подтверждает нужную версию страницы: заголовок, фрагмент текста или идентификатор сборки без секретов.
- Должны ли корневой домен,
www, API и статический поддомен вести на разные узлы.
Используйте публичный URL без токенов, персональных данных и параметров авторизации. Проверка обычного GET-запроса не подтверждает работу входа, заказа, оплаты или другого пользовательского сценария.
Шаг 1. Соберите все A и AAAA-записи
Начните с DNS-ответа, а не со списка серверов в панели хостинга:
dig AAAA example.com
dig A example.comОбычный вывод dig показывает сами адреса и TTL. Если менялась зона, сравните ответ авторитетного сервера с тем, что возвращают используемые рекурсивные резолверы. Так можно отделить ещё не обновившийся DNS-кэш от ошибки на конечном узле.
Составьте строку матрицы для каждой AAAA-записи. Если адрес есть в панели балансировщика, но отсутствует в публичном DNS, он не участвует в текущей проверке пользователей; если запись опубликована, она должна пройти приёмку независимо от ожидаемой доли трафика.
Шаг 2. Проверьте принудительный IPv6 без подмены имени
Не открывайте только https://[IPv6-адрес]/: при такой проверке меняется имя для TLS и виртуального хоста. Используйте --resolve, чтобы соединиться с выбранным адресом, но сохранить домен в URL, SNI и проверке сертификата.
Замените тестовый адрес из документационного диапазона на очередную AAAA-запись:
curl --resolve example.com:443:[2001:db8::10] \
--connect-timeout 5 --max-time 15 \
-sS -o /dev/null \
-w 'ip=%{remote_ip} http=%{http_code} ttfb=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/Curl по умолчанию проверяет цепочку сертификата и соответствие имени. Не добавляйте -k: успешный ответ с отключённой проверкой TLS создаст ложное ощущение готовности. Поле remote_ip должно совпасть с адресом текущей строки матрицы.
Если исходный URL должен перенаправлять посетителя, сначала посмотрите его заголовки, затем повторите запрос с -L и проверьте конечный URL. Не считайте любой код 200 успехом: страница-заглушка, ответ другого виртуального хоста или форма аварийного режима тоже могут вернуть его.
Шаг 3. Сравните HTTPS, редиректы и содержимое
Для каждого адреса заполните одинаковый набор полей:
| Проверка | Что зафиксировать | Критерий приёмки | | --- | --- | --- | | Соединение | выбранный IPv6 и время подключения | соединение установлено с нужным адресом | | TLS | имя, срок и цепочка сертификата | проверка проходит без отключения TLS | | HTTP | исходный код и цепочка редиректов | поведение совпадает с ожидаемой схемой | | Конечный URL | схема, домен и путь | нет перехода на служебный или чужой адрес | | Контент | стабильный безопасный маркер | загружена нужная версия, а не заглушка | | Сравнение с IPv4 | код, редирект, ключевые заголовки и маркер | различия объяснимы конфигурацией |
Если страница динамическая, не сравнивайте весь HTML побайтно. Выберите устойчивый признак, который действительно отличает рабочую страницу от ошибки: заголовок, ожидаемый текст или контролируемый служебный маркер.
Шаг 4. Разберите сбой по уровню
Не отвечает ни одна AAAA-запись
Сначала убедитесь, что тестовая машина имеет глобальный IPv6-маршрут. Затем повторите проверку из другой внешней IPv6-сети. Если результат совпал, проверяйте маршрут к площадке, сетевой экран, security group, балансировщик и прослушивание порта на IPv6.
Не работает только один адрес
Ищите отличие конкретного узла: неразвёрнутый виртуальный хост, закрытый порт, отсутствующий backend, старая конфигурация прокси или отдельное правило CDN. Удаление записи из DNS может остановить новые обращения, но не заменяет исправление причины и учёт TTL у резолверов.
TLS падает только по IPv6
Проверьте, что IPv6 приходит на тот же виртуальный хост, передаёт правильный SNI и использует актуальную цепочку сертификата. Исправный сертификат по IPv4 ничего не говорит о TLS-конфигурации другого балансировщика.
HTTP или контент отличается от IPv4
Сравните маршрутизацию прокси, заголовок Host, правила CDN, версию приложения и доступность backend. Если маленький ответ проходит, а более крупная страница зависает, отдельно исследуйте MTU пути и фильтрацию служебных сообщений IPv6.
Ошибки, из-за которых приёмка даёт ложный результат
- Проверить только домен с
curl -6, не закрепив отдельную AAAA-запись. - Использовать IP-литерал и принять ошибку сертификата за дефект самого сертификата.
- Отключить TLS-проверку параметром
-k. - Тестировать только из офисной сети без подтверждённого IPv6-маршрута.
- Ограничиться кодом ответа и не проверить конечный URL и содержимое.
- Опубликовать AAAA до настройки firewall, балансировщика и виртуального хоста.
- Проверить только корневой домен, забыв о
www, API или домене статических файлов.
Когда приёмку можно завершить
IPv6 готов, когда каждая публичная AAAA-запись проходит одну и ту же матрицу из внешней IPv6-сети, а отличия от IPv4 заранее объяснены. Сохраните результат с датой, сетью и адресом проверки: после ротации узлов или изменения DNS матрицу нужно выполнить заново.
Web-Puls помогает наблюдать доступность публичного сайта после запуска. Если приёмка выявила разные ответы IPv4 и IPv6 и нужен технический разбор DNS, CDN или сервера, отправьте заявку на диагностику, указав домен, время проверки и обезличенные результаты по каждой AAAA-записи.