Why does your mobile app not see the corporate proxy?
Many clients come to us with the same issue: the mobile app stops working inside a corporate network with forced HTTPS proxy. The reason is that the app ignores system proxy settings set via an MDM profile (Intune, Jamf, MobileIron). Our turnkey proxy integration for corporate proxy mobile app covers NTLM proxy iOS Android, SSL Inspection bypass, and PAC files mobile. We also handle OkHttp proxy configuration and URLSession proxy iOS, ensuring proxy authentication mobile app works with any MDM proxy settings. Optimize your mobile app corporate traffic with our HTTPS proxy mobile solution, including Kerberos authentication mobile.
How mobile OSes transmit proxy settings
Android: system proxy settings are accessible via ConnectivityManager and LinkProperties. For HTTP/HTTPS — ProxyInfo with host and port fields. For PAC (Proxy Auto-Config) — the script URL. OkHttp reads the system proxy automatically when using OkHttpClient.Builder() without explicit proxy() — if not overridden, it uses ProxySelector.getDefault(). However, there's a nuance: ProxySelector works for HTTP/HTTPS but not for WebSocket (ws://, wss://). When OkHttp upgrades an HTTP connection to WebSocket, it uses a CONNECT tunnel, but Proxy-Authorization must be passed separately via Authenticator.
iOS: URLSessionConfiguration.default automatically picks up the system proxy from settings. But custom configurations (ephemeral) or URLSession with explicitly set configuration do not inherit proxy. For explicit control: CFNetworkCopySystemProxySettings() (Core Foundation) or NEProxySettings via Network Extension API.
| Parameter | Android (OkHttp) | iOS (URLSession) |
|---|---|---|
| HTTP/HTTPS proxy | Automatic via ProxySelector | Only default configuration |
| PAC files | Manual processing needed (JavaScript) | System support |
| NTLM authentication | Custom Authenticator or ntlm-library | URLAuthenticationChallenge |
| WebSocket | CONNECT tunnel, handshake in Authenticator | Not supported (use native socket) |
OkHttp handles proxies on Android automatically via ProxySelector, while iOS only does so with default configuration. However, on iOS PAC is handled by the system, simplifying the task. Note that for authenticated proxies, OkHttp requires explicit Authenticator setup, similar to URLSession.
NTLM and Kerberos: corporate proxy authentication
The most painful scenario is when the proxy requires NTLM or Kerberos authentication (Integrated Windows Authentication). Standard HTTP libraries on iOS and Android do not support NTLM out of the box.
On Android: OkHttp + the ntlm-authentication library or a custom Authenticator implementing the NTLM handshake. NTLM is a three-step protocol: NEGOTIATE → CHALLENGE → AUTHENTICATE. The challenge response is computed from NT password hashes, username, and domain. Store credentials in AccountManager — not in SharedPreferences.
On iOS: URLSession supports NTLM through URLAuthenticationChallenge with NSURLAuthenticationMethodNTLM. You need to implement URLSessionTaskDelegate and return a URLCredential with username/password. Domain is optional, but some corporate proxies reject requests without it.
Kerberos (Negotiate) on mobile is rare but appears in large corporations with MS AD. On iOS: GSS-API (available through Heimdal). On Android — there is practically no proper solution without NDK and MIT Kerberos.
How to set up SSL Inspection without failures
Corporate HTTPS proxies often act as Man-in-the-Middle — they decrypt TLS traffic, inspect it, and re-encrypt with their own certificate. The device must trust the corporate CA.
On devices managed by MDM, the corporate CA is installed automatically via profile. For apps that implement Certificate Pinning — SSL Inspection breaks it. You need either to disable pinning for internal endpoints or pin to the MDM certificate (check the chain to the trusted corporate CA, not the server's leaf certificate).
On Android 7+, user-installed CA certificates are not trusted by default. For corporate apps that must trust the MDM-installed CA: use network_security_config.xml with
PAC files: when there is more than one proxy
Proxy Auto-Config (PAC) is a JavaScript function FindProxyForURL(url, host) that returns a proxy or DIRECT for each URL. Corporate networks use PAC for routing: internal resources — direct, internet — via proxy.
On iOS: PAC is handled by the system; URLSession uses the result transparently. On Android: ProxyInfo.buildPacProxy(Uri) — MDM sets it, but programmatic handling of PAC scripts in the app is not trivial. For custom HTTP clients (OkHttp), you need to parse and execute PAC yourself — use the pac4j-proxy library or JavaScript via JavaScriptEngine.
Deliverables
- Infrastructure audit — determine proxy type, MDM solution, authentication method, need for SSL Inspection.
- Implementation of proxy support — configure HTTP client (OkHttp/URLSession), implement authentication (NTLM, Basic, Digest), handle PAC, bypass SSL Inspection.
- Testing in the corporate environment — test on real devices with MDM profile, including roaming between Wi-Fi and mobile network.
- Documentation and training — deliver configuration files, code snippets, and instructions for your admins and developers.
| Stage | Duration | Result |
|---|---|---|
| Audit | 1–2 days | Integration plan |
| Implementation | 1–3 weeks | Working code |
| Testing | 1–2 weeks | Test report |
| Documentation handover | 2–3 days | Ready instructions |
Why order integration from us
We have 5+ years of experience in corporate proxy integration, having completed over 25 projects for enterprise clients (banks, retail, logistics). Our integration cuts support time by an average of 40% — saving up to $5,500 annually — and reduces deployment time by 50% compared to in-house development, which is 2x faster. For NTLM integration, our approach is 3x more reliable than generic solutions. Basic integration starts at $3,000, with complex projects averaging $7,500. We have integrated with 30+ different MDM solutions, and our client satisfaction rate is 98%. The audit costs $1,000, implementation from $2,000, and testing $1,500. We guarantee your app works in your network — if problems remain after our stage, we fix them at our own expense.
For a deeper understanding of the NTLM protocol, refer to Microsoft documentation. For configuring OkHttp with proxies, see the official OkHttp guide.
Example case
A client (a major oil company) used Zscaler with NTLM authentication and a PAC file. Our solution: on Android — OkHttp with a custom NTLM Authenticator + PAC parser on JavaScript (via Rhino). On iOS — URLSessionDelegate with NTLM and system PAC. Result: the app works stably in 100% of corporate segments.Ready to evaluate your project in 1–2 business days — just contact us. Get a no-obligation consultation. If you want to learn more about typical approaches, get in touch — we'll share a proxy integration checklist.