Quels identifiants .NET appartiennent au proxy ?

Pour un WebProxy personnalisé, placez le compte du proxy sur cet objet. Plusieurs autres propriétés d’identifiants .NET visent des destinataires différents :

Cet exemple .NET 10 fournit un proxy explicite et son propre compte :

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

Remplacez le point de documentation et utilisez un compte fourni par l’opérateur. Une entrée de liste sans authentification n’a pas besoin d’un identifiant inventé. Puisque Proxy du gestionnaire est explicitement affecté, DefaultProxyCredentials ne remplace pas WebProxy.Credentials.

UseDefaultCredentials a aussi une portée propre à l’objet : l’authentification serveur d’un gestionnaire et l’authentification proxy d’un WebProxy sont différentes. Envoyer le compte de l’utilisateur du processus n’est pas une réponse générique à 407.

Si le défi d’authentification persiste, vérifiez le mécanisme réel, le point choisi et l’instance client/gestionnaire. L’authentification proxy peut précéder le TLS de destination ; un en-tête Authorization du site ne peut donc pas y répondre. L’authentification prise en charge dépend toujours du gestionnaire, de la plateforme, du service et de la politique de déploiement ; aucun changement global du proxy Windows n’est requis.