Diagnosing Intermittent Connection Pool Exhaustion in Xamarin HttpClient

Direct Answer

Default pool size: Xamarin's HttpClient inherits platform limits — approximately 4–6 concurrent connections per host on iOS (NSUrlSession) and 5 per host on Android (OkHttp). These are hard OS caps; HttpClientHandler.MaxConnectionsPerServer is ignored on iOS and capped by OkHttp on Android.

Platform limit interaction: When concurrent requests exceed the per-host limit, the OS queues or drops connections silently. The symptom appears as intermittent TaskCanceledException or HttpRequestException with no clear timeout, because the pool cannot grow and requests stall until a slot frees.

Single shared HttpClient: Reusing one instance reliably prevents the dominant exhaustion cause (creating a new handler/pool per request). Side effects exist: stale DNS entries after TTL expiry and cookie/header persistence. Mitigate with PooledConnectionLifetime = TimeSpan.FromMinutes(2) on the handler to force periodic DNS re-resolution.

Likely Explanation vs. Confirmed Facts

Likely Explanation	Confirmed Fact
Intermittent failures under load stem from per-request new HttpClient() leaking handlers until GC finalizes them.	Each HttpClient constructor creates a new HttpClientHandler (and thus a new native pool). Disposing the client does not immediately release the native sockets.
Stale DNS after load-balancer IP rotation looks like pool exhaustion because retries consume remaining slots.	PooledConnectionLifetime (available on .NET Standard 2.0+ via HttpClientHandler) closes idle connections after the set window, triggering fresh DNS lookup.
iOS enforces ~4–6 connections/host regardless of MaxConnectionsPerServer.	Only a custom NSUrlSessionConfiguration injected via a derived handler can change this; not possible with stock HttpClientHandler.

Steps Needed for This Case

1. Audit instantiation pattern: Search the codebase for new HttpClient() inside request paths. Replace with a single static readonly HttpClient initialized at startup:

   static readonly HttpClient Client = new HttpClient(new HttpClientHandler
   {
       PooledConnectionLifetime = TimeSpan.FromMinutes(2),
       // MaxConnectionsPerServer is ignored on iOS; leave default on Android
   });

2. Verify handler count stays at 1: Add a static counter in the handler constructor/finalizer (or use dotnet-trace with System.Net.Http provider) and log every 30 s. The count must not grow with request rate.
3. Confirm platform socket plateau: During a load test, run:
   • Android: adb shell cat /proc/$(pidof your.package)/net/tcp — connections to the target host should plateau at ~5.
   • iOS simulator: lsof -p <pid> -i — plateau at ~4–6.
4. Test DNS rotation recovery: Edit /etc/hosts (or use a rotating DNS record) to change the target IP while the app runs. Requests should recover within the PooledConnectionLifetime window without restart.

One Missing Diagnostic Detail

Are you targeting .NET Standard 2.0 / Xamarin.Forms or have you migrated to .NET 6+ / MAUI? The answer changes whether PooledConnectionLifetime is available on the stock handler and whether HttpClientFactory (with built-in pooling) can be adopted instead of a manual singleton.