Интеграция корпоративного прокси-сервера в мобильное приложение

Почему мобильное приложение не видит корпоративный прокси?

Многие клиенты обращаются к нам с одной и той же проблемой: мобильное приложение перестаёт работать внутри корпоративной сети с принудительным HTTPS-прокси. Причина — приложение игнорирует системные настройки прокси, установленные через MDM-профиль (Intune, Jamf, MobileIron). Наш опыт показывает, что корректная интеграция с прокси — задача нетривиальная, особенно если прокси требует NTLM-аутентификацию или выполняет SSL Inspection. Давайте разберём подводные камни на практических примерах.

Как мобильные ОС передают настройки прокси

Android: системные настройки прокси доступны через ConnectivityManager и свойства LinkProperties. Для HTTP/HTTPS — ProxyInfo с полем host и port. Для PAC (Proxy Auto-Config) — URL скрипта. OkHttp читает системный прокси автоматически при использовании OkHttpClient.Builder() без явного proxy() — если не переопределять, он использует ProxySelector.getDefault(). Но есть нюанс: ProxySelector работает для HTTP/HTTPS, но не для WebSocket (ws://, wss://). OkHttp при апгрейде HTTP-соединения до WebSocket использует CONNECT-туннель, но Proxy-Authorization нужно передавать отдельно через Authenticator.

iOS: URLSessionConfiguration.default автоматически подхватывает системный прокси из настроек. Но кастомные конфигурации (ephemeral) или URLSession с явно заданным configuration — не наследуют proxy. Для явного контроля: CFNetworkCopySystemProxySettings() (Core Foundation) или NEProxySettings через Network Extension API.

OkHttp справляется с прокси на Android автоматически через ProxySelector, а iOS — только при default configuration. Но на iOS PAC обрабатывается системой, что упрощает задачу. Обратите внимание, что для прокси с аутентификацией OkHttp требует явной настройки Authenticator, аналогично URLSession.

NTLM и Kerberos: корпоративная аутентификация прокси

Самый болезненный сценарий — прокси требует NTLM или Kerberos аутентификацию (Integrated Windows Authentication). Стандартные HTTP-библиотеки на iOS и Android не поддерживают NTLM из коробки.

На Android: OkHttp + библиотека ntlm-authentication или кастомный Authenticator с реализацией NTLM handshake. NTLM — трёхшаговый протокол: NEGOTIATE → CHALLENGE → AUTHENTICATE. Ответ на challenge вычисляется на основе хэшей NT-пароля, username и domain. Хранить credentials в AccountManager — не в SharedPreferences.

На iOS: URLSession поддерживает NTLM через URLAuthenticationChallenge с NSURLAuthenticationMethodNTLM. Нужно реализовать URLSessionTaskDelegate и возвращать URLCredential с username/password. Domain — опционально, но без него некоторые корпоративные прокси не принимают.

Kerberos (Negotiate) на мобиле — редкость, но встречается в крупных корпорациях с MS AD. На iOS: GSS-API (доступен через Heimdal). На Android — практически нет нормального решения без NDK и MIT Kerberos.

Как настроить SSL Inspection без сбоев

Корпоративный HTTPS-прокси часто выступает Man-in-the-Middle — расшифровывает TLS-трафик, проверяет, перешифровывает собственным сертификатом. Устройство должно доверять корпоративному CA.

На устройствах с MDM корпоративный CA устанавливается автоматически через профиль. Для приложений, которые реализуют Certificate Pinning — SSL Inspection ломает его. Нужно либо отключить pinning для внутренних эндпоинтов, либо pinning на уровне MDM-сертификата (проверять не leaf-сертификат сервера, а цепочку к доверенному корпоративному CA).

На Android 7+ пользовательские CA-сертификаты не доверяются приложениям по умолчанию. Для корпоративных приложений, которые должны доверять MDM-установленному CA: network_security_config.xml с <certificates src="system"/> и явным указанием <certificates src="user"/> для development, только system для production MDM.

PAC-файлы: когда прокси не один

Proxy Auto-Config (PAC) — JavaScript-функция FindProxyForURL(url, host), которая возвращает прокси или DIRECT для каждого URL. Корпоративные сети используют PAC для маршрутизации: внутренние ресурсы — напрямую, интернет — через прокси.

На iOS: PAC обрабатывается системой, URLSession использует результат прозрачно. На Android: ProxyInfo.buildPacProxy(Uri) — MDM устанавливает, но программная обработка PAC-скриптов в приложении не тривиальна. Для кастомных HTTP-клиентов (OkHttp) нужно парсить и выполнять PAC самостоятельно — библиотека pac4j-proxy или JavaScript через JavaScriptEngine.

Что входит в интеграцию под ключ

1. Аудит инфраструктуры — определяем тип прокси, MDM-решение, метод аутентификации, необходимость SSL Inspection.
2. Реализация поддержки прокси — настройка HTTP-клиента (OkHttp/URLSession), реализация аутентификации (NTLM, Basic, Digest), обработка PAC, bypass SSL Inspection.
3. Тестирование в корпоративной среде — проверяем на реальных устройствах с MDM-профилем, включая роуминг между Wi-Fi и мобильной сетью.
4. Документация и обучение — передаём конфигурационные файлы, code snippets, инструкции по настройке прокси для ваших администраторов и разработчиков.

Почему стоит заказать интеграцию у нас

У нас 5+ лет опыта в интеграции корпоративных прокси, выполнено более 20 проектов для enterprise-клиентов (банки, ритейл, логистика). Мы гарантируем работоспособность приложения в вашей сети — если после нашего этапа останутся проблемы, доведём до ума за свой счёт. Средняя экономия затрат на поддержку составляет до 500 000 рублей ежегодно — за счёт исключения сбоев при смене прокси или обновлении MDM-политик.

Для более глубокого понимания протокола NTLM можно обратиться к документации Microsoft. А для настройки OkHttp под прокси — официальный гайд OkHttp.

Готовы оценить ваш проект за 1–2 рабочих дня — просто напишите нам. Получите консультацию без обязательств. А если хотите узнать больше о типовых подходах, свяжитесь с нами — поделимся чек-листом по интеграции прокси.