Um IWebProxy .NET compartilhado é seguro em solicitações simultâneas?

IWebProxy descreve uma política de proxy. Ele não concede a todas as implementações as mesmas garantias de simultaneidade. Antes de compartilhar uma instância entre tarefas de trabalho, identifique sua implementação concreta e o ambiente de execução ao qual ela pertence.

A interface expõe consultas de rota dependentes do destino e credenciais. Uma implementação personalizada pode consultar um endereço fixo, estado mutável ou configuração automática. Essas escolhas afetam tanto a segurança quanto o desempenho.

Mantenha as alterações de configuração fora do processamento de solicitações

Evite usar um objeto de proxy compartilhado como rascunho: alterar seu endereço ou credenciais para a tarefa A enquanto a tarefa B seleciona uma rota torna a propriedade ambígua. Configure uma política antes de entregá-la ao cliente. Para cargas de trabalho com contas ou endpoints de proxy diferentes, use configurações de cliente com propriedade separada.

A documentação histórica do WebProxy não oferecia garantia de segurança de threads para membros de instância. Aplique esse contrato à implementação correspondente. Se a sincronização for necessária, cada leitor e escritor deve participar; um bloqueio de wrapper não pode coordenar chamadores que usam o objeto original diretamente.

Uma pausa longa em GetProxy pode, em vez disso, envolver descoberta ou avaliação de PAC. A Microsoft documenta a descoberta bloqueante para WinHTTP; essa explicação se aplica quando o cliente usa esse backend. Meça a busca de rota separadamente do tempo de conexão e resposta. Serializar uma busca lenta pode apenas criar uma fila.

Um endpoint fixo pode eliminar a descoberta quando uma rota fixa é pretendida. Capturar um único URI de uma política de sistema em mudança também descarta suas decisões futuras. Preserve essa distinção ao manter código legado; use HttpClient e sua configuração de manipulador suportada para novos trabalhos HTTP.