Как настроить Charles Proxy для перехвата запросов Flutter-приложения
PrimeCoder · 2026 · формат: tech
Разбор новинки простыми словами: что это, кому нужно и брать ли.
Flutter-командам приходится вшивать SSL-сертификат в debug-сборку, иначе QA не видит сетевые баги до релиза — стандартный Wi-Fi-прокси тут не работает.
Связанные услуги: каталог, AI Boost Team, стать клиентом.
Flutter-приложение и системный Wi-Fi-прокси живут в разных мирах. Настроили прокси на телефоне, открыли Charles — в списке пусто. Трафик при этом идёт, просто идёт мимо сниффера.
Павел Гершевич, Mobile Team Lead в Amiga и соавтор книги «Основы Flutter», разобрал на практике, как подготовить приложение и устройства, чтобы QA видел сетевые запросы до релиза. Материал не короткий (около 10 минут чтения), но вывод укладывается в одну фразу: без правки кода приложения перехвата не будет.
«Запросы идут напрямую в сеть, минуя прокси, который настроен через Wi-Fi устройства. Поэтому для настройки именно под Charles нам нужно будет добавить сам прокси к нашему коду на Flutter».
Что вообще произошло
Charles — старый инструмент из арсенала мобильного QA: он встаёт посредником между приложением и бэкендом, показывает запросы, умеет подменять ответы и тормозить соединение. С нативным кодом это работало годами. С Flutter — сломалось.
Причина в архитектуре. Flutter-разработчики обычно берут готовую библиотеку — dio или http — и отправляют запросы напрямую в сеть. Системная настройка «прокси для этой Wi-Fi сети» на такой трафик не распространяется, разработчики Android прямо пишут, что она работает в основном для браузера. Прокси-клиенты, которые ставят на устройство отдельным приложением, ведут себя иначе: они встраиваются перед выходом трафика в сеть. Charles так не умеет — он ждёт трафик на порту.
Отсюда типовая картина в команде: тестировщик настроил Wi-Fi, принял подключение в Charles, а в дереве запросов — тишина. И баг с потерянным токеном авторизации уезжает в прод.
Что тестировщик получает в руки
Три вещи, каждая закрывает свой класс дефектов.
Анализ трафика. Логи приложения не всегда удобны, а Charles показывает всю картину: когда ушёл запрос, на какой endpoint, какой статус вернулся, есть ли дубли, хватает ли данных в теле. Классика — приложение не положило токен в заголовок или отправило неполный набор полей. В логах это искать долго, в прокси видно сразу.
Подмена ответа. Два сценария. Первый — проверить, как клиент реагирует на ошибки сервера и корректно ли разбирает ответ. Второй — работать, пока бэкенд ещё на моках: тестировщик подставляет нужные данные и смотрит на поведение экранов.
Throttling. Эмуляция медленной и нестабильной сети. Ограничить скорость можно и другими способами, но через прокси удобнее ловить именно сетевые залипания.
Как это собрать
Charles запускают на компьютере — он сразу слушает локальную сеть на порту 8888. Дальше нужен адрес машины в этой сети: на Windows — ipconfig, на macOS — ipconfig getifaddr en0 (именно en0, это Wi-Fi), на Linux — ip a. Получается что-то вида 192.168.X.X, и прокси живёт по адресу 192.168.X.X:8888.
Устройство подключают к той же Wi-Fi сети и прописывают прокси вручную. На Android: настройки сети → Wi-Fi → подключенная сеть → редактировать → расширенные настройки → «Настройка вручную», хост и порт 8888. На iOS: Wi-Fi → подключенная сеть → настройка прокси → «Вручную», сервер и порт. После этого в Charles всплывает диалог о новом подключении — его надо принять.
Мелочь, которая бесит на дистанции: на iOS настройки сохраняются и при отключении прокси возвращаются одним переключателем, на Android при сбросе IP и порт придётся вводить заново.
Остаётся HTTPS. Без SSL-сертификата тела запросов не читаются, только факт соединения. Путей два, и они не равнозначны.
| Способ | Плюсы | Минусы |
|---|---|---|
| Сертификат на само устройство | Один раз — и работает для всех приложений. Код трогать не нужно, риск утечки в релиз нулевой | Повторять на каждом устройстве. Десяток тестировщиков и по пять устройств у каждого — это десятки ручных установок. Перехват открывается для всех приложений на телефоне, безопасность падает |
| Сертификат в нативной части приложения | Один раз для всех устройств. Привязка к debug-режиму или отдельному Flavor. Перехват только вашего приложения | Работает только на Android. Нужна пересборка и сопровождение кода |
Сам файл берут по адресу http://chls.pro/ssl с устройства, которое уже подключено к прокси, либо через меню Help → SSL Proxying → Save Charles Root Certificate.
Где подвох
Главная иллюзия — «настроил один раз и забыл». Сертификат на устройстве снижает общую безопасность телефона: под перехват попадают и сторонние приложения. Для личного девайса QA это терпимо, для корпоративного парка — вопрос политики, а не удобства.
Вшивание сертификата в нативное приложение выглядит чище, но закрывает только Android и требует, чтобы кто-то в команде держал эту часть кода в порядке. Зато привязка к debug или отдельному Flavor снимает риск, что сертификат уедет в релизную сборку.
И третье: маршрутизацию запросов всё равно надо решать в коде приложения. Сертификат отвечает на вопрос «доверять ли», а не «куда идти». Это две разные задачи, и вторая без правки Flutter-кода не закрывается.
Брать или подождать
Брать за 30 секунд: если у вас есть мобильный клиент на Flutter и хотя бы один тестировщик — берите. Настройка занимает силы один раз, экономит релизные баги потом.
Подождать: если мобильного приложения нет или QA-функцию выполняет разработчик — не тратьте время на инфраструктуру ради инфраструктуры.
Вердикт
Это не про «ещё один инструмент в стек». Это про то, что у QA появляется доступ к сетевому слою, которого раньше не было. Цена — полдня инженера и договорённость внутри команды, как именно ставится сертификат. Выгода — баги с токенами, дублями запросов и кривой десериализацией ловятся до релиза, а не в сторе в отзывах.
Начинать стоит с одного устройства и одного тестировщика. Если схема приживается, дальше два пути: раздать инструкцию на всю команду (быстро, дёшево, снижает безопасность устройств) или зашить сертификат в нативный слой debug-сборки (дольше, аккуратнее, только Android).
FAQ
Прокси включён, а Charles пустой. Что не так?
Запросы Flutter идут мимо системной настройки Wi-Fi. Проверять надо не телефон, а код приложения.
Можно обойтись без правки кода?
Сертификат на устройстве — да, но это решает только доверие к HTTPS. Маршрут запросов всё равно настраивается на стороне приложения.
Почему вшитый сертификат — только Android?
Так устроен разбор: способ с нативной частью приложения описан именно для Android. На iOS такой путь в материале не рассматривается.
Сколько это занимает?
Чтение разбора — около 10 минут. Настройка на практике дольше: один прокси на компьютере, ручные настройки на каждом устройстве, установка сертификата.
Что сделать на этой неделе
Заведите отдельный debug-флейвор, если его ещё нет. Поднимите Charles на машине, зафиксируйте IP и порт 8888 в командной вики. Пропишите вдвоём с тестировщиком настройки на одном Android и одном iOS, поставьте сертификат и поймайте первый реальный запрос. Дальше решайте: масштабировать на все устройства вручную или отдать инженеру задачу на вшивание сертификата в нативную часть.