પોતાના 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 પ્રોક્સી બદલવાની જરૂર નથી.

સંબંધિત લેખો