Сайт работает по IPv4, но не по IPv6: как найти разрыв

Если сайт работает по IPv4, но не открывается по IPv6, проверьте второй путь отдельно: адрес в AAAA, возможность соединения, HTTPS и ответ приложения. Наличие DNS-записи не подтверждает работу службы. Не просите всех посетителей отключить IPv6: сначала установите, на каком участке перестаёт работать ваш собственный вход.

За одним именем могут стоять разные назначения

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

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

Начните с AAAA, но не заканчивайте ею

RFC 3596 определяет AAAA как запись, содержащую IPv6-адрес. Это описание назначения имени, а не проверка веб-приложения на этом адресе. Если запись указывает на неподготовленный или прежний узел, её наличие лишь направит исследование к этому узлу.

Сопоставьте каждый возвращённый адрес с планом размещения. Не заменяйте IPv6-адрес произвольным преобразованием из IPv4: требуется действительное назначение вашей инфраструктуры. Если владелец не знает, должен ли сайт обслуживаться по IPv6, это сначала вопрос к хостеру или администратору.

Матрица двух путей к сайту

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

Проверьте возможность именно такого соединения

Для раздельного наблюдения можно использовать средство, которое позволяет выбрать семейство адресов. В руководстве curl для этого описаны ipv4 и ipv6. Но сам диагностический компьютер должен иметь подходящий сетевой путь; его локальная невозможность IPv6-соединения не доказывает отказ сайта.

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

Сначала исследуйте свой или согласованный ресурс. Сканировать чужие сети для этого не требуется. В обращении через поддержку сервера нужны конкретный вход, время и стадия отказа; просьба «включить IPv6 везде» не объясняет текущую схему.

Готов ли сервер принять второй путь

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

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

Появился ответ — исследуйте HTTPS и проект

Если соединение установлено, сопоставьте сертификат для нужного имени и полученный HTTP-ответ. При проверке IP нельзя терять доменное имя, с которым работает обычный посетитель. Иначе можно увидеть другую точку обслуживания и ошибочно объявить основной сайт неисправным.

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

Приёмка исправления по границам

1. Определите, должен ли проверяемый публичный вход работать в обоих семействах.
2. Сохраните DNS-назначения и результаты раздельных наблюдений с условиями подключения.
3. Найдите первую различающуюся границу: адрес, соединение, TLS или приложение.
4. Исправьте подтверждённое расхождение в ответственной системе, сохранив согласованный способ возврата.
5. Повторите обе проверки и отдельно проверьте основные ресурсы контрольной страницы.

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

Как передать результат следующему администратору

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

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