La semaine dernière, j’ai perdu un temps franchement gênant à fixer une réponse 407 Proxy Authentication Required, persuadé que mon fournisseur de proxy avait un souci. En réalité, j’avais mis les identifiants au mauvais endroit — une correction de deux lignes qui m’a pris deux heures à dénicher. Si ça vous parle, ce guide est pour vous.
La configuration d’un proxy avec HttpClient en C# fait partie de ces sujets où la base paraît simple, mais où les pièges en prod — saturation des sockets, incompatibilités de version SOCKS5, confusion sur les identifiants — vous font perdre un temps précieux.
Je travaille depuis un moment sur des outils de web scraping et d’extraction de données chez Thunderbit, et j’ai vu ces mêmes erreurs revenir encore et encore, aussi bien dans nos échanges techniques que dans les communautés de développeurs qu’on suit. Ce tutoriel couvre tout le parcours : mise en place, authentification, rotation de proxy, choix du protocole et tableau de dépannage que j’aurais vraiment aimé avoir le jour où j’ai commencé.
Niveau : Débutant à intermédiaire
Temps requis : Environ 15 minutes pour suivre, plus pour les scénarios de rotation en production
Ce qu’il vous faut : SDK .NET 6+ (pour SOCKS5 et les fonctionnalités modernes des handlers ; .NET Framework 4.x fonctionne pour les exemples de proxy HTTP de base), un éditeur de code et au moins un endpoint proxy à tester
Qu’est-ce que HttpClient et pourquoi a-t-il besoin d’un proxy ?
HttpClient est la classe intégrée de .NET, dans System.Net.Http, pour envoyer des requêtes HTTP et recevoir des réponses. Elle gère async/await, les en-têtes personnalisés, les jetons d’annulation et une configuration basée sur des handlers. Microsoft la décrit comme une classe permettant d’envoyer des requêtes HTTP et de recevoir des réponses HTTP depuis une ressource identifiée par une URI.
Un serveur proxy est un intermédiaire entre votre application et le site cible. Quand vous faites passer le trafic par un proxy, le site de destination voit l’adresse IP du proxy à la place de la vôtre.
HttpClient n’a pas directement de propriété Proxy. Le routage via proxy se configure sur le handler sous-jacent — soit HttpClientHandler, soit SocketsHttpHandler — qui accepte une instance de WebProxy. Le modèle mental ressemble à ça :
[Votre application C#] → [HttpClient + Handler] → [Serveur proxy] → [Site cible]
C’est pour ça que « changer le proxy d’un HttpClient déjà utilisé » relève d’un souci d’architecture, pas d’un simple changement de propriété. J’y reviens plus loin dans la partie sur la rotation.
Essayez Thunderbit pour simplifier l’extraction de données
Pourquoi utiliser un proxy avec HttpClient en C# ?
Les développeurs redirigent le trafic de HttpClient via des proxies pour plusieurs raisons très courantes, et le bon type de proxy dépend de l’usage.
- Éviter les bannissements d’IP et les limites de débit : indispensable pour le web scraping, la génération de leads ou la surveillance de prix à grande échelle. Une seule IP qui envoie trop de requêtes sera vite bloquée.
- Contourner les restrictions géographiques : accéder à des API ou des contenus bloqués selon la région grâce à des proxies situés dans certains pays.
- Masquer votre IP d’origine : ajouter une couche de confidentialité pour la collecte de données sensibles ou l’analyse concurrentielle.
- Contraintes d’entreprise ou de conformité : beaucoup d’organisations exigent que le trafic sortant passe par une passerelle centralisée pour la journalisation et la gouvernance.
- Tests et QA : simuler des requêtes depuis différents emplacements ou conditions réseau sans déployer d’infrastructure dans ces zones.
| Cas d’usage | Type de proxy conseillé | Pourquoi c’est adapté |
|---|---|---|
| Web scraping à grande échelle | Proxies résidentiels rotatifs | Plus de diversité d’IP, plus difficile à classer par les systèmes anti-bot |
| Suivi des prix e-commerce | Résidentiel ou datacenter géolocalisé | Vérification des prix et des stocks selon la région |
| Accès API via une passerelle fixe | Proxy datacenter ou proxy d’entreprise | Allowlisting IP prévisible, coût plus faible |
| Conformité entreprise | Proxy système, proxy PAC, proxy d’entreprise authentifié | Journalisation centralisée et contrôle des flux sortants |
| Tests QA et localisation | Pool de proxies par pays | Simule un accès réel depuis les régions ciblées |
L’usage d’un proxy évolue aussi par étapes assez prévisibles. On commence avec un proxy statique unique pour valider le routage. Un scraper de production passe ensuite à un pool, en associant les requêtes aux proxies selon le domaine cible, la zone géographique ou le taux d’échec. Les équipes plus mûres s’orientent souvent vers une passerelle proxy managée, où la rotation, les tentatives et l’affinité de session sont gérées derrière un seul endpoint.
La rotation de proxy n’est pas une solution miracle. Si une cible bloque les comportements suspects, changer d’IP aide seulement si la cadence des requêtes, les en-têtes, les cookies et l’empreinte TLS sont aussi gérés proprement.
Quelles versions de .NET prennent en charge quoi ? Tableau de compatibilité rapide
Copier un exemple de proxy trouvé dans un article sans vérifier la cible de framework est une des grandes causes d’échecs silencieux. La grande séparation se fait entre .NET Framework 4.x et le .NET moderne (.NET 6+). Voici ce qui fonctionne où :
| Fonctionnalité | .NET Framework 4.x | .NET 6 | .NET 7 | .NET 8–9 |
|---|---|---|---|---|
WebProxy + HttpClientHandler | Oui | Oui | Oui | Oui |
SOCKS5 via WebProxy("socks5://...") | Non | Oui (ajouté dans .NET 6) | Oui | Oui |
SocketsHttpHandler (handler par défaut) | Non | Oui | Oui | Oui |
HttpClient.DefaultProxy statique | Non | Oui | Oui | Oui |
PooledConnectionLifetime | Non | Oui | Oui | Oui |
Si vous ciblez .NET Framework 4.x, restez sur des proxys HTTP/HTTPS avec HttpClientHandler et WebProxy. SOCKS5 et les contrôles modernes de pooling nécessitent .NET 6 ou une version plus récente.
Un comportement subtil à surveiller : HttpClient.DefaultProxy est une propriété statique dans le .NET moderne. Si elle est définie dans un code de démarrage partagé ou héritée de variables d’environnement comme HTTPS_PROXY ou HTTP_PROXY, chaque instance de HttpClient la récupère sauf si vous la remplacez explicitement dans le handler. Dans les déploiements conteneurisés, c’est une source fréquente de confusion du genre : « pourquoi mon client utilise-t-il un proxy que je n’ai jamais configuré ? ».
Étape 1 : créer un nouveau projet console C#
Ouvrez un terminal et créez un nouveau projet :
dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo
Vérifiez la version de votre SDK avec dotnet --version. Les exemples de ce guide visent .NET 6+ pour couvrir toutes les fonctionnalités. Si vous avez besoin du dernier SDK LTS, prenez-le sur la page de téléchargement de Microsoft.
Ouvrez Program.cs dans votre éditeur. C’est là que tout se passe.
Étape 2 : faire une requête HTTP de base, sans proxy
Avant de configurer un proxy, identifiez votre IP de sortie réelle. Comme ça, une fois le proxy activé, vous pourrez vérifier que l’IP a bien changé.
using System.Net.Http;
using var client = new HttpClient();
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Direct IP: {ip}");
Lancez le code. Vous devriez voir votre adresse IP publique actuelle, par exemple :
Direct IP: 203.0.113.10
Gardez cette valeur en tête. À l’étape suivante, elle devrait être différente.
Étape 3 : configurer un WebProxy avec HttpClientHandler
Le schéma classique repose sur trois objets : un WebProxy, un handler et le client.
using System.Net;
using System.Net.Http;
var proxy = new WebProxy("http://proxy.example.com:8080")
{
BypassProxyOnLocal = false
};
var handler = new HttpClientHandler
{
Proxy = proxy,
UseProxy = true,
UseDefaultCredentials = false
};
using var client = new HttpClient(handler);
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Proxy IP: {ip}");
Remplacez proxy.example.com:8080 par votre endpoint proxy réel. Si tout est bien branché, l’IP affichée doit maintenant correspondre à l’IP de sortie du proxy, et non à la vôtre.
Points clés à retenir :
Proxy— l’instanceIWebProxyutilisée par le handler pour le routage.UseProxy = true— dit au handler d’utiliser réellement le proxy configuré. (Ça paraît évident, mais l’oublier fait vraiment perdre du temps en débogage.)BypassProxyOnLocal = false— empêche le handler de contourner le proxy pour les destinations jugées « locales ».UseDefaultCredentials— contrôle l’envoi des identifiants Windows par défaut. Ce n’est pas la même chose que le couple nom d’utilisateur/mot de passe du proxy.
Étape 4 : ajouter l’authentification proxy avec NetworkCredential
La plupart des fournisseurs de proxy payants exigent des identifiants. La bonne manière de faire consiste à les définir directement sur l’objet WebProxy :
using System.Net;
using System.Net.Http;
var proxy = new WebProxy("http://proxy.example.com:8080")
{
Credentials = new NetworkCredential("proxy-user", "proxy-password")
};
var handler = new HttpClientHandler
{
Proxy = proxy,
UseProxy = true
};
using var client = new HttpClient(handler);
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Authenticated proxy IP: {ip}");
Beaucoup de fournisseurs donnent une URL au format http://username:password@host:port. Pour du code .NET, mieux vaut utiliser NetworkCredential plutôt que d’intégrer les identifiants dans la chaîne URI. Ça évite les soucis d’échappement avec les caractères spéciaux dans les mots de passe et ça sépare clairement l’URI des identifiants.
Je détaille plus bas l’erreur d’authentification la plus fréquente — et pourquoi elle déclenche des erreurs 407.
Étape 5 : exploiter ou exporter les données de réponse
Pour aller au-delà d’un simple test d’IP, traitez la réponse correctement :
using var response = await client.GetAsync("https://example.com/api/products");
if (!response.IsSuccessStatusCode)
{
Console.WriteLine($"Request failed: {(int)response.StatusCode} {response.ReasonPhrase}");
return;
}
var body = await response.Content.ReadAsStringAsync();
Console.WriteLine(body);
Dans un workflow de scraping, la requête via proxy n’est que la couche transport. Il faut encore gérer le parsing, la normalisation, la déduplication, les retries et l’export vers Excel, Google Sheets, des bases de données ou d’autres destinations. Des outils comme Thunderbit peuvent automatiser l’extraction et l’export — son extension Chrome gère l’extraction de données structurées et les exports gratuits vers Google Sheets, Excel, Airtable ou Notion sans vous demander d’écrire du code de parsing.
Exporter les données extraites vers Excel, Sheets, Airtable ou Notion Get Started Free
Identifiants du proxy vs identifiants du serveur : l’erreur qui provoque les 407
J’ai vu cette erreur dans des threads Stack Overflow, des posts Microsoft Q&A et — je l’avoue — dans mon propre code.
La distinction est simple, mais facile à confondre :
- Les identifiants du proxy vous authentifient auprès du serveur proxy lui-même.
- Les identifiants du serveur vous authentifient auprès du serveur de destination.
Dans HttpClientHandler, ces paramètres vivent sur des propriétés différentes. Mettre les identifiants au mauvais endroit est la cause n°1 des erreurs 407 Proxy Authentication Required.
// ❌ FAUX — définit les identifiants pour le serveur de destination, pas pour le proxy
handler.Credentials = new NetworkCredential("user", "pass");
// ✅ CORRECT — définit les identifiants directement sur l’objet proxy
handler.Proxy = new WebProxy("http://proxy:8080")
{
Credentials = new NetworkCredential("user", "pass")
};
HttpClientHandler.Credentials cible la destination. WebProxy.Credentials cible le proxy. Si le proxy renvoie 407, vos identifiants doivent être placés sur le proxy.
Autre piège : HttpClientHandler.PreAuthenticate contrôle le comportement de pré-authentification pour l’authentification du serveur cible. Il ne contrôle pas l’en-tête Proxy-Authorization. Ne l’utilisez pas comme solution de secours pour une erreur 407.
Comment faire tourner les proxies avec HttpClient en C#
Les développeurs posent cette question tout le temps sur les forums. La réponse est d’abord un peu frustrante : vous ne pouvez pas changer le proxy d’une instance HttpClient déjà en cours d’utilisation. Le proxy appartient au handler. Le handler est défini à la construction. HttpClient n’expose aucune propriété Proxy modifiable.
La solution naïve — new HttpClient(new HttpClientHandler { Proxy = ... }) à chaque requête — crée un autre problème. Microsoft met clairement en garde contre le fait de créer et de détruire des clients à chaque requête, car cela peut épuiser les ports TCP disponibles : les ports ne sont pas libérés immédiatement après la fermeture de la connexion.
Voici donc trois approches vraiment adaptées à la production.
Option 1 : clients nommés via IHttpClientFactory
Si votre ensemble de proxies est connu au démarrage, les clients nommés sont l’option la plus simple. Chaque client nommé reçoit sa propre configuration de handler, et le code applicatif les récupère par nom à l’exécution.
builder.Services.AddHttpClient("proxy-us")
.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
Proxy = new WebProxy("http://us-proxy.example.com:8080")
{
Credentials = new NetworkCredential("user", "pass")
},
UseProxy = true
});
builder.Services.AddHttpClient("proxy-eu")
.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
Proxy = new WebProxy("http://eu-proxy.example.com:8080")
{
Credentials = new NetworkCredential("user", "pass")
},
UseProxy = true
});
// Au moment de la requête :
var client = httpClientFactory.CreateClient("proxy-us");
La factory gère la durée de vie des handlers et évite le mauvais pattern du client recréé à chaque requête.
Option 2 : SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)
Pour un client longue durée derrière une passerelle proxy qui change d’IP de sortie sur les nouvelles connexions, PooledConnectionLifetime force la recréation des connexions après une durée définie.
var handler = new SocketsHttpHandler
{
Proxy = new WebProxy("http://rotating-gateway.example.com:8080")
{
Credentials = new NetworkCredential("user", "pass")
},
UseProxy = true,
PooledConnectionLifetime = TimeSpan.FromMinutes(5)
};
using var client = new HttpClient(handler);
Ça ne change pas magiquement l’objet Proxy à chaque requête. Ça fonctionne surtout avec des passerelles proxy qui attribuent une IP de sortie différente à chaque nouvelle connexion TCP, ou avec des pools de proxies pilotés par DNS où le nom d’hôte résout vers différents endpoints au fil du temps.
Option 3 : DelegatingHandler personnalisé pour une sélection avancée du proxy
Quand le choix du proxy dépend de l’URL de la requête, de la charge utile ou du contexte d’exécution, un handler de routage personnalisé peut inspecter chaque requête et la diriger vers le bon pipeline de handlers internes.
public sealed class ProxyRoutingHandler : DelegatingHandler
{
private readonly IReadOnlyDictionary<string, HttpMessageInvoker> _clients;
protected override Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request,
CancellationToken cancellationToken)
{
var key = SelectProxyKey(request);
return _clients[key].SendAsync(request, cancellationToken);
}
}
C’est une architecture avancée. La sécurité des threads, la libération des ressources, la réutilisation des handlers, le comportement des retries et la journalisation deviennent votre responsabilité. Je la recommande seulement si les deux premières options ne conviennent vraiment pas.
Comparaison des trois approches
| Approche | Complexité | Version .NET | Sécurité des threads | Surcharge |
|---|---|---|---|---|
| Clients nommés (IHttpClientFactory) | Faible | .NET Core 2.1+ | Élevée (configuration immuable) | Faible |
| SocketsHttpHandler + PooledConnectionLifetime | Moyenne | .NET 6+ | Élevée | Faible |
| DelegatingHandler personnalisé | Élevée | Toute version | Dépend de l’implémentation | Moyenne |
Pour la plupart des équipes, les clients nommés sont le meilleur point de départ. Passez à PooledConnectionLifetime pour des passerelles rotatives stables, et au routage personnalisé seulement quand le choix du proxy dépend de métadonnées au niveau de la requête.
Choisir le bon protocole proxy : HTTP, HTTPS et SOCKS5
Tous les proxies ne parlent pas la même langue, et utiliser un mauvais schéma de protocole provoque des erreurs déroutantes.
Proxy HTTP : comprend les requêtes HTTP. Pour des cibles HTTP simples, il peut les transmettre directement. Pour des cibles HTTPS, le client envoie une requête CONNECT pour créer un tunnel, puis la négociation TLS s’effectue à travers ce tunnel avec la destination. C’est le modèle le plus courant.
Proxy terminant le HTTPS : le proxy présente son propre certificat TLS et ré-encode le trafic vers l’amont. C’est fréquent dans les systèmes d’inspection d’entreprise et certaines API de scraping managées. Cela peut déclencher des erreurs de validation de certificat si le client ne fait pas confiance à la chaîne de certificats du proxy.
Proxy SOCKS5 : un tunnel TCP au niveau transport, compatible avec tout trafic TCP, pas seulement HTTP. Très utilisé par les fournisseurs de proxies résidentiels. Pris en charge nativement dans .NET 6+.
Exemple SOCKS5 :
var handler = new SocketsHttpHandler
{
Proxy = new WebProxy("socks5://proxy.example.com:1080")
{
Credentials = new NetworkCredential("proxy-user", "proxy-password")
},
UseProxy = true
};
using var client = new HttpClient(handler);
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine(ip);
À propos de la validation des certificats SSL
Quand vous utilisez des proxies terminant le HTTPS, vous pouvez voir des erreurs RemoteCertificateNameMismatch. Le ServerCertificateCustomValidationCallback permet de personnaliser la validation :
var handler = new HttpClientHandler
{
ServerCertificateCustomValidationCallback =
HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
};
N’utilisez ça qu’en développement local ou avec un proxy d’interception TLS de confiance et explicitement approuvé. Retourner true sans réfléchir désactive un contrôle de sécurité critique et vous expose à des attaques de type man-in-the-middle. En production, avec des proxies CONNECT ou SOCKS standards, laissez la validation SSL activée.
Dépannage des erreurs proxy courantes avec C# HttpClient
Ce tableau associe le symptôme visible à la cause probable et au premier correctif à essayer. Je vous conseille de l’ajouter à vos favoris : il couvre les erreurs les plus fréquentes dans les threads Stack Overflow et les forums de développeurs.
| Erreur / symptôme | Cause fréquente | Correctif |
|---|---|---|
| 407 Proxy Authentication Required | Identifiants définis sur handler.Credentials au lieu de handler.Proxy.Credentials; mauvais format de nom d’utilisateur; caractères spéciaux dans le mot de passe intégrés à l’URL | Utiliser WebProxy.Credentials = new NetworkCredential(...); éviter d’intégrer les identifiants dans l’URI; vérifier le format du nom d’utilisateur exigé par le fournisseur |
| TaskCanceledException / Timeout | Endpoint proxy lent, inaccessible, surchargé ou bloqué par un pare-feu ; délai d’attente par défaut de 100 s trop court | Tester le proxy avec curl; augmenter HttpClient.Timeout seulement après avoir confirmé que l’endpoint fonctionne ; ajouter des retries et des vérifications de santé du proxy |
| SocketException / saturation des sockets | Création et suppression de HttpClient ou de handlers à chaque requête | Utiliser IHttpClientFactory, des clients singleton, ou SocketsHttpHandler avec des contrôles de pooling |
| SSL RemoteCertificateNameMismatch | Interception HTTPS par un proxy d’entreprise ou managé | Installer/faire confiance à l’autorité de certification du proxy si nécessaire ; utiliser une validation personnalisée uniquement dans un environnement de dev contrôlé ou un scénario MITM approuvé |
| Boucle de redirection 302 | Page captive du proxy/VPN d’entreprise ou blocage de la liste autorisée provoquant des redirections en boucle | Tester la connexion directe ; inspecter les en-têtes Location ; vérifier l’allowlist du proxy et le portail d’authentification |
| HttpRequestException / aucune connexion avec une URL SOCKS | Code SOCKS exécuté sur .NET Framework ou un ancien .NET ; mauvais schéma ou mauvais port | Utiliser .NET 6+ pour la prise en charge native de SOCKS ; vérifier socks5://host:port ; tester avec la documentation du fournisseur |
| Le proxy semble ignoré | UseProxy = false; destination contournée car considérée comme locale ; variable d’environnement NO_PROXY ; handler configuré autrement que prévu | Définir UseProxy = true; inspecter HttpClient.DefaultProxy; effacer ou remplacer les variables d’environnement ; définir BypassProxyOnLocal = false |
Flux de débogage rapide
- La requête a-t-elle réussi ? → Oui : comparez la sortie de
api.ipify.orgavec l’IP attendue du proxy. - Non, y a-t-il un code HTTP ? → 407 : corrigez les identifiants du proxy. 403/429 : la cible bloque le proxy ou limite le débit. Boucle 3xx : le proxy ou la passerelle d’entreprise redirige peut-être.
- Non, pas de code HTTP, juste une exception ? → Timeout : testez l’accessibilité du proxy. Exception socket/certificat : vérifiez le pooling, le protocole, le TLS et la version .NET.
Commandes utiles pour valider le proxy en dehors de .NET :
curl -x http://user:pass@proxy.example.com:8080 https://api.ipify.org/
curl --socks5 user:pass@proxy.example.com:1080 https://api.ipify.org/
Si curl fonctionne mais pas votre code C#, la différence vient souvent du schéma d’authentification, du trust store TLS, des variables d’environnement ou de l’échappement des identifiants. Alignez exactement l’URL proxy, le schéma et l’authentification de curl, puis déplacez les identifiants dans NetworkCredential.
Quand se passer de la gestion des proxys : l’alternative no-code
Une bonne partie des développeurs qui cherchent “HttpClient proxy C#” n’essaie pas d’apprendre la théorie des proxys — elle essaie de faire tourner un scraper. Il est utile d’être franc sur les cas où le code C# personnalisé est le bon outil, et ceux où il ne l’est pas.
Construisez un scraper C# personnalisé avec rotation de proxy quand :
- vous avez besoin d’un contrôle total sur la logique de requête, les cookies, les en-têtes, les retries et le parsing
- le scraper s’intègre dans une base de code .NET existante ou un service interne
- des exigences de conformité ou de sécurité imposent de maîtriser l’infrastructure de bout en bout
Utilisez un outil no-code comme Thunderbit quand :
- l’objectif est l’extraction de données structurées depuis des sites, pas l’infrastructure HTTP
- vous préférez éviter de gérer des pools de proxys, des CAPTCHA ou la saturation des sockets
- l’équipe a besoin de données dans Excel, Google Sheets, Airtable ou Notion sans écrire de code de parsing
L’extension Chrome de Thunderbit gère automatiquement la rotation de proxy et les mécanismes anti-bot via son option de scraping cloud. Son API permet aux développeurs de définir un schéma JSON et d’obtenir des données structurées sans gérer HttpClient ni WebProxy. Pour les équipes qui font du web scraping pour comparer les prix ou de l’extraction de leads, le gain de temps à la mise en place est important.
| Scénario | C# personnalisé + proxy | Thunderbit |
|---|---|---|
| Contrôle total de la logique de requête | Oui | Non (contrôle au niveau API) |
| Gestion des proxys requise | Oui | Non (gérée automatiquement) |
| Gestion anti-bot / CAPTCHA | Manuelle ou tierce | Intégrée |
| Temps de mise en place | Quelques heures à quelques jours | Quelques minutes |
| Idéal pour | Bases .NET existantes, pipelines personnalisés | Extraction rapide, équipes non techniques, export vers tableurs |
Ce n’est pas un argument du style « n’utilisez jamais HttpClient ». Si vous construisez un service .NET de production, vous devez absolument comprendre la configuration des proxys. Mais si vous passez des heures à déboguer des erreurs 407 pour une collecte de données ponctuelle, il existe des options plus simples — et il n’y a aucune honte à les utiliser. Vous pouvez consulter les tarifs de Thunderbit ou la chaîne YouTube pour des démonstrations.
Points clés à retenir
Le schéma de base reste le même : WebProxy → handler → HttpClient. Tout le reste consiste à éviter les erreurs opérationnelles qui apparaissent en production.
- Les identifiants vont sur le proxy, pas sur le handler. L’exemple côte à côte dans la section 407 est ce qu’il faut retenir en priorité.
- Ne créez pas un nouveau
HttpClientpar requête ou par proxy. UtilisezIHttpClientFactorypour les clients nommés,SocketsHttpHandleravecPooledConnectionLifetimepour les passerelles rotatives, ou un handler de routage personnalisé pour les cas avancés. - Vérifiez votre version de .NET avant de copier du code SOCKS5 ou
SocketsHttpHandler. Le tableau de compatibilité ci-dessus vous évite des échecs silencieux. - Testez d’abord le proxy en dehors de .NET. Une simple commande
curlélimine toute une catégorie de débogage. - Pour l’extraction de données structurées sans les tracas liés aux proxys, des outils comme Thunderbit gèrent la couche transport pour que vous puissiez vous concentrer sur les données elles-mêmes.
La prochaine fois que vous tombez sur un 407 ou une TaskCanceledException, commencez par le tableau de dépannage ci-dessus.
FAQ
Puis-je changer le proxy d’une instance HttpClient existante ?
Non. Le proxy est lié au handler, et le handler est défini à la construction. HttpClient n’expose pas de propriété Proxy modifiable. Pour utiliser des proxys différents, créez des handlers et des clients séparés, puis gérez-les avec des clients nommés IHttpClientFactory ou un pool de clients préconfigurés.
HttpClient utilise-t-il le proxy système par défaut ?
Oui. Dans le .NET moderne, si vous ne définissez pas explicitement un handler, HttpClient hérite des paramètres de proxy par défaut du système — y compris les variables d’environnement comme HTTPS_PROXY et HTTP_PROXY via HttpClient.DefaultProxy. Pour l’ignorer, définissez explicitement UseProxy = false sur le handler.
Comment utiliser un proxy SOCKS5 avec HttpClient en C# ?
Utilisez new WebProxy("socks5://host:port") avec SocketsHttpHandler. La prise en charge native des proxys SOCKS requiert .NET 6 ou une version ultérieure. Sur .NET Framework 4.x, SOCKS5 n’est pas pris en charge nativement — il faut une bibliothèque tierce.
Pourquoi est-ce que je reçois sans cesse 407 Proxy Authentication Required ?
Le plus probable est que vous définissiez les identifiants sur handler.Credentials (qui cible le serveur de destination) au lieu de handler.Proxy.Credentials (qui cible le proxy). Voir la section « Identifiants du proxy vs identifiants du serveur » ci-dessus pour le bon schéma.
Est-il sûr de désactiver la validation des certificats SSL avec un proxy ?
Seulement en développement local ou lorsque vous faites entièrement confiance au fournisseur de proxy (par exemple une API de scraping managée en mode proxy HTTPS). En production avec des proxies CONNECT ou SOCKS standard, laissez la validation SSL activée pour éviter les attaques de type man-in-the-middle.
Essayez Thunderbit pour un web scraping sans effort Get Started Free
En savoir plus
