Перевірка правил NO_PROXY у .NET за допомогою HttpClient.DefaultProxy.IsBypassed

Укажіть і голий домен, і форму з провідною крапкою, коли HttpClient має обходити проксі для обох, а потім перевірте IsBypassed.

Згідно з документованою політикою проксі з середовища в HttpClient, example.internal і .example.internal зіставляються по-різному. Голе ім'я вибирає батьківський хост; форма з провідною крапкою вибирає його піддомени.

Якщо обидва мають іти напряму, включіть обидва в середовище під час запуску:

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

Об'єднайте їх із передбачуваним наявним списком обходу. У системах, де імена змінних розрізняють регістр, .NET спершу перевіряє проксі-змінні в нижньому регістрі, а потім у верхньому, тому застарілий no_proxy може мати пріоритет над NO_PROXY.

Усередині програми селектор за замовчуванням можна переглянути, не надсилаючи HTTP-запит до пункту призначення:

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

Фрагмент використовує System і System.Net.Http. Якщо застосунок явно надав інший IWebProxy, перевіряйте натомість фактичний проксі обробника. Задайте потрібне середовище до ініціалізації проксі за замовчуванням.

Це документовані правила .NET. Результат curl із тим самим рядком не доводить, що інший клієнт вибрав той самий маршрут, а рішення про обхід усе ще потребує прямої мережевої доступності.

Схожі статті