Changing a Used .NET HttpClient Proxy Handler Can Fail
Keep .NET proxy routing stable during concurrent requests instead of modifying handler properties after use.
Configure .NET handler routing before first use. Setting Proxy or UseProxy after requests begin can throw InvalidOperationException.
| Change | What it does not provide |
|---|---|
| Rewrite a used handler property | A supported request-local route switch |
Mutate assigned WebProxy.Address | Atomic selection for concurrent requests or movement of pooled connections |
Put a global current value inside IWebProxy | A defined concurrency policy merely by moving the state |
For a bounded set of routes, keep reusable clients/handler groups associated with those policies and select the client before sending. A custom IWebProxy can make deliberate, concurrency-safe decisions, but a mutable shared scratch value remains ambiguous.
Bound route clients and in-flight work for destinations, duration, connection lifetime and OS limits. More routes add pools/sockets, so a benchmark's proxy count is not a capacity guarantee.
A retry through another proxy is another bounded attempt with its own client/outcome. For submissions, retain the possibility that the first request was processed before its reply disappeared.