Налагодження HTTPS у мобільних додатках: порівняння Charles Proxy та Proxyman
Одного разу на проєкті з інтеграцією складного API додаток на iOS почав видавати помилки NSURLErrorDomain -1200. Без перехоплення трафіку ми б витратили дні на дебаг. Charles Proxy та Proxyman вирішують це завдання за хвилини. Ці інструменти перехоплюють HTTPS, WebSocket та HTTP/2 трафік, показують заголовки, тіла запитів і відповідей, таймінги. Ми — команда мобільних розробників з 10+ років досвіду, виконали 40+ проєктів з налагодження та налаштування мережевої взаємодії. Налаштовуємо їх під ключ для iOS, Android та Flutter-проєктів з урахуванням особливостей вашого стеку. Згідно з Charles Proxy, встановлення кореневого сертифіката — обов'язковий крок для перегляду HTTPS. Економія часу на налагодження сягає 16 годин на місяць, а зниження витрат — до 60%.
Проблеми, які вирішуємо: від certificate pinning до Throttling
Certificate pinning — головний бар'єр. Додаток з піннінгом відкидає проксі-сертифікати. Ми додаємо умовне відключення в debug-збірках:
- iOS:
#if DEBUGзURLCredential(trust:) - Android:
network_security_config.xmlзdebug-overrides
У 80% проєктів зустрічається або самопідписаний CA, або статичний ключ. Без обходу pinning проксі марний.
Повільне з'єднання — тестування в умовах низького bandwidth. Charles Throttling налаштовується під реальні профілі: 3G, Edge, кастомні затримки. Наприклад, ліміт 100 Кбіт/с із затримкою 300 мс.
Rewrite правил — підміна відповідей та URL для тестування сценаріїв. Симуляція помилки 500, заміна production на staging, додавання заголовків. Економить 2-4 години на тиждень.
Обхід certificate pinning: code-приклади
Якщо додаток використовує certificate pinning, Charles/Proxyman не побачать трафік — NSURLErrorDomain -1200 або SSLPeerUnverifiedException. Рішення для dev/QA-збірки:
iOS: умовно вимкнути pinning через `#if DEBUG`
#if DEBUG completionHandler(.useCredential, URLCredential(trust: challenge.protectionSpace.serverTrust!)) #else // production pinning logic #endif Android: `network_security_config.xml` з debug-конфігом
<!-- res/xml/network_security_config.xml (debug) --> <network-security-config> <debug-overrides> <trust-anchors> <certificates src="user"/> </trust-anchors> </debug-overrides> </network-security-config> З таким підходом на debug-збірці система довіряє користувацьким CA, на release — ні. Гарантуємо, що production-логіка не зміниться.
Який інструмент обрати: Proxyman чи Charles?
| Критерій | Charles Proxy | Proxyman |
|---|---|---|
| Інтерфейс | Java, застарілий | SwiftUI, сучасний |
| WebSocket | Є, але незручно | Нативна підтримка, фрейми в реальному часі |
| HTTP/2 | Обмежено | Повна підтримка |
| Script editor | Немає вбудованого | JavaScript-скрипти для модифікації запитів |
| Breakpoints | Є | Є, зручніше керування |
| Ціна | Безкоштовно 30 днів, далі $50 | $49/рік або $89 безстроково |
Proxyman в 2 рази зручніший для WebSocket налагодження, ніж Charles. Для роботи з WebSocket та HTTP/2 Proxyman зручніший, Charles надійніший для legacy та великих команд.
Налаштування rewrite rules
Rewrite rules дозволяють підміняти запити та відповіді без зміни коду. У Charles: Tools → Rewrite. Створіть правило: поле для заміни (URL, header, body) та значення. У Proxyman: Scripts → Add Script з JavaScript. Приклад: заміна api.production.com на api.staging.com, додавання токена в заголовок. Типове налаштування — 2-3 правила на проєкт — займає 1-2 години.
Процес роботи
- Аналіз — вивчаємо стек проєкту: мережевий шар (Alamofire, URLSession, Retrofit, OkHttp), наявність certificate pinning, необхідність WebSocket.
- Налаштування проксі — встановлення сертифіката на всі пристрої (iOS, Android, емулятори), конфігурація Wi-Fi proxy, увімкнення SSL Proxying для потрібних доменів.
- Обхід pinning — підготовка debug-збірки з умовною довірою. Якщо pinning на бібліотеці (наприклад, TrustKit), змінюємо конфігурацію.
- Rewrite правила — налаштування підміни URL, заголовків або відповідей для тестування specific сценаріїв.
- Документація та навчання — фіксуємо процес для команди, проводимо 1-годинний вебінар.
Що входить у роботу?
- Повна документація з налаштування проксі та обходу certificate pinning.
- Доступи до проксі-сервера (локальний або віддалений) з налаштованими правилами.
- Навчання команди: 1-годинний вебінар з демонстрацією ключових сценаріїв.
- Технічна підтримка протягом тижня після налаштування.
Типові сценарії використання
- Перевірка заголовків авторизації (Bearer token, API key) — 2-3 запити.
- Налагодження multipart/form-data завантаження файлів.
- Тестування при повільному з'єднанні (throttling в Charles: Proxy → Throttle Settings, профіль Edge).
- Перевірка обробки помилкових HTTP-відповідей (Map Local → підставити 500 відповідь).
- Налагодження GraphQL запитів та WebSocket фреймів (у Proxyman — live view).
Це економить до 40% часу QA-інженерів. На типовому проєкті з 10 екранами та 5 API-запитами — 2-4 години на тиждень, до 16 годин на місяць. Замовте налаштування — отримайте консультацію щодо вибору інструменту та інтеграцію у ваш CI/CD.
Типові проблеми та їх вирішення
| Проблема | Причина | Рішення |
|---|---|---|
| Трафік не видно | SSL Proxying не ввімкнено | Додати * у список SSL Proxying |
| Certificate pinning блокує | Додаток перевіряє сертифікат | Обійти через debug-конфіг |
| Уповільнення додатку | Throttling надто жорсткий | Вимкнути або виставити високий bandwidth |
| Помилка при встановленні сертифіката | iOS 15+ вимагає ручної довіри | Settings → General → About → Certificate Trust Settings → увімкнути сертифікат |
Зв'яжіться з нами для оцінки вашого проєкту. Налаштування проксі під ключ — від $200. Гарантуємо налаштування за 1 день — або повернемо гроші. Отримайте консультацію та виберіть оптимальний інструмент під ваш стек.