Envoyer les requêtes .NET HttpClient via un proxy

La requête doit utiliser le HttpClient construit avec votre gestionnaire proxy. Créer un objet WebProxy sans rapport ne modifie pas le chemin d’un autre client.

using System;
using System.Net;
using System.Net.Http;

var proxy = new WebProxy("http://203.0.113.10:8080")
{
    BypassProxyOnLocal = false
};

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);
Console.WriteLine(await response.Content.ReadAsStringAsync());

Remplacez l’adresse documentaire par un vrai proxy HTTP de votre service ou de la liste de proxys HTTP. Cette syntaxe de haut niveau convient à un projet console C# moderne ; les projets anciens peuvent placer les instructions dans un Main asynchrone.

Vérifiez les deux propriétés du gestionnaire : Proxy choisit le point de terminaison et UseProxy=true active son utilisation. Si le point fonctionne séparément mais pas dans l’application, vérifiez qu’aucun code ne désactive UseProxy et que l’appel utilise cette instance. Le gestionnaire dédié évite de dépendre de la découverte du processus ou du système d’exploitation.

Lorsque l’opérateur fournit un compte, affectez un NetworkCredential à la propriété WebProxy.Credentials. L’Authorization du site concerne un autre relais ; une entrée IP:port publique ne fournit pas d’identifiants par défaut. Un point d’écoute http:// peut transporter HTTPS par tunnel ; conservez la vérification normale de la destination.

Ce court programme libère les objets à sa sortie. Pour des appels de service répétés, suivez les recommandations .NET sur la durée de vie du client et conservez le client/gestionnaire pour la charge, au lieu de reconstruire ses pools de connexions à chaque requête. Examinez le statut renvoyé : un chemin proxy fonctionnel peut encore transporter un refus du site.