Hoe gebruik je een proxy met HttpClient in C#: patronen en oplossingen

Vorige week zat ik gênant lang naar een 407 Proxy Authentication Required-melding te staren, ervan overtuigd dat mijn proxyprovider kapot was. Bleek dat ik de inloggegevens op het verkeerde property had gezet — een oplossing van twee regels die me twee uur kostte om te vinden. Klinkt dat bekend? Dan is deze gids voor jou.

Proxyconfiguratie met HttpClient in C# is zo’n onderwerp waarbij het basispatroon simpel lijkt, maar de valkuilen in productie — socket exhaustion, SOCKS5-versieverschillen, verwarring over credentials — je in de praktijk veel tijd kosten.

Bij Thunderbit werk ik al een tijdje aan tools voor webscraping en data-extractie, en ik zie deze fouten steeds weer terugkomen, zowel in onze technische discussies als in de developersgemeenschappen die we volgen. Deze walkthrough behandelt het hele traject: setup, authenticatie, proxy-rotatie, protocolkeuze en een troubleshooting-tabel waarvan ik echt had gewild dat die er was toen ik begon.

Moeilijkheidsgraad: Beginner tot gemiddeld
Benodigde tijd: ongeveer 15 minuten om mee te volgen, langer voor rotatiepatronen in productie
Wat je nodig hebt: .NET 6+ SDK (voor SOCKS5 en moderne handler-functies; .NET Framework 4.x werkt voor basisvoorbeelden met HTTP-proxy), een code-editor en ten minste één proxy-endpoint om mee te testen

Wat is HttpClient en waarom heeft het een proxy nodig?

HttpClient is de ingebouwde .NET-klasse in System.Net.Http voor het versturen van HTTP-verzoeken en het ontvangen van responses. De klasse ondersteunt async/await, custom headers, cancellation tokens en configuratie via handlers. Microsoft beschrijft het als een klasse voor het versturen van HTTP-verzoeken en het ontvangen van HTTP-responses van een resource die wordt geïdentificeerd door een URI.

Een proxyserver is een tussenlaag tussen je applicatie en de doelwebsite. Als je verkeer via een proxy routeert, ziet de doelserver het IP-adres van de proxy in plaats van jouw eigen IP.

HttpClient zelf heeft geen Proxy-property. Proxy-routing configureer je op de onderliggende handler — of dat nu HttpClientHandler of SocketsHttpHandler is — en die accepteert een WebProxy-instantie. Het mentale model ziet er zo uit:

[Je C#-app] → [HttpClient + Handler] → [Proxyserver] → [Doelwebsite]

Daarom is “de proxy wijzigen op een live HttpClient” een ontwerpvraagstuk, geen simpele property-toekenning. Meer daarover in het gedeelte over rotatie.

Probeer Thunderbit voor eenvoudigere data-extractie

Waarom een proxy gebruiken met HttpClient in C#

Ontwikkelaars sturen HttpClient-verkeer om een aantal terugkerende redenen via proxies, en het juiste proxytype hangt af van de taak.

IP-blokkades en rate limits vermijden: Essentieel voor webscraping, leadgeneratie of prijsmonitoring op schaal. Een enkel IP dat een site maar blijft bestoken, wordt snel geblokkeerd.
Geo-beperkingen omzeilen: Krijg toegang tot regio-gebonden API’s of content door via proxies in specifieke landen te routeren.
Je bron-IP verbergen: Voeg een extra privacylaag toe voor gevoelige data-collectie of competitief onderzoek.
Bedrijfs- of compliance-eisen: Veel organisaties eisen dat uitgaand verkeer via een centrale gateway loopt voor logging en governance.
Testen en QA: Simuleer requests uit verschillende locaties of netwerkcondities zonder infrastructuur fysiek in die regio’s uit te rollen.

Gebruikssituatie	Typische proxykeuze	Waarom dit past
Webscraping op schaal	Roterende residential proxies	Meer IP-diversiteit, moeilijker te classificeren door anti-bot systemen
Prijsmonitoring voor e-commerce	Residential of geo-gerichte datacenterproxy	Regionale prijs- en voorraadcontroles
API-toegang via een vaste gateway	Datacenterproxy of bedrijfsproxy	Voorspelbare IP-allowlisting, lagere kosten
Enterprise compliance	Systeemproxy, PAC-proxy, geauthenticeerde bedrijfsproxy	Gecentraliseerde logging en uitgaande controle
QA- en lokalisatietesten	Land-specifieke proxy pool	Simuleert echte gebruikersuitvoer vanuit doelregio’s

Proxygebruik schaalt meestal in duidelijke fases. Je begint met één statische proxy om de routing te bevestigen. Een production scraper gaat over op een pool, waarbij requests worden gemapt naar proxies op basis van doel-domein, geografie of foutpercentage. Volwassen teams stappen vaak over op een beheerde proxygateway, waarbij rotatie, retries en session affinity achter één endpoint worden afgehandeld.

Proxy-rotatie is geen wondermiddel. Als een target verdacht gedrag blokkeert, helpt rotatie van IP’s alleen echt als requestfrequentie, headers, cookies en TLS-fingerprinting ook zorgvuldig worden behandeld.

Welke .NET-versie ondersteunt wat: een snelle compatibiliteitsmatrix

Een proxy-snippet uit een blogpost in het verkeerde target framework plakken is een grote bron van stille fouten. De belangrijkste scheidslijn is .NET Framework 4.x versus moderne .NET (.NET 6+). Dit werkt waar:

.net-version-comparison.webp

Mogelijkheid	.NET Framework 4.x	.NET 6	.NET 7	.NET 8–9
`WebProxy` + `HttpClientHandler`	Ja	Ja	Ja	Ja
SOCKS5 via `WebProxy("socks5://...")`	Nee	Ja (toegevoegd in .NET 6)	Ja	Ja
`SocketsHttpHandler` (standaard handler)	Nee	Ja	Ja	Ja
`HttpClient.DefaultProxy` statisch	Nee	Ja	Ja	Ja
`PooledConnectionLifetime`	Nee	Ja	Ja	Ja

Als je op .NET Framework 4.x mikt, blijf dan bij HTTP/HTTPS-proxies met HttpClientHandler en WebProxy. SOCKS5 en moderne pooling-control vereisen .NET 6 of hoger.

Een subtiel gedragspunt: HttpClient.DefaultProxy is in moderne .NET een statische property. Als die wordt gezet in gedeelde startup-code of wordt geërfd van omgevingsvariabelen zoals HTTPS_PROXY of HTTP_PROXY, pakt elke HttpClient-instantie die op, tenzij je de handler expliciet overschrijft. In containerized deployments is dit een veelvoorkomende oorzaak van verwarring: “waarom gebruikt mijn client een proxy die ik nooit heb ingesteld?”

Stap 1: Maak een nieuw C# consoleproject aan

Open een terminal en zet een nieuw project op:

dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo

Controleer je SDK-versie met dotnet --version. De voorbeelden in deze gids richten zich op .NET 6+ voor volledige functionaliteit. Als je de nieuwste LTS SDK nodig hebt, haal die dan via de downloadpagina van Microsoft.

Open Program.cs in je editor. Daar gebeurt alles.

Stap 2: Maak een basis HTTP-request zonder proxy

Voordat je een proxy instelt, moet je je echte uitgaande IP vaststellen. Zo kun je, zodra de proxy actief is, controleren of het IP daadwerkelijk is veranderd.

using System.Net.Http;

using var client = new HttpClient();
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Direct IP: {ip}");

Voer het uit. Je zou je huidige publieke IP-adres moeten zien, bijvoorbeeld:

Direct IP: 203.0.113.10

Onthoud die waarde. Na de volgende stap moet die anders zijn.

Stap 3: Configureer een WebProxy met HttpClientHandler

Het klassieke patroon bestaat uit drie objecten: een WebProxy, een handler en de 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}");

Vervang proxy.example.com:8080 door je eigen proxy-endpoint. Als alles goed is geconfigureerd, moet het output-IP nu overeenkomen met het exit-IP van je proxy — niet met je echte IP.

Belangrijke properties om te begrijpen:

Proxy — de IWebProxy-instantie die de handler gebruikt voor routing.
UseProxy = true — vertelt de handler om de ingestelde proxy daadwerkelijk te gebruiken. (Klinkt logisch, maar het vergeten hiervan kost in de praktijk veel debugtijd.)
BypassProxyOnLocal = false — zorgt ervoor dat de handler de proxy niet overslaat voor bestemmingen die als “lokaal” worden gezien.
UseDefaultCredentials — bepaalt of de handler Windows-defaultcredentials meestuurt. Dit is niet hetzelfde als een proxygebruikersnaam en -wachtwoord.

Stap 4: Voeg proxy-authenticatie toe met NetworkCredential

De meeste betaalde proxyproviders vereisen credentials. Het juiste patroon is om die op het WebProxy-object zelf te zetten:

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

Veel providers geven een URL-formaat zoals http://username:password@host:port. Voor .NET-code is NetworkCredential meestal beter dan credentials in de URI-string zetten. Daarmee voorkom je problemen met speciale tekens in wachtwoorden en houd je het onderscheid tussen URI en credentials expliciet.

Ik behandel de meest voorkomende authenticatiefout — en waarom die 407-fouten veroorzaakt — in een apart gedeelte hieronder.

Stap 5: Gebruik of exporteer de responsdata

Voor alles wat verder gaat dan een snelle IP-check, moet je de response netjes verwerken:

using var response = await client.GetAsync("https://example.com/api/products");

if (!response.IsSuccessStatusCode)
{
    Console.WriteLine($"Request mislukt: {(int)response.StatusCode} {response.ReasonPhrase}");
    return;
}

var body = await response.Content.ReadAsStringAsync();
Console.WriteLine(body);

Voor scraping-workflows is de proxied request alleen de transportlaag. Je hebt nog steeds parsing, normalisatie, deduplicatie, retries en export naar Excel, Google Sheets, databases of andere bestemmingen nodig. Tools zoals Thunderbit kunnen de extractie- en exportstappen automatiseren — de Chrome-extensie verwerkt gestructureerde data-extractie en gratis exports naar Google Sheets, Excel, Airtable of Notion, zonder dat je parsingcode hoeft te schrijven.

Exporteer gescrapete data naar Excel, Sheets, Airtable of Notion Get Started Free

Proxy-credentials versus server-credentials: de fout die 407-fouten veroorzaakt

Ik heb deze fout gezien in Stack Overflow-threads, Microsoft Q&A-posts en — eerlijk is eerlijk — in mijn eigen code.

Het onderscheid is simpel, maar makkelijk te verwarren:

Proxy-credentials authenticeren je bij de proxyserver zelf.
Server-credentials authenticeren je bij de doelserver.

In HttpClientHandler zitten die op verschillende properties. Credentials op de verkeerde plek zetten is de nummer 1 oorzaak van 407 Proxy Authentication Required-fouten.

// ❌ FOUT — zet credentials voor de doelserver, niet voor de proxy
handler.Credentials = new NetworkCredential("user", "pass");

// ✅ GOED — zet credentials op het proxy-object zelf
handler.Proxy = new WebProxy("http://proxy:8080")
{
    Credentials = new NetworkCredential("user", "pass")
};

HttpClientHandler.Credentials is voor de doelserver. WebProxy.Credentials is voor de proxy. Krijg je een 407 terug, dan horen je credentials op de proxy.

Nog een valkuil: HttpClientHandler.PreAuthenticate stuurt gedrag aan voor authenticatie bij de doelserver. Het regelt niet de Proxy-Authorization-header. Gebruik dit dus niet als oplossing voor 407.

Hoe roteer je proxies met HttpClient in C#

Ontwikkelaars vragen dit voortdurend in forums. Het antwoord is in eerste instantie teleurstellend: je kunt de proxy van een live HttpClient-instantie niet wijzigen. De proxy zit op de handler. De handler wordt ingesteld bij het aanmaken. HttpClient biedt geen veranderbare Proxy-property.

De naïeve workaround — voor elk request new HttpClient(new HttpClientHandler { Proxy = ... }) maken — creëert een ander probleem. Microsoft waarschuwt expliciet dat clients per request aanmaken en direct weggooien TCP-poorten kan uitputten, omdat poorten niet meteen vrijkomen na het sluiten van de verbinding.

Hier zijn dus drie productieklare patronen die echt werken.

Optie 1: Named clients via IHttpClientFactory

Als je proxyset al bij startup bekend is, zijn named clients de eenvoudigste optie. Elke named client krijgt zijn eigen handlerconfiguratie en je applicatie kiest op runtime op naam.

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

// Tijdens een request:
var client = httpClientFactory.CreateClient("proxy-us");

De factory beheert de levensduur van handlers en voorkomt het anti-patroon van een client per request.

Optie 2: SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)

Voor een langdurig draaiende client achter een proxygateway die exit-IP’s roteert op nieuwe verbindingen, dwingt PooledConnectionLifetime af dat verbindingen na een ingestelde tijd opnieuw worden aangemaakt.

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

Dit verandert niet magisch het Proxy-object per request. Het werkt vooral goed met proxygateways die bij elke nieuwe TCP-verbinding een ander exit-IP toewijzen, of met DNS-gestuurde proxy pools waarbij de hostname in de tijd naar andere endpoints resolveert.

Optie 3: Custom DelegatingHandler voor geavanceerde proxyselectie

Wanneer proxyselectie afhangt van de request-URL, payload of runtime-context, kan een custom routing handler elk request inspecteren en doorsturen naar de juiste inner handler pipeline.

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

Dit is een geavanceerde aanpak. Thread safety, disposal, hergebruik van handlers, retry-gedrag en logging worden dan jouw verantwoordelijkheid. Ik zou dit alleen aanraden als de eerste twee opties echt niet passen.

De drie aanpakken vergeleken

Aanpak	Complexiteit	.NET-versie	Thread safety	Overhead
Named clients (IHttpClientFactory)	Laag	.NET Core 2.1+	Hoog (immutabele configuratie)	Laag
SocketsHttpHandler + PooledConnectionLifetime	Gemiddeld	.NET 6+	Hoog	Laag
Custom DelegatingHandler	Hoog	Elke	Hangt af van implementatie	Gemiddeld

Voor de meeste teams zijn named clients het beste startpunt. Stap over op PooledConnectionLifetime voor stabiele roterende gateways, en gebruik custom routing alleen wanneer de proxykeuze afhangt van metadata op requestniveau.

Kies het juiste proxyprotocol: HTTP, HTTPS en SOCKS5

Niet alle proxies spreken dezelfde taal, en als je het verkeerde protocol of schema gebruikt, krijg je verwarrende fouten.

HTTP-proxy: Begrijpt HTTP-verzoeken. Voor gewone HTTP-targets kan hij requests direct doorsturen. Voor HTTPS-targets stuurt de client een CONNECT-request om een tunnel op te zetten, waarna TLS via die tunnel met de doelserver wordt onderhandeld. Dit is het meest gangbare model.

HTTPS-terminerende proxy: De proxy presenteert zijn eigen TLS-certificaat en versleutelt upstream-verkeer opnieuw. Dit zie je vaak in enterprise-inspectiesystemen en sommige beheerde scraping-API’s. Dit kan certificaatvalidatiefouten veroorzaken als de client de certificaatketen van de proxy niet vertrouwt.

SOCKS5-proxy: Een TCP-tunnel op transportlaag die werkt voor alle TCP-verkeer, niet alleen HTTP. Veel gebruikt door providers van residential proxies. Natief ondersteund in .NET 6+.

SOCKS5-voorbeeld:

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

Een opmerking over SSL-certificaatvalidatie

Bij HTTPS-terminerende proxies kun je RemoteCertificateNameMismatch-fouten zien. De ServerCertificateCustomValidationCallback kan de validatie aanpassen:

var handler = new HttpClientHandler
{
    ServerCertificateCustomValidationCallback =
        HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
};

Gebruik dit alleen in lokale ontwikkeling of met een vertrouwde, goedgekeurde TLS-interceptieproxy. Blind true teruggeven schakelt een kritieke beveiligingscontrole uit en maakt je vatbaar voor man-in-the-middle-aanvallen. In productie, met standaard CONNECT- of SOCKS-proxies, moet SSL-validatie gewoon aan blijven.

Veelvoorkomende proxyfouten in C# HttpClient oplossen

Deze tabel koppelt het zichtbare symptoom aan de waarschijnlijke oorzaak en de eerste fix die je moet proberen. Bookmark dit gedeelte gerust — het behandelt de fouten die het vaakst opduiken in Stack Overflow-threads en developersforums.

Fout / symptoom	Veelvoorkomende oorzaak	Oplossing
407 Proxy Authentication Required	Credentials gezet op `handler.Credentials` in plaats van `handler.Proxy.Credentials`; verkeerd gebruikersnaamformaat; speciale tekens in een wachtwoord dat in de URL is ingebed	Gebruik `WebProxy.Credentials = new NetworkCredential(...)`; stop credentials niet in de URI; controleer het gebruikersnaamformaat van de provider
TaskCanceledException / Timeout	Proxy-endpoint is traag, onbereikbaar, overbelast of door firewall geblokkeerd; standaard timeout van 100s is te kort	Test de proxy met `curl`; verhoog `HttpClient.Timeout` pas nadat je hebt bewezen dat het endpoint werkt; voeg retries en health checks toe
SocketException / Socket exhaustion	`HttpClient` of handlers per request aanmaken en weggooien	Gebruik `IHttpClientFactory`, singleton clients of `SocketsHttpHandler` met pooling controls
SSL RemoteCertificateNameMismatch	HTTPS-interceptie door corporate of beheerde proxy	Installeer/vertrouw de proxy-CA waar passend; gebruik custom validation alleen in gecontroleerde dev- of goedgekeurde MITM-scenario’s
302 Redirect loop	Captive portal of allowlist-blokkade van een bedrijfsproxy/VPN die blijft omleiden	Test een directe verbinding; inspecteer `Location`-headers; controleer allowlist en authenticatieportal van de proxy
HttpRequestException / Geen verbinding met SOCKS-URL	SOCKS-code draaien op .NET Framework of oudere .NET; verkeerd schema of verkeerde poort	Gebruik .NET 6+ voor native SOCKS-ondersteuning; controleer `socks5://host:port`; test met documentatie van de provider
Proxy lijkt genegeerd te worden	`UseProxy = false`; target wordt als lokaal overgeslagen; `NO_PROXY`-omgevingsvariabele; handler anders geconfigureerd dan verwacht	Zet `UseProxy = true`; inspecteer `HttpClient.DefaultProxy`; wis of overschrijf omgevingsvariabelen; zet `BypassProxyOnLocal = false`

Snelle debugflow

Is het request gelukt? → Ja: vergelijk de output van api.ipify.org met het verwachte proxy-IP.
Nee, er is een HTTP-statuscode? → 407: los proxycredentials op. 403/429: de target blokkeert of rate-limited de proxy. 3xx-loop: de proxy of corporate gateway kan aan het omleiden zijn.
Geen statuscode, alleen een exception? → Timeout: test de bereikbaarheid van de proxy. Socket- of certificaat-exception: controleer pooling, protocol, TLS en de .NET-versie.

Handige eerste commando’s om de proxy zelf buiten .NET te valideren:

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/

Als curl werkt maar je C#-code niet, zit het verschil meestal in het auth-schema, de TLS trust store, omgevingsvariabelen of het escapen van credentials. Laat curl’s proxy-URL, schema en authenticatie exact overeenkomen en zet de credentials daarna om naar NetworkCredential.

Wanneer proxybeheer overslaan: het no-code alternatief

Een flink deel van de developers die zoeken op “HttpClient proxy C#” wil niet per se proxytheorie leren — ze willen gewoon een scraper draaien. Het is de moeite waard om eerlijk te zijn over wanneer custom C# proxycode het juiste gereedschap is en wanneer niet.

Bouw een custom C# scraper met proxy-rotatie wanneer:

Je volledige controle nodig hebt over requestlogica, cookies, headers, retries en parsing
De scraper moet integreren in een bestaande .NET-codebase of interne service
Compliance- of security-eisen vereisen dat je de infrastructuur end-to-end zelf beheert

Gebruik een no-code tool zoals Thunderbit wanneer:

Het doel gestructureerde data-extractie van websites is, niet HTTP-infrastructuur
Je liever geen proxy pools onderhoudt, CAPTCHAs afhandelt of socket exhaustion debugt
Het team data nodig heeft in Excel, Google Sheets, Airtable of Notion zonder parsingcode te schrijven

De Chrome-extensie van Thunderbit regelt proxy-rotatie en anti-botmaatregelen automatisch via de cloud scraping-optie. Met de API kunnen developers een JSON-schema definiëren en gestructureerde data terugkrijgen zonder HttpClient of WebProxy te hoeven beheren. Voor teams die webscraping voor prijsvergelijking of leadextractie doen, is het verschil in opstarttijd aanzienlijk.

Scenario	Custom C# + Proxy	Thunderbit
Volledige controle over requestlogica	Ja	Nee (alleen API-niveau controle)
Proxybeheer vereist	Ja	Nee (automatisch geregeld)
Anti-bot / CAPTCHA-afhandeling	Handmatig of via derde partij	Ingebouwd
Setup-tijd	Uren tot dagen	Minuten
Beste voor	Bestaande .NET-codebases, custom pipelines	Snelle data-extractie, niet-technische teams, spreadsheet-export

Dit is geen pleidooi om HttpClient nooit te gebruiken. Als je een productie-.NET-service bouwt, moet je proxyconfiguratie absoluut begrijpen. Maar als je uren kwijt bent aan het debuggen van 407-fouten voor een eenmalige datacollectieklus, zijn er simpelere opties — en daar is niets mis mee. Je kunt de prijzen van Thunderbit bekijken of het YouTube-kanaal raadplegen voor walkthroughs.

Belangrijkste inzichten

Het kernpatroon blijft hetzelfde: WebProxy → handler → HttpClient. Alles daarna draait om het vermijden van operationele fouten die in productie opduiken.

Credentials horen op de proxy, niet op de handler. Het snippet naast elkaar in het 407-gedeelte is het belangrijkste om te onthouden.
Maak niet per request of per proxy een nieuwe HttpClient. Gebruik IHttpClientFactory voor named clients, SocketsHttpHandler met PooledConnectionLifetime voor roterende gateways, of een custom routing handler voor geavanceerde scenario’s.
Controleer je .NET-versie voordat je SOCKS5- of SocketsHttpHandler-code kopieert. De compatibiliteitsmatrix hierboven voorkomt stille fouten.
Test de proxy eerst buiten .NET. Een snel curl-commando haalt al een hele categorie debugging weg.
Voor gestructureerde data-extractie zonder proxygedoe regelen tools zoals Thunderbit de transportlaag, zodat jij je kunt richten op de data zelf.

De volgende keer dat je tegen een 407 of een TaskCanceledException aanloopt, begin dan met de troubleshooting-tabel hierboven.

FAQ's

Kan ik de proxy op een bestaande HttpClient-instantie wijzigen?

Nee. De proxy is gekoppeld aan de handler, en de handler wordt ingesteld bij het aanmaken. HttpClient heeft geen mutabele Proxy-property. Voor verschillende proxies maak je aparte handlers en clients aan, en beheer je die met IHttpClientFactory named clients of een pool van vooraf geconfigureerde clients.

Gebruikt HttpClient standaard de systeemproxy?

Ja. In moderne .NET erft HttpClient de standaard proxy-instellingen van het systeem als je niet expliciet een handler instelt — inclusief omgevingsvariabelen zoals HTTPS_PROXY en HTTP_PROXY via HttpClient.DefaultProxy. Om dit uit te schakelen, zet je expliciet UseProxy = false op de handler.

Hoe gebruik ik een SOCKS5-proxy met HttpClient in C#?

Gebruik new WebProxy("socks5://host:port") met SocketsHttpHandler. Native SOCKS-ondersteuning vereist .NET 6 of later. Op .NET Framework 4.x wordt SOCKS5 niet native ondersteund — daarvoor heb je een third-party library nodig.

Waarom krijg ik steeds 407 Proxy Authentication Required?

Waarschijnlijk zet je credentials op handler.Credentials (voor de doelserver) in plaats van op handler.Proxy.Credentials (voor de proxy). Zie hierboven het gedeelte “Proxy-credentials versus server-credentials” voor het juiste patroon.

Is het veilig om SSL-certificaatvalidatie uit te schakelen wanneer ik een proxy gebruik?

Alleen in lokale ontwikkeling of wanneer je de proxyprovider volledig vertrouwt (bijvoorbeeld een beheerde scraping-API in HTTPS-proxymodus). In productie met standaard CONNECT- of SOCKS-proxies moet SSL-validatie aan blijven om man-in-the-middle-aanvallen te voorkomen.

Probeer Thunderbit voor moeiteloos webscrapen Get Started Free

Meer lezen

Data extraheren met AI

Gegevens eenvoudig overzetten naar Google Sheets, Airtable of Notion

Chrome Store Rating

PRODUCT HUNT#1 Product of the Week