Sådan bruger du en proxy med HttpClient i C#: mønstre og løsninger

Sidste uge brugte jeg pinligt lang tid på at stirre på et 407 Proxy Authentication Required-svar, overbevist om at min proxy-leverandør var defekt. Det viste sig, at jeg havde sat legitimationsoplysninger på det forkerte property — en to-linjers rettelse, som tog mig to timer at finde. Hvis det lyder bekendt, er denne guide til dig.

Proxykonfiguration med HttpClient i C# er et af de emner, hvor grundmønsteret er ret ligetil, men faldgruberne i produktion — socket exhaustion, SOCKS5-versioner der ikke matcher, forvirring omkring credentials — kan koste dyrbar tid.

Jeg har arbejdet med web scraping og dataudtræk hos Thunderbit i et stykke tid nu, og jeg har set de samme fejl dukke op igen og igen, både i vores egne tekniske diskussioner og i de udviklerfællesskaber, vi følger. Denne gennemgang dækker hele forløbet: opsætning, autentificering, proxy-rotation, protokolvervalg og en fejlfindingstabel, som jeg virkelig ville ønske fandtes den dag, jeg begyndte.

Sværhedsgrad: Begynder til øvet
Tidsforbrug: ~15 minutter at følge med, længere hvis du vil bygge produktionsklar rotation
Det skal du bruge: .NET 6+ SDK (til SOCKS5 og moderne handler-funktioner; .NET Framework 4.x virker til grundlæggende HTTP-proxy-eksempler), en kodeeditor og mindst ét proxy-endpoint at teste med

Hvad er HttpClient, og hvorfor har det brug for en proxy?

HttpClient er den indbyggede .NET-klasse i System.Net.Http til at sende HTTP-anmodninger og modtage svar. Den understøtter async/await, brugerdefinerede headers, cancellation tokens og konfiguration via handlers. Microsoft beskriver den som en klasse til at sende HTTP-anmodninger og modtage HTTP-svar fra en ressource identificeret ved en URI.

En proxyserver er et mellemled mellem din applikation og det målwebsted, du vil kontakte. Når du sender trafikken gennem en proxy, ser målserveren proxyens IP-adresse i stedet for din egen.

HttpClient har ikke selv et Proxy-property. Proxy-routing konfigureres på den underliggende handler — enten HttpClientHandler eller SocketsHttpHandler — som accepterer en WebProxy-instans. Det mentale billede ser sådan ud:

[Din C#-app] → [HttpClient + handler] → [Proxyserver] → [Målwebsted]

Derfor er “skift proxy på en levende HttpClient” et designproblem og ikke bare en simpel property-ændring. Mere om det i rotationsafsnittet.

Prøv Thunderbit for nemmere dataudtræk

Hvorfor bruge en proxy med HttpClient i C#

Udviklere sender HttpClient-trafik gennem proxies af en række tilbagevendende grunde, og den rigtige proxytype afhænger af opgaven.

Undgå IP-blokeringer og rate limits: Nødvendigt til web scraping, leadgenerering eller prisovervågning i stor skala. En enkelt IP, der banker løs på et site, bliver hurtigt blokeret.
Omgå geografiske begrænsninger: Få adgang til API’er eller indhold, der er låst til bestemte regioner, ved at route via proxies i udvalgte lande.
Skjul din oprindelige IP: Tilføj et lag privatliv ved følsom dataindsamling eller konkurrentanalyse.
Krav fra virksomhed eller compliance: Mange virksomheder kræver, at udgående trafik passerer gennem en central gateway for logning og kontrol.
Test og QA: Simulér anmodninger fra forskellige lokationer eller netværksforhold uden fysisk at rulle infrastruktur ud i de regioner.

Anvendelse	Typisk proxyvalg	Hvorfor det passer
Web scraping i stor skala	Rotérende residential proxies	Større IP-variation, sværere for anti-bot-systemer at identificere
Overvågning af e-handelspriser	Residential eller geo-targeted datacenter proxy	Region-specifik prissætning og lagerkontrol
API-adgang via fast gateway	Datacenter-proxy eller virksomhedsproxy	Forudsigelig IP-allowlisting, lavere pris
Virksomhedscompliance	Systemproxy, PAC-proxy, autentificeret virksomhedsproxy	Centraliseret logning og styring af udgående trafik
QA og lokaliserings-test	Landespecifikt proxy-pool	Simulerer reel brugeradgang fra målregionen

Proxybrug skalerer også i ret forudsigelige trin. Du starter med en enkelt statisk proxy for at bekræfte routing. En produktionsscraper går videre til en pulje, hvor anmodninger mappes til proxies efter domæne, geografi eller fejlfrekvens. Mere modne teams skifter ofte til en administreret proxy-gateway, hvor rotation, retries og session affinity håndteres bag ét endpoint.

Proxy-rotation er ikke en mirakelkur. Hvis et målwebsted blokerer mistænkelig adfærd, hjælper roterende IP’er kun, hvis anmodningsfrekvens, headers, cookies og TLS-fingeraftryk også håndteres omhyggeligt.

Hvilken .NET-version understøtter hvad: et hurtigt kompatibilitets-overblik

At kopiere et proxy-eksempel fra et blogindlæg ind i den forkerte target framework-version er en stor kilde til tavse fejl. Den vigtigste skillelinje er .NET Framework 4.x versus moderne .NET (.NET 6+). Her er, hvad der virker hvor:

.net-version-comparison.webp

Funktion	.NET Framework 4.x	.NET 6	.NET 7	.NET 8–9
`WebProxy` + `HttpClientHandler`	Ja	Ja	Ja	Ja
SOCKS5 via `WebProxy("socks5://...")`	Nej	Ja (tilføjet i .NET 6)	Ja	Ja
`SocketsHttpHandler` (standard handler)	Nej	Ja	Ja	Ja
Statisk `HttpClient.DefaultProxy`	Nej	Ja	Ja	Ja
`PooledConnectionLifetime`	Nej	Ja	Ja	Ja

Hvis du målretter .NET Framework 4.x, så hold dig til HTTP/HTTPS-proxies med HttpClientHandler og WebProxy. SOCKS5 og moderne pooling-kontrol kræver .NET 6 eller nyere.

En subtil adfærd, du skal være opmærksom på: HttpClient.DefaultProxy er et statisk property i moderne .NET. Hvis det sættes i delt startup-kode eller arves fra miljøvariabler som HTTPS_PROXY eller HTTP_PROXY, vil alle HttpClient-instanser bruge det, medmindre du eksplicit overskriver handleren. I containeriserede miljøer er det en meget almindelig årsag til forvirringen: “Hvorfor bruger min klient en proxy, jeg aldrig har konfigureret?”

Trin 1: Opret et nyt C#-konsolprojekt

Åbn en terminal, og opret et nyt projekt:

dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo

Tjek din SDK-version med dotnet --version. Eksemplerne i denne guide er målrettet .NET 6+ for fuld funktionalitet. Hvis du har brug for den nyeste LTS-SDK, kan du hente den fra Microsofts downloadside.

Åbn Program.cs i din editor. Det er her, det hele sker.

Trin 2: Lav en baseline HTTP-anmodning (uden proxy)

Før du sætter en proxy op, skal du kende din rigtige udgående IP. På den måde kan du bagefter bekræfte, at IP’en faktisk ændrer sig, når proxyen slås til.

using System.Net.Http;

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

Kør det. Du bør se din nuværende offentlige IP-adresse, noget i stil med:

Direkte IP: 203.0.113.10

Husk den værdi. Efter næste trin burde den være anderledes.

Trin 3: Konfigurer en WebProxy med HttpClientHandler

Det klassiske mønster består af tre objekter: en WebProxy, en handler og klienten.

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

Erstat proxy.example.com:8080 med dit faktiske proxy-endpoint. Hvis alt er koblet korrekt sammen, bør output-IP’en nu matche proxyens exit-IP — ikke din egen.

Vigtige properties at forstå:

Proxy — den IWebProxy-instans, som handleren bruger til routing.
UseProxy = true — fortæller handleren, at den faktisk skal bruge den konfigurerede proxy. (Det lyder oplagt, men at glemme dette er en reel tidsrøver i fejlsøgning.)
BypassProxyOnLocal = false — forhindrer handleren i at springe proxyen over for destinationer, der ser “lokale” ud.
UseDefaultCredentials — styrer, om handleren sender Windows’ standardcredentials. Det er ikke det samme som proxy-brugernavn og password.

Trin 4: Tilføj proxy-autentificering med NetworkCredential

De fleste betalte proxy-leverandører kræver credentials. Det korrekte mønster er at sætte dem på selve WebProxy-objektet:

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($"Autentificeret proxy-IP: {ip}");

Mange leverandører giver en URL som http://username:password@host:port. I .NET-kode bør du dog foretrække NetworkCredential frem for at indlejre credentials direkte i URI-strengen. Det undgår problemer med escaping af specialtegn i adgangskoder og gør skellet mellem URI og credentials tydeligt.

Jeg gennemgår den mest almindelige autentificeringsfejl — og hvorfor den giver 407-fejl — i et særskilt afsnit nedenfor.

Trin 5: Brug eller eksportér responsdataene

Til alt andet end et hurtigt IP-tjek bør du håndtere svaret ordentligt:

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

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

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

For scraping-workflows er den proxiede anmodning kun transportlaget. Du skal stadig have parsing, normalisering, deduplikering, retries og eksport til Excel, Google Sheets, databaser eller andre destinationer. Værktøjer som Thunderbit kan automatisere både udtræk og eksport — dens Chrome-udvidelse håndterer struktureret dataudtræk og gratis eksport til Google Sheets, Excel, Airtable eller Notion uden at du behøver skrive parsingkode.

Eksportér scrappede data til Excel, Sheets, Airtable eller Notion Get Started Free

Proxy-legitimationsoplysninger vs. server-legitimationsoplysninger: fejlen der giver 407-fejl

Jeg har set denne fejl i Stack Overflow-tråde, Microsoft Q&A-indlæg og — ærligt talt — i min egen kode.

Skellet er simpelt, men let at forveksle:

Proxy-legitimationsoplysninger autentificerer dig over for selve proxyserveren.
Server-legitimationsoplysninger autentificerer dig over for destinationen/målserveren.

I HttpClientHandler ligger de på forskellige properties. At sætte credentials det forkerte sted er den største årsag til 407 Proxy Authentication Required-fejl.

// ❌ FORKERT — sætter credentials til destinationen, ikke til proxyen
handler.Credentials = new NetworkCredential("user", "pass");

// ✅ KORREKT — sætter credentials på selve proxy-objektet
handler.Proxy = new WebProxy("http://proxy:8080")
{
    Credentials = new NetworkCredential("user", "pass")
};

HttpClientHandler.Credentials gælder destinationen. WebProxy.Credentials gælder proxyen. Hvis proxyen returnerer 407, skal dine credentials ligge på proxyen.

En anden fælde: HttpClientHandler.PreAuthenticate styrer pre-authentication for autentificering mod målserveren. Den styrer ikke Proxy-Authorization-headeren. Brug den ikke som løsning på 407.

Sådan roterer du proxies med HttpClient i C#

Udviklere spørger konstant om dette i fora. Svaret er i starten lidt skuffende: du kan ikke ændre proxyen på en kørende HttpClient-instans. Proxyen ligger på handleren. Handleren sættes ved konstruktion. HttpClient har intet mutabelt Proxy-property.

Den naive løsning — new HttpClient(new HttpClientHandler { Proxy = ... }) for hver anmodning — skaber et andet problem. Microsoft advarer direkte om, at det at oprette og dispose klienter pr. request kan udtømme ledige TCP-porte, fordi portene ikke frigives øjeblikkeligt efter, at forbindelsen er lukket.

Her er derfor tre produktionsvenlige mønstre, der faktisk virker.

Mulighed 1: Navngivne klienter via IHttpClientFactory

Hvis dit proxysæt er kendt ved opstart, er navngivne klienter den løsning med lavest kompleksitet. Hver navngiven klient får sin egen handler-konfiguration, og applikationskoden slår op efter navn ved runtime.

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

// Når anmodningen skal sendes:
var client = httpClientFactory.CreateClient("proxy-us");

Factory’en styrer handler-livscyklus og undgår anti-patternet med en ny klient pr. request.

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

For en langlivet klient bag en proxy-gateway, der roterer exit-IP’er på nye forbindelser, tvinger PooledConnectionLifetime forbindelser til at blive genskabt efter en konfigureret periode.

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

Det ændrer ikke magisk Proxy-objektet pr. request. Det fungerer bedst sammen med proxy-gateways, der tildeler en ny exit-IP for hver ny TCP-forbindelse, eller med DNS-baserede proxy-pools, hvor hostnavnet over tid peger på forskellige endpoints.

Mulighed 3: Egen DelegatingHandler til avanceret proxyvalg

Når proxyvalget afhænger af request-URL, payload eller runtime-kontekst, kan en brugerdefineret routing-handler inspicere hver request og sende den videre til den rigtige underliggende 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);
    }
}

Det er et avanceret design. Thread safety, disposal, genbrug af handlers, retry-adfærd og logging bliver dit eget ansvar. Jeg vil kun anbefale det, når de to første muligheder reelt ikke passer.

Sammenligning af de tre tilgange

Tilgang	Kompleksitet	.NET-version	Thread safety	Overhead
Navngivne klienter (IHttpClientFactory)	Lav	.NET Core 2.1+	Høj (immutabel konfiguration)	Lav
SocketsHttpHandler + PooledConnectionLifetime	Mellem	.NET 6+	Høj	Lav
Egen DelegatingHandler	Høj	Alle	Afhænger af implementering	Mellem

For de fleste teams er navngivne klienter det rigtige sted at starte. Gå videre til PooledConnectionLifetime for stabile roterende gateways, og brug kun brugerdefineret routing, når proxyvalget afhænger af metadata på request-niveau.

Vælg den rigtige proxyprotokol: HTTP, HTTPS og SOCKS5

Ikke alle proxies taler samme sprog, og bruger du den forkerte protokol, får du forvirrende fejl.

HTTP-proxy: Forstår HTTP-anmodninger. For almindelige HTTP-targets kan den sende requests direkte videre. For HTTPS-targets sender klienten en CONNECT-anmodning for at oprette en tunnel, hvorefter TLS forhandles gennem tunnellen med destinationen. Det er den mest almindelige model.

HTTPS-terminerende proxy: Proxyen præsenterer sit eget TLS-certifikat og krypterer trafikken igen videre opstrøms. Det er almindeligt i virksomheds-inspektionssystemer og nogle administrerede scraping-API’er. Kan udløse fejl i certifikatvalidering, hvis klienten ikke stoler på proxyens certifikatkæde.

SOCKS5-proxy: En TCP-tunnel på transportlaget, som virker til al TCP-trafik, ikke kun HTTP. Udbredt blandt leverandører af residential proxies. Understøttes nativt i .NET 6+.

SOCKS5-eksempel:

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

En bemærkning om SSL-certifikatvalidering

Når du bruger HTTPS-terminerende proxies, kan du se RemoteCertificateNameMismatch-fejl. ServerCertificateCustomValidationCallback kan bruges til at tilpasse valideringen:

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

Brug kun dette i lokal udvikling eller med en betroet, godkendt TLS-interceptende proxy. Hvis du blindt returnerer true, slår du en kritisk sikkerhedskontrol fra og åbner for man-in-the-middle-angreb. I produktion med standard CONNECT- eller SOCKS-proxies bør SSL-validering forblive slået til.

Fejlfinding af almindelige proxyfejl i C# HttpClient

Denne tabel kobler det synlige symptom til den sandsynlige årsag og den første rettelse, du bør prøve. Bogmærk gerne dette afsnit — det dækker de fejl, der oftest dukker op i Stack Overflow-tråde og udviklerfora.

Fejl / symptom	Typisk årsag	Løsning
407 Proxy Authentication Required	Credentials sat på `handler.Credentials` i stedet for `handler.Proxy.Credentials`; forkert brugernavnsformat; specialtegn i adgangskode indlejret i URL	Brug `WebProxy.Credentials = new NetworkCredential(...)`; undgå at indlejre credentials i URI; verificér leverandørens brugernavnsformat
TaskCanceledException / Timeout	Proxy-endpoint er langsomt, utilgængeligt, overbelastet eller blokeret af firewall; standardtimeout på 100s er for kort	Test proxyen med `curl`; forøg kun `HttpClient.Timeout`, efter du har bevist at endpointet virker; tilføj retries og sundhedstjek af proxyer
SocketException / Socket exhaustion	Oprettelse og disposal af `HttpClient` eller handlers for hver request	Brug `IHttpClientFactory`, singleton-klienter eller `SocketsHttpHandler` med pooling-kontroller
SSL RemoteCertificateNameMismatch	HTTPS-inspektion via virksomheds- eller administreret proxy	Installér/stol på proxyens CA, hvor det er relevant; brug kun custom validation i kontrolleret udvikling eller godkendte MITM-scenarier
302 Redirect-loop	Captive portal eller allowlist-blokering fra virksomhedsproxy/VPN, som videresender igen og igen	Test direkte forbindelse; inspicér `Location`-headers; tjek proxy-allowlist og autentificeringsportal
HttpRequestException / Ingen forbindelse med SOCKS-URL	SOCKS-kode køres på .NET Framework eller ældre .NET; forkert scheme eller port	Brug .NET 6+ til native SOCKS-support; verificér `socks5://host:port`; test med leverandørens dokumentation
Proxy virker tilsyneladende ikke	`UseProxy = false`; destination springes over som lokal; `NO_PROXY`-miljøvariabel; handler konfigureret anderledes end forventet	Sæt `UseProxy = true`; undersøg `HttpClient.DefaultProxy`; ryd eller overskriv miljøvariabler; sæt `BypassProxyOnLocal = false`

Hurtig fejlsøgningsflow

Lykkedes anmodningen? → Ja: sammenlign output fra api.ipify.org med den forventede proxy-IP.
Nej, er der en HTTP-statuskode? → 407: ret proxy-credentials. 403/429: målet har blokeret eller rate-limited proxyen. 3xx-loop: proxyen eller virksomhedsgatewayen videresender muligvis.
Ingen statuskode, kun en exception? → Timeout: test om proxyen kan nås. Socket-/certifikatfejl: tjek pooling, protokol, TLS og .NET-version.

Nyttige første kommandoer til at validere proxyen uden for .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/

Hvis curl virker, men din C#-kode ikke gør, er forskellen typisk auth-scheme, TLS trust store, miljøvariabler eller escaping af credentials. Match curl’s proxy-URL, scheme og autentificering præcist, og flyt derefter credentials over i NetworkCredential.

Hvornår du bør springe proxyhåndtering over: det no-code alternativ

En betydelig del af udviklere, der søger på “HttpClient proxy C#”, prøver ikke at lære proxyteori — de prøver at holde en scraper kørende. Det er værd at være ærlig omkring, hvornår egen C#-proxykode er det rigtige værktøj, og hvornår det ikke er.

Byg en custom C#-scraper med proxy-rotation, når:

Du har brug for fuld kontrol over request-logik, cookies, headers, retries og parsing
Scraperen skal integreres i en eksisterende .NET-kodebase eller intern service
Compliance eller sikkerhed kræver, at du ejer hele infrastrukturen end-to-end

Brug et no-code værktøj som Thunderbit, når:

Målet er struktureret dataudtræk fra websites, ikke HTTP-infrastruktur
Du helst vil slippe for at vedligeholde proxy-pools, håndtere CAPTCHA’er eller debugge socket exhaustion
Teamet har brug for data i Excel, Google Sheets, Airtable eller Notion uden at skrive parsingkode

Thunderbits Chrome-udvidelse håndterer proxy-rotation og anti-bot-foranstaltninger automatisk via cloud scraping-funktionen. Dets API lader udviklere definere et JSON-skema og få strukturerede data tilbage uden overhovedet at skulle administrere HttpClient eller WebProxy. For teams, der arbejder med web scraping til prissammenligning eller lead extraction, er forskellen i opsætningstid markant.

Scenarie	Custom C# + proxy	Thunderbit
Fuld kontrol over request-logik	Ja	Nej (kun kontrol på API-niveau)
Proxyhåndtering nødvendig	Ja	Nej (håndteres automatisk)
Anti-bot / CAPTCHA-håndtering	Manuel eller tredjepart	Indbygget
Opsætningstid	Timer til dage	Minutter
Bedst til	Eksisterende .NET-kodebaser, custom pipelines	Hurtigt dataudtræk, ikke-tekniske teams, eksport til regneark

Det her er ikke et argument for “aldrig brug HttpClient”. Hvis du bygger en produktionsklar .NET-tjeneste, bør du helt klart forstå proxykonfiguration. Men hvis du bruger timer på at debugge 407-fejl for en engangsindsamling, findes der enklere muligheder — og det er helt i orden at bruge dem. Du kan se Thunderbits priser eller tjekke YouTube-kanalen for gennemgange.

Vigtigste pointer

Kerne-mønsteret er det samme: WebProxy → handler → HttpClient. Resten handler om at undgå de driftsfejl, som dukker op i produktion.

Credentials skal ligge på proxyen, ikke på handleren. Side-om-side-eksemplet i 407-afsnittet er det vigtigste at huske.
Opret ikke en ny HttpClient pr. request eller pr. proxy. Brug IHttpClientFactory til navngivne klienter, SocketsHttpHandler med PooledConnectionLifetime til roterende gateways eller en custom routing-handler til avancerede scenarier.
Tjek din .NET-version, før du kopierer SOCKS5- eller SocketsHttpHandler-kode. Kompatibilitetsoversigten ovenfor sparer dig for tavse fejl.
Test proxyen uden for .NET først. En hurtig curl-kommando fjerner en hel kategori af fejlfinding.
Til struktureret dataudtræk uden proxyhovedpine kan værktøjer som Thunderbit håndtere transportlaget, så du kan fokusere på selve dataene.

Næste gang du rammer en 407 eller en TaskCanceledException, så start med fejlfindingstabellen ovenfor.

FAQs

Kan jeg ændre proxyen på en eksisterende HttpClient-instans?

Nej. Proxyen er bundet til handleren, og handleren sættes ved konstruktion. HttpClient har ikke et mutabelt Proxy-property. Hvis du vil bruge forskellige proxies, skal du oprette separate handlers og klienter og styre dem med IHttpClientFactory-navngivne klienter eller en pulje af forkonfigurerede klienter.

Bruger HttpClient systemproxyen som standard?

Ja. I moderne .NET arver HttpClient systemets standard proxyindstillinger, hvis du ikke eksplicit sætter en handler — inklusive miljøvariabler som HTTPS_PROXY og HTTP_PROXY via HttpClient.DefaultProxy. Hvis du vil fravælge det, skal du eksplicit sætte UseProxy = false på handleren.

Hvordan bruger jeg en SOCKS5-proxy med HttpClient i C#?

Brug new WebProxy("socks5://host:port") sammen med SocketsHttpHandler. Native SOCKS-understøttelse kræver .NET 6 eller nyere. På .NET Framework 4.x understøttes SOCKS5 ikke nativt — der skal du bruge et tredjepartsbibliotek.

Hvorfor bliver jeg hele tiden ved med at få 407 Proxy Authentication Required?

Mest sandsynligt sætter du credentials på handler.Credentials (som gælder destinationserveren) i stedet for handler.Proxy.Credentials (som gælder proxyen). Se afsnittet “Proxy-legitimationsoplysninger vs. server-legitimationsoplysninger” ovenfor for det korrekte mønster.

Er det sikkert at slå SSL-certifikatvalidering fra, når man bruger en proxy?

Kun i lokal udvikling eller når du har fuld tillid til proxy-leverandøren (for eksempel en administreret scraping-API i HTTPS-proxy-mode). I produktion med standard CONNECT- eller SOCKS-proxies bør SSL-validering forblive slået til for at beskytte mod man-in-the-middle-angreb.

Prøv Thunderbit til ubesværet web scraping Get Started Free

Læs mere