Keep a Separate .NET Handler for Each Proxy Account
Build separate handlers for simultaneous accounts instead of replacing WebProxy.Credentials on a transport already serving requests.
A transport can retain the proxy credential-provider object chosen when its pool manager was created. Replacing WebProxy.Credentials afterward is not a reliable account-switch operation.
Create the route and account together before using the client:
var proxy = new System.Net.WebProxy(proxyEndpoint)
{
Credentials = new System.Net.NetworkCredential(proxyUser, proxyPassword)
};
var handler = new System.Net.Http.HttpClientHandler
{
UseProxy = true,
Proxy = proxy
};
var client = new System.Net.Http.HttpClient(handler);The endpoint and credentials come from application configuration. Build another handler for a second identity; another HttpClient sharing the first handler still shares its policy.
A custom ICredentials provider can answer later challenges, but it cannot relabel an established tunnel as another account. Assigning one global username/password around asynchronous calls leaves challenge timing and account ownership in conflict.
Keep a bounded set of clients when reuse is needed. Drain old work before disposing its transport. One new handler per request wastes connection pools; keeping every historical account forever grows them without a bound.