Чому iOS-застосунок працює через Wi-Fi, але не через мобільну мережу: практичний посібник із тестування

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

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

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

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

Чому результати в Wi-Fi і мобільній мережі можуть відрізнятися

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

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

Тому твердження «працює через 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 на стільникову мережу. Використовуйте їх, щоб локалізувати питання регіональної маршрутизації, а потім обов'язково підтверджуйте виправлення на фізичному пристрої з мобільним підключенням.

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

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

1. Відтворіть проблему на фізичному iPhone. Використайте ту саму релізну або TestFlight-збірку та вимкніть Wi-Fi.
2. Перевірте дозволи й профілі. Переконайтеся в доступі до мобільної мережі; перевірте VPN, фільтрацію, режим економії даних (Low Data Mode) та обмеження керованого пристрою.
3. Визначте проблемний запит. З'ясуйте, чи зачіпає помилка авторизацію, API, медіа, оплату або сторонній SDK.
4. Визначте етап збою. Розділіть помилки DNS, установлення з'єднання, TLS, відповіді сервера та обробки даних на клієнті.
5. Перевірте роботу в мережі лише з IPv6. Використайте налаштування DNS64/NAT64, рекомендоване Apple, та усуньте припущення щодо наявності IPv4.
6. Порівняйте зовнішні маршрути. Перевірте регіони, де проблема спостерігається, і ті, де все працює, якщо місцеперебування може мати значення.
7. Вивчіть дані сервера. Якщо запит не доходить до сервера, дослідіть DNS, маршрутизацію, TLS або фільтрацію на периферії мережі. Якщо доходить — проаналізуйте статус відповіді та затримку.
8. Виправте найвужчу підтверджену причину. Уникайте широких винятків безпеки й безсистемного повторення запитів.
9. Повторіть повний користувацький сценарій. Перевірте вхід, завантаження медіа, покупки, відновлення фонових операцій і кожен окремий робочий домен.

Підсумок

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

Найшвидший шлях до надійного виправлення — систематичне порівняння. Відтворіть збій на реальному пристрої, знайдіть точний запит і етап помилки, окремо перевірте IPv6, за потреби порівняйте регіональні маршрути та підтвердьте рішення в мобільній мережі.

GateProxies може спростити порівняння зовнішніх маршрутів і GEO, коли команді необхідно дослідити поведінку вебсервісу, API або CDN поза офісною мережею. Це один з інструментів тестування, а не заміна перевіркам безпосередньо на пристрої.

Застосунок готовий до роботи лише тоді, коли повний користувацький сценарій успішно проходить і поза тією мережею, в якій продукт розробляли.

Джерела, наведені у вихідному матеріалі

• Apple Developer: Supporting IPv6-only Networks.
• Apple Developer: Supporting IPv6 DNS64/NAT64 Networks.
• Apple Developer: Preventing Insecure Network Connections.
• Apple Developer: waitsForConnectivity.
• Apple Developer: NWPathMonitor.
• GateProxies: резидентські, мобільні та ISP-проксі.