Кои .NET данни за вход принадлежат на проксито?
Различавайте WebProxy.Credentials, данните на целевия сървър и DefaultProxyCredentials при удостоверяване на HTTP прокси.
За собствен WebProxy задайте прокси акаунта на този обект. Други .NET свойства за данни за вход обслужват различни получатели:
| Свойство | Получател |
|---|---|
WebProxy.Credentials | Проксито, представено от този обект. |
HttpClientHandler.Credentials | Целевият сървър. |
DefaultProxyCredentials | Системното прокси по подразбиране, когато Proxy е null, а UseProxy е true. |
Този .NET 10 пример задава изрично прокси и негов собствен акаунт:
using System;
using System.Net;
using System.Net.Http;
string password = Environment.GetEnvironmentVariable("PROXY_PASSWORD")
?? throw new InvalidOperationException("Set PROXY_PASSWORD");
var proxy = new WebProxy("http://203.0.113.10:8080")
{
Credentials = new NetworkCredential("proxy-user", password)
};
using var handler = new HttpClientHandler
{
Proxy = proxy,
UseProxy = true
};
using var client = new HttpClient(handler)
{
Timeout = TimeSpan.FromSeconds(15)
};
using var response = await client.GetAsync("https://example.com/");
Console.WriteLine((int)response.StatusCode);
Заменете документационната крайна точка и използвайте акаунт от оператора. Запис без удостоверяване не се нуждае от измислен вход. Понеже Proxy на обработчика е изрично зададено, DefaultProxyCredentials не заменя WebProxy.Credentials.
UseDefaultCredentials също има обхват според обекта: удостоверяването към сървъра на обработчика и прокси удостоверяването на WebProxy са различни. Изпращането на акаунта на потребителя на процеса не е универсален отговор на 407.
Ако заявката за удостоверяване продължава, проверете действителната схема, избраната точка и инстанцията клиент/обработчик. Прокси удостоверяването може да предхожда TLS към целта, затова Authorization заглавка на сайта не може да му отговори. Поддръжката все още зависи от обработчик, платформа, услуга и политика на внедряване; не е нужна глобална промяна на Windows проксито.