Для ўласнага WebProxy задайце ўліковы запіс проксі на гэтым аб’екце. Іншыя ўласцівасці ўліковых даных .NET маюць іншых атрымальнікаў:

УласцівасцьАтрымальнік
WebProxy.CredentialsПроксі, прадстаўлены гэтым аб’ектам.
HttpClientHandler.CredentialsСервер прызначэння.
DefaultProxyCredentialsСістэмны стандартны проксі, калі Proxy ёсць null, а UseProxy — true.

Гэты прыклад .NET 10 задае яўны проксі і яго ўласны ўліковы запіс:

using System;
using System.Net;
using System.Net.Http;

string password = Environment.GetEnvironmentVariable("PROXY_PASSWORD")
    ?? throw new InvalidOperationException("Set PROXY_PASSWORD");

var proxy = new WebProxy("http://203.0.113.10:8080")
{
    Credentials = new NetworkCredential("proxy-user", password)
};

using var handler = new HttpClientHandler
{
    Proxy = proxy,
    UseProxy = true
};
using var client = new HttpClient(handler)
{
    Timeout = TimeSpan.FromSeconds(15)
};

using var response = await client.GetAsync("https://example.com/");
Console.WriteLine((int)response.StatusCode);

Замяніце дакументацыйны пункт і выкарыстоўвайце ўліковы запіс ад аператара. Запіс спіса без аўтэнтыфікацыі не патрабуе прыдуманага ўваходу. Паколькі Proxy апрацоўшчыка зададзена яўна, DefaultProxyCredentials не замяняе WebProxy.Credentials.

UseDefaultCredentials таксама мае вобласць паводле аб’екта: аўтэнтыфікацыя апрацоўшчыка на серверы і аўтэнтыфікацыя WebProxy на проксі адрозніваюцца. Адпраўка ўліковага запісу карыстальніка працэсу не з’яўляецца агульным адказам на 407.

Калі патрабаванне аўтэнтыфікацыі застаецца, праверце фактычную схему, выбраны пункт і асобнік кліента/апрацоўшчыка. Аўтэнтыфікацыя проксі можа папярэднічаць TLS прызначэння, таму загаловак Authorization сайта не можа на яе адказаць. Падтрымка залежыць ад апрацоўшчыка, платформы, сэрвісу і палітыкі ўкаранення; глабальная змена проксі Windows не патрэбна.

Падобныя артыкулы