Почему Apple требует поддержки IPv6 и как это связано с мобильными сетями?

Apple требует, чтобы приложения, отправляемые в App Store, поддерживали сети только с IPv6. Мобильный оператор может отдавать предпочтение IPv6 и использовать трансляцию DNS64/NAT64, тогда как офисная Wi-Fi-сеть может работать только через IPv4, поэтому проблема с IPv6 может не проявиться при тестировании в офисе.

Почему не рекомендуется проверять доступность сети (reachability) перед каждым запросом?

Apple отказалась от рекомендации использовать предварительную проверку доступности сети как обязательное условие перед отправкой запроса, поскольку между проверкой и выполнением запроса состояние сети может измениться. Более надёжный подход — запустить запрос и обработать фактический результат.

Почему iOS-приложение работает через Wi-Fi, но не через мобильную сеть: практическое руководство по тестированию

Q: Почему нельзя просто использовать исключение NSAllowsArbitraryLoads для решения проблем с TLS?

Глобальное исключение NSAllowsArbitraryLoads ослабляет транспортную безопасность всего приложения и скрывает реальный дефект. Если временное исключение неизбежно, статья рекомендует делать его точечным и документировать.

Q: Как параметр waitsForConnectivity помогает при работе в мобильной сети?

Параметр waitsForConnectivity позволяет сессии URLSession дождаться подходящего сетевого пути, а не немедленно завершиться ошибкой. Это особенно полезно в условиях нестабильного мобильного соединения.

Тестирование iOS-приложения в сетях Wi-Fi и мобильной связи

iOS-приложение успешно проходит все тесты в офисе. Авторизация работает, изображения загружаются, покупки проходят. Но затем тестировщик отключает Wi-Fi — и приложение начинает работать медленно, показывает пустой экран или сообщает об отсутствии подключения к интернету.

Это не какой-то исключительный случай. Wi-Fi и мобильный интернет могут использовать разные маршруты к одному и тому же серверу. У них могут отличаться DNS-резолверы, семейства IP-адресов, узлы CDN, правила фильтрации и задержки. Запрос, который успешно выполняется через офисную сеть, может выявить скрытые предположения в работе приложения, как только трафик пойдёт через сеть мобильного оператора.

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

Партнёрский материал: это техническое руководство подготовлено совместно с GateProxies. Сервис упоминается в контексте региональных маршрутов для тестирования веб-сервисов, API и CDN. Прокси не воспроизводят радиосеть и все особенности подключения через мобильного оператора.

Почему результаты в Wi-Fi и мобильной сети могут различаться

С точки зрения приложения оба подключения обеспечивают доступ в интернет. Но на сетевом уровне они могут сильно различаться.

Офисная сеть Wi-Fi может разрешать домен API в IPv4 и обращаться к ближайшему узлу CDN через стабильное широкополосное соединение. Мобильный оператор может отдавать предпочтение IPv6, использовать трансляцию DNS64/NAT64, выбирать другой периферийный узел CDN или направлять трафик через Carrier-Grade NAT (CGNAT). В мобильной сети также могут быть выше задержки и чаще происходить переключения при перемещении пользователя между базовыми станциями.

Поэтому утверждение «работает через Wi-Fi» доказывает лишь то, что работает один конкретный сетевой маршрут. Оно не гарантирует, что клиент и сервер будут одинаково функционировать во всех сетях реальных пользователей.

Сравнение прохождения запросов через Wi-Fi и мобильную сеть

Сначала определите точный характер сбоя

Фраза «мобильный интернет не работает» слишком общая для диагностики. Перед изменением кода зафиксируйте конкретные признаки проблемы:

модель iPhone и версию iOS;
мобильного оператора и страну;
отображается ли на устройстве 4G, LTE или 5G;
точный экран и действие, на котором возникает ошибка;
время сбоя с указанием часового пояса;
открывает ли Safari обычный HTTPS-сайт;
возникает ли ошибка сразу или спустя некоторое время;
не работают все запросы или только конкретный хост либо функция;
восстанавливается ли выполнение того же действия после возвращения к Wi-Fi.

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

Проверьте настройки устройства и приложения

Откройте Настройки → Сотовая связь и убедитесь, что приложению разрешено использовать мобильные данные. Временно отключите VPN, приложения с DNS-фильтрацией, средства безопасности и инструменты анализа трафика: они могут самостоятельно менять сетевой маршрут.

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

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

Также проверьте, как интерфейс определяет отсутствие интернета. Apple отказалась от рекомендации использовать предварительную проверку доступности сети (reachability) как обязательное условие перед отправкой запроса: между проверкой и выполнением запроса состояние сети может измениться. Более надёжный подход — запустить запрос и обработать фактический результат. При необходимости параметр waitsForConnectivity позволяет сессии дождаться подходящего сетевого пути, а не немедленно завершиться ошибкой.

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

Проверяйте не только стабильные состояния сети, но и переходы между ними. Запустите запрос через Wi-Fi, отключите его и проследите, как соединение переходит на мобильные данные. Повторите проверку в обратном направлении. Фоновые загрузки, скачивание медиафайлов и длительные соединения требуют отдельных сценариев тестирования переходов.

Проверьте IPv6 и DNS64/NAT64

IPv6 — одно из наиболее важных различий между офисными и операторскими сетями. Apple требует, чтобы приложения, отправляемые в App Store, поддерживали сети только с IPv6. Приложения, которые используют высокоуровневые сетевые API Apple и подключаются по доменным именам, обычно получают такую поддержку автоматически. Но жёстко прописанные IPv4-адреса и код сокетов, рассчитанный на конкретное семейство адресов, по-прежнему могут приводить к сбоям.

Обратите внимание на следующие признаки:

базовый URL API содержит IPv4-адрес вместо доменного имени;
код предполагает, что любой IP-адрес состоит из четырёх десятичных групп;
списки разрешённых адресов принимают только IPv4-источники;
SDK помещает буквальный IP-адрес в URL или сообщение протокола;
сервер имеет AAAA-запись, но некорректно обслуживает IPv6;
IPv6-адреса вручную формируются на основе IPv4.

Apple рекомендует тестировать приложение в сети только с IPv6, использующей DNS64/NAT64. Локальная проверка по Wi-Fi, которая незаметно задействует IPv4, может вообще не затронуть маршрут, с которым столкнётся пользователь мобильного интернета. Используйте доменные имена, позволяйте системному резолверу выбирать адрес и проверяйте поведение как клиента, так и сервера.

Сравните DNS-записи A и AAAA для каждого домена, связанного с проблемной функцией: API, авторизации, медиа, конфигурации и платежей. Проверьте устаревшие записи, неудачные миграции и цепочки CNAME, которые могут по-разному обрабатываться различными резолверами.

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

Проверьте TLS и App Transport Security

App Transport Security (ATS) защищает соединения, устанавливаемые через URL Loading System от Apple. URLSession ожидает HTTPS, действительные сертификаты и современные версии TLS. Серверная часть может нормально работать в одном браузере, но давать сбой, если региональный узел выдаёт неполную цепочку сертификатов, просроченный сертификат, сертификат с несовпадающим именем хоста или использует устаревшую конфигурацию TLS.

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

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

Отличайте высокую задержку от отсутствия подключения

Мобильные сети не всегда медленнее Wi-Fi, но их поведение может быть менее предсказуемым. Условия радиосвязи, перегрузка сети и маршрутизация способны увеличить задержку или потери пакетов. Тайм-аут, выбранный при тестировании в быстрой офисной сети, может оказаться слишком коротким для реального мобильного подключения.

Добавьте инструментирование запросов, чтобы команда могла ответить на вопросы:

Завершилось ли разрешение DNS?
Было ли установлено соединение?
Успешно ли завершилось согласование TLS?
Когда пришёл первый байт ответа?
Сколько времени заняла передача данных?
Повторялся ли запрос и по какой причине?

Никогда не записывайте в журналы пароли, заголовки авторизации, cookies, токены доступа и конфиденциальные тела запросов. Диагностика должна объяснять, на каком сетевом этапе возникла проблема, а не создавать новый инцидент безопасности.

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

Проверьте региональное поведение CDN и API

Если проблема затрагивает пользователей одной страны или одного мобильного оператора, само приложение может быть исправным, а сбой — находиться на пути доставки данных.

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

Здесь помогают контролируемые региональные проверки. Команда может отправить одинаковый веб- или API-запрос через выходные узлы в разных странах и сравнить коды ответа, задержку, заголовки и содержимое ответов. GateProxies предлагает резидентские, мобильные и ISP-прокси, которые можно использовать для сравнения маршрутов. На момент написания исходного материала стоимость резидентского трафика начинается от $1,31 за ГБ, мобильного — от $3 за ГБ, а ISP-адресов — от $4,50 за IP.

Выбирайте тип прокси в соответствии с задачей. Резидентские маршруты помогают проверять поведение веб-сайтов и API в зависимости от местоположения. Стабильный ISP-маршрут подходит для повторяющихся тестов с одного адреса. Мобильные выходные узлы предоставляют дополнительную внешнюю точку наблюдения с подключением операторского происхождения.

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

Практический порядок диагностики

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

Практическая схема диагностики сетевых сбоев iOS

Воспроизведите проблему на физическом iPhone. Используйте ту же релизную или TestFlight-сборку и отключите Wi-Fi.
Проверьте разрешения и профили. Убедитесь в доступе к мобильной сети; проверьте VPN, фильтрацию, режим экономии данных (Low Data Mode) и ограничения управляемого устройства.
Определите проблемный запрос. Установите, затрагивает ли ошибка авторизацию, API, медиа, оплату или сторонний SDK.
Определите этап сбоя. Разделите ошибки DNS, установления соединения, TLS, ответа сервера и обработки данных на клиенте.
Проверьте работу в сети только с IPv6. Используйте настройку DNS64/NAT64, рекомендованную Apple, и устраните предположения о наличии IPv4.
Сравните внешние маршруты. Проверьте регионы, где проблема наблюдается, и те, где всё работает, если местоположение может иметь значение.
Изучите данные сервера. Если запрос до сервера не доходит, исследуйте DNS, маршрутизацию, TLS или фильтрацию на периферии сети. Если доходит — проанализируйте статус ответа и задержку.
Исправьте наиболее узкую подтверждённую причину. Избегайте широких исключений безопасности и бессистемного повторения запросов.
Повторите полный пользовательский сценарий. Проверьте вход, загрузку медиа, покупки, восстановление фоновых операций и каждый отдельный рабочий домен.

Итог

Когда iOS-приложение работает через Wi-Fi, но не через мобильные данные, причина обычно находится на одном из нескольких уровней: разрешения, конфигурация клиента, переходы между сетями, IPv6 и DNS, TLS, предположения о тайм-аутах, маршрутизация CDN или региональные правила.

Самый быстрый путь к надёжному исправлению — систематическое сравнение. Воспроизведите сбой на реальном устройстве, найдите точный запрос и этап ошибки, отдельно проверьте IPv6, при необходимости сравните региональные маршруты и подтвердите решение в мобильной сети.

GateProxies может упростить сравнение внешних маршрутов и GEO, когда команде необходимо исследовать поведение веб-сервиса, API или CDN вне офисной сети. Это один из инструментов тестирования, а не замена проверкам непосредственно на устройстве.

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