На корпоративном Wi‑Fi браузер открывает API, а приложение получает тайм-аут. Как проверить, что приложение игнорирует системный HTTP-прокси?
Нужно проверить запрос через контролируемый прокси и посмотреть, появляется ли он в журналах прокси. Если браузер проходит через прокси, а запрос приложения в его журналах отсутствует при тех же сетевых условиях, приложение, вероятно, устанавливает прямое соединение или использует транспорт, который данный прокси не поддерживает.
Одного факта, что браузер работает, недостаточно: браузер и приложение могут использовать разные сетевые библиотеки, настройки прокси и протоколы.
Корпоративные сети стали использовать HTTP-прокси для контроля доступа, аудита, фильтрации и ограничения исходящих соединений. Клиент сначала подключается к прокси, а тот уже пересылает запрос к внешнему серверу.
В мобильных ОС настройка прокси может задаваться для конкретной сети Wi‑Fi, но приложение не обязано обрабатывать её так же, как браузер. Результат зависит от сетевого стека приложения, используемого транспорта и политики организации.
При прямом подключении из корпоративной сети исходящий трафик к API может блокироваться межсетевым экраном. Браузер при этом работает через разрешённый прокси, поэтому сравнение только по результату создаёт ложный вывод о неисправности сервера или приложения.
Неверная диагностика приводит к попыткам менять тайм-ауты, DNS или сертификаты, хотя запрос вообще не достигает ни прокси, ни API. Отдельный риск возникает при HTTPS: прокси может передавать соединение через туннель, требовать аутентификацию или выполнять проверку сертификатов.
Сначала зафиксируйте одинаковые условия: одно устройство, одна сеть Wi‑Fi, один адрес API и один момент времени. Убедитесь, что браузер действительно использует прокси, а не получает ответ из кэша или через иной разрешённый маршрут.
Затем направьте тестовый запрос приложения через прокси, для которого доступны журналы. Проверьте три точки: попытку соединения на устройстве, запись запроса в журнале прокси и запись входящего запроса на сервере.
Интерпретация результатов:
Повторите тест через мобильную сеть. Если приложение работает там, но не в корпоративном Wi‑Fi, это подтверждает зависимость от сетевой политики, но ещё не доказывает именно игнорирование прокси.
Нужно учитывать, что HTTP-прокси и другие транспорты не взаимозаменяемы. Прокси может поддерживать обычный HTTP и HTTPS через туннелирование, но не поддерживать используемый приложением вариант транспорта. Поэтому в диагностике фиксируют не только адрес и порт, но и фактический протокол соединения.
Приложение не загружало данные в офисной сети, а браузер успешно открывал тот же домен. Рассматривались три варианта: увеличить тайм-аут, разрешить адрес API в межсетевом экране или проверить маршрут через корпоративный прокси.
Увеличение тайм-аута не помогло и лишь замедляло отображение ошибки. Разрешение прямого доступа решило бы проблему, но нарушало сетевую политику организации. Поэтому настроили тестовый прокси с журналированием и сравнили обращения браузера и приложения.
В журнале были только запросы браузера. На мобильной сети приложение работало, а в Wi‑Fi корпоративная сеть блокировала прямой выход. Выводом стало не изменение серверной части, а проверка поддержки прокси выбранным сетевым стеком и согласование допустимого маршрута с владельцами сети.
Нет. Браузер может использовать системный прокси, собственный защищённый DNS, кэш или другой разрешённый маршрут. Нужно подтвердить фактический путь именно запроса приложения по журналам прокси и сервера.
Нет. Запрос мог не дойти до прокси из-за ошибки разрешения имени, блокировки исходящего соединения или неверной настройки сети. Доказательство требует корреляции нескольких наблюдений: приложение не появляется в журнале прокси, браузер в тех же условиях появляется, а через мобильную сеть приложение работает.
При обычном HTTPS прокси часто видит факт туннелирования и адрес назначения, но не содержимое HTTP-запроса. Для расшифровки нужен режим контролируемой проверки TLS, а на мобильном устройстве могут дополнительно мешать доверие к тестовому сертификату или проверка сертификатов самим приложением. Поэтому для ответа на вопрос о маршруте обычно достаточно журналов соединений; перехват содержимого применяют только в разрешённой тестовой среде.