Is a Shared .NET IWebProxy Safe Across Concurrent Requests?

IWebProxy describes a proxy policy. It does not give every implementation the same concurrency guarantees. Before sharing one instance across worker tasks, identify its concrete implementation and the runtime it belongs to.

The interface exposes destination-dependent route queries and credentials. A custom implementation may consult a fixed address, mutable state or automatic configuration. Those choices affect both safety and performance.

Keep configuration changes out of request processing

Avoid using one shared proxy object as a scratchpad: changing its address or credentials for job A while job B is selecting a route makes ownership unclear. Configure a policy before handing it to the client. For workloads with different proxy accounts or endpoints, use separately owned client configurations.

Historical WebProxy documentation withheld a thread-safety guarantee for instance members. Apply that contract to the corresponding implementation. If synchronization is required, every reader and writer must participate; a wrapper lock cannot coordinate callers using the original object directly.

A long pause in GetProxy may instead involve discovery or PAC evaluation. Microsoft documents blocking discovery for WinHTTP; that explanation applies when the client uses that backend. Measure route lookup separately from connection and response time. Serializing a slow lookup can merely create a queue.

A fixed endpoint can remove discovery when a fixed route is intended. Capturing one URI from a changing system policy also discards its future decisions. Preserve that distinction when maintaining legacy code; use HttpClient and its supported handler configuration for new HTTP work.