Проксі, налаштований для одного іменованого HttpClient, не налаштовує автоматично всі клієнти, які повертає IHttpClientFactory. Тримайте ім'я реєстрації та запитане ім'я разом.

services.AddHttpClient("via-proxy")
    .ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
    {
        Proxy = new WebProxy("http://203.0.113.10:8080"),
        UseProxy = true
    });

Потім отримайте цю іменовану конфігурацію:

var client = factory.CreateClient("via-proxy");

Кінцева точка наведена для ілюстрації. Для дозволених запитів до публічних сервісів список HTTP-проксі пропонує кандидатів для URL-адреси WebProxy іменованого клієнта. Створення клієнта за замовчуванням без імені в іншому місці — це інший пошук, навіть якщо обидва клієнти походять з однієї й тієї самої впровадженої фабрики.

Налаштовуйте поведінку проксі на рівні з'єднання в основному обробнику, а не розглядайте її як заголовок запиту до призначення. Фабрика може керувати часом життя обробників окремо від об'єктів HttpClient, які вона повертає.

Якщо виклик належить типізованому клієнту або іншому SDK, перевірте, яка реєстрація надає його HttpClient. Правильно налаштований іменований клієнт, який ніколи не використовується, не впливає на мережевий шлях цього SDK.

Використовуйте цю конфігурацію для стабільної політики маршрутизації. Заміна працюючого обробника між операціями залишається окремою проблемою паралельності та часу життя.

Схожі статті