Проверка правил 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 с той же строкой не доказывает, что другой клиент выбрал тот же маршрут, а решение об обходе по-прежнему требует прямой сетевой доступности.

Похожие статьи