Kontroleer .NET se NO_PROXY-reëls met HttpClient.DefaultProxy.IsBypassed

Vir HttpClient se gedokumenteerde omgewingsproksi-beleid pas example.internal en .example.internal verskillend. Die kaal naam kies die ouerhost; die voorpuntvorm kies sy subdomeine.

As albei direk moet wees, sluit albei by die opstartomgewing in:

export no_proxy='example.internal,.example.internal'

Voeg dit by die bestaande omseillys wat jy bedoel. Op stelsels met hooflettersensitiewe veranderlikename kyk .NET eerste na die kleinletter-proksiveranderlikes en daarna na die hoofletter-een, so 'n verouderde no_proxy kan voorrang bo NO_PROXY kry.

Binne die toepassing kan die verstekkeerder ondersoek word sonder om die bestemmings-HTTP-versoek te stuur:

foreach (var host in new[] {
    "example.internal", "api.example.internal", "other.internal"
})
{
    var uri = new Uri("https://" + host + "/");
    Console.WriteLine($"{host}: bypass={HttpClient.DefaultProxy.IsBypassed(uri)}");
}

Die fragment gebruik System en System.Net.Http. Ondersoek eerder die werklike handler-proksi as die toepassing 'n ander IWebProxy eksplisiet verskaf het. Stel die bedoelde omgewing voordat die verstekproksi geïnitialiseer word.

Dit is .NET se gedokumenteerde reëls. 'n curl-uitslag met dieselfde string bewys nie dat 'n ander kliënt dieselfde roete gekies het nie, en 'n omseilbesluit vereis steeds direkte netwerkbereikbaarheid.