Sjekk NO_PROXY-reglene i .NET med HttpClient.DefaultProxy.IsBypassed

List både det nakne domenet og formen med ledende punkt når HttpClient skal omgå proxyen for begge, og undersøk deretter IsBypassed.

Ifølge den dokumenterte miljøproxy-policyen til HttpClient matcher example.internal og .example.internal ulikt. Det nakne navnet velger vertsverten; formen med ledende punkt velger underdomenene.

Hvis begge skal gå direkte, ta begge med i oppstartsmiljøet:

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

Flett disse inn i den tiltenkte eksisterende unntakslisten. På systemer der variabelnavn skiller mellom store og små bokstaver, sjekker .NET først proxyvariabler med små bokstaver og deretter dem med store, så en utdatert no_proxy kan få forrang foran NO_PROXY.

Inne i programmet kan standardvelgeren undersøkes uten å sende HTTP-forespørselen til målet:

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)}");
}

Utdraget bruker System og System.Net.Http. Hvis programmet uttrykkelig har oppgitt en annen IWebProxy, undersøk den faktiske handler-proxyen i stedet. Angi det tiltenkte miljøet før standardproxyen initialiseres.

Dette er de dokumenterte reglene i .NET. Et curl-resultat med samme streng beviser ikke at en annen klient valgte samme rute, og en unntaksbeslutning krever fortsatt direkte nettverkstilgang.

Relaterte artikler