В IPv6-only сети приложение не соединяется с API по доменному имени. Как локализовать, нарушает ли клиент поддержку IPv6?
Проверяйте приложение в сети без IPv4 через доменное имя API и разделяйте два участка: установление соединения клиентом и доступность самого сервера через механизм DNS64/NAT64. Если доменное имя преобразуется в IPv6-адрес, а приложение всё равно пытается использовать IPv4-литерал или IPv4-зависимую библиотеку, проблема находится на стороне клиента. Если же IPv6-адрес не разрешается или сервер недоступен через IPv6/NAT64, причина находится в сетевой инфраструктуре или серверной конфигурации.
IPv6 появился из-за ограниченного адресного пространства IPv4 и необходимости поддерживать дальнейший рост числа подключённых устройств. Мобильные операторы постепенно внедряют сети, где устройство получает только IPv6, но должно обращаться к ресурсам, работающим в IPv4-инфраструктуре.
Для перехода используются, в частности, DNS64 и NAT64. DNS64 синтезирует IPv6-ответ для IPv4-only хоста, а NAT64 преобразует последующий трафик в IPv4. Поэтому приложение должно работать не только в привычной dual-stack-сети, где доступны оба протокола.
Ошибка в IPv6-only сети может выглядеть как обычный сетевой сбой: тайм-аут, невозможность входа или загрузки данных. Однако её причиной бывает не сервер, а клиентский код, который использует IPv4-литерал, получает только IPv4-адрес из собственного DNS-механизма или зависит от библиотеки, некорректно работающей без IPv4.
Неверный вывод опасен в обе стороны. Если обвинить сервер при проблеме клиента, исправление не попадёт в приложение; если обвинить приложение при отсутствии IPv6-доступности у API, команда потратит время на изменение исправного клиента.
Сначала воспроизведите проблему в контролируемой IPv6-only сети, а не просто на устройстве с включённым IPv6. Используйте API по доменному имени, потому что обращение к IPv4-адресу напрямую заведомо не проверяет работу через DNS64/NAT64.
Затем проверьте следующие границы:
Для локализации полезно сравнить запрос приложения с запросом системного браузера или диагностического клиента в той же сети. Если браузер открывает тот же домен, а приложение нет, вероятнее проблема в сетевом стеке приложения, его библиотеке или настройках. Если не работает всё, нужно проверять DNS64/NAT64, маршрутизацию, балансировщик, TLS и доступность API.
Проверка должна включать не только стартовый запрос. Отдельно проверяются авторизация, загрузка файлов, WebSocket или потоковые соединения, фоновые запросы и переходы между Wi-Fi и мобильной сетью, если они используются продуктом. Поддержка IPv6 не означает, что каждый вспомогательный сервис приложения автоматически доступен через IPv6.
Компромисс состоит в выборе уровня диагностики. Перехват трафика и журналы дают точную локализацию, но требуют настроенной тестовой сети; проверка только пользовательского результата быстрее, но не позволяет надёжно отличить проблему DNS, транспорта, TLS и HTTP.
Мобильное приложение успешно работало в офисной сети, но в IPv6-only тестовой сети не открывало экран авторизации. Рассматривались три варианта: признать недоступным API, переключить тестовую сеть на dual-stack или исследовать клиентский сетевой путь.
Первый вариант был быстрым, но не объяснял причину. Второй скрывал бы дефект и не проверял требуемый сценарий. Выбрали третий вариант: подтвердили, что доменное имя разрешается через DNS64, а браузер устанавливает соединение с API; затем в сетевых журналах приложения обнаружили обращение к отдельному сервису по IPv4-литералу.
После замены этого адреса на доменное имя и проверки всех вспомогательных endpoint приложение заработало. Итоговый тест оставили в матрице совместимости, потому что основной API был исправен, а дефект находился в редко используемом клиентском маршруте.
Нет. Dual-stack-сеть может скрыть дефект: клиент всегда выберет рабочий IPv4-маршрут, и IPv6-совместимость фактически не будет проверена. Нужен сценарий, в котором у устройства отсутствует IPv4-маршрут, а доступ к IPv4-only ресурсам обеспечивается контролируемым DNS64/NAT64.
DNS64 работает с именами, для которых можно получить IPv4-адрес и синтезировать IPv6-представление. Прямой IPv4-литерал не проходит через обычный механизм разрешения имени, поэтому приложение не сможет использовать его в IPv6-only сети. Такой тест выявляет сам факт IPv4-зависимости, но не проверяет корректность DNS64/NAT64 для доменного имени.
Нет. После транспорта остаются TLS и прикладной протокол. Проблема может проявиться в сертификатах, маршрутизации балансировщика, ограничениях firewall, WebSocket или отдельном домене для загрузки файлов. Поэтому успешное разрешение имени и установка TCP-соединения — промежуточные доказательства, а не подтверждение полной совместимости приложения.