URI может содержать username:password перед своим узлом. Это не значит, что каждый .NET API, принимающий такой URI, копирует сведения о пользователе в объект проверки подлинности.

Создавая WebProxy напрямую, сделайте назначение учетных данных явным:

var proxy = new WebProxy("http://203.0.113.10:8080")
{
    Credentials = new NetworkCredential(proxyUser, proxyPassword)
};

Переменные конечной точки и учетной записи приведены для примера. Так адрес назначения, адрес прокси-сервера и учетная запись прокси-сервера остаются раздельными.

Если входной формат предоставляет URL с учетными данными, разбирайте сведения о пользователе осознанно. Сохраняйте пароль с двоеточиями, разделяя только по разделителю учетных данных, и декодируйте закодированные компоненты на нужном этапе. Не печатайте исходный URL при диагностике этого анализатора.

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

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

Похожие статьи