Безопасен ли общий .NET IWebProxy при одновременных запросах?

IWebProxy описывает политику прокси. Он не даёт каждой реализации одинаковых гарантий параллелизма. Прежде чем делить один экземпляр между задачами рабочих, определите его конкретную реализацию и среду выполнения, к которой он относится.

Интерфейс предоставляет зависящие от назначения запросы маршрута и учётные данные. Пользовательская реализация может обращаться к фиксированному адресу, изменяемому состоянию или автоматической конфигурации. Этот выбор влияет как на безопасность, так и на производительность.

Держите изменения конфигурации вне обработки запросов

Избегайте использования одного общего объекта прокси как черновика: изменение его адреса или учётных данных для задачи A, пока задача B выбирает маршрут, делает владение неясным. Настройте политику до передачи клиенту. Для нагрузок с разными учётными записями прокси или конечными точками используйте отдельно принадлежащие конфигурации клиента.

Историческая документация WebProxy не давала гарантии потокобезопасности для членов экземпляра. Примените этот контракт к соответствующей реализации. Если требуется синхронизация, каждый читатель и писатель должны участвовать; блокировка-обёртка не может координировать вызывающих, которые напрямую используют исходный объект.

Долгая пауза в GetProxy может вместо этого быть связана с обнаружением или оценкой PAC. Microsoft документирует блокирующее обнаружение для WinHTTP; это объяснение применимо, когда клиент использует этот бэкенд. Измеряйте поиск маршрута отдельно от времени соединения и ответа. Сериализация медленного поиска может лишь создать очередь.

Фиксированная конечная точка может устранить обнаружение, когда предполагается фиксированный маршрут. Захват одного URI из изменяющейся системной политики также отбрасывает её будущие решения. Сохраняйте это различие при поддержке устаревшего кода; используйте HttpClient и поддерживаемую конфигурацию обработчика для новой работы с HTTP.