Så använder du en proxy med HttpClient i C#: mönster och lösningar

Förra veckan lade jag pinsamt många timmar på att stirra på ett 407 Proxy Authentication Required-svar, helt säker på att min proxy-leverantör strulade. Det visade sig att jag hade lagt in uppgifterna på fel egenskap — en fix på två rader som tog mig två timmar att hitta. Känns det bekant är den här guiden för dig.

Proxykonfiguration med HttpClient i C# är ett område där grundmönstret är enkelt, men fallgroparna i produktion — socket exhaustion, SOCKS5-versioner som inte matchar, förvirring kring autentisering — äter upp riktig tid.

Jag har arbetat med verktyg för web scraping och datauttag på Thunderbit ett bra tag nu, och jag har sett samma misstag dyka upp om och om igen, både i våra interna tekniska diskussioner och i utvecklargemenskaperna vi följer. Den här genomgången täcker allt från uppsättning och autentisering till proxyrotation, protokollval och en felsökningstabell som jag verkligen önskar hade funnits när jag började.

Svårighetsgrad: Nybörjare till medelnivå
Tidsåtgång: ~15 minuter att följa med, längre för produktionsmönster med rotation
Det här behöver du: .NET 6+-SDK (för SOCKS5 och moderna handler-funktioner; .NET Framework 4.x fungerar för enkla HTTP-proxyexempel), en kodeditor och minst en proxyendpoint att testa med

Vad är HttpClient och varför behöver det en proxy?

HttpClient är .NET:s inbyggda klass i System.Net.Http för att skicka HTTP-begäranden och ta emot svar. Den stödjer async/await, egna headers, cancellations tokens och konfigurering via handlers. Microsoft beskriver den som en klass för att skicka HTTP-begäranden och ta emot HTTP-svar från en resurs som identifieras av en URI.

En proxyserver är en mellanhand mellan din applikation och målwebbplatsen. När du skickar trafiken genom en proxy ser målservern proxyns IP-adress i stället för din egen.

HttpClient har ingen egen Proxy-egenskap. Proxy-routing konfigureras i den underliggande handlern — antingen HttpClientHandler eller SocketsHttpHandler — som accepterar en WebProxy-instans. Den mentala modellen ser ut så här:

[Din C#-app] → [HttpClient + Handler] → [Proxyserver] → [Målwebbplats]

Därför är “ändra proxyn på en aktiv HttpClient” ett designproblem, inte bara en enkel egenskapstilldelning. Mer om det i avsnittet om rotation.

Testa Thunderbit för enklare datauttag

Varför använda en proxy med HttpClient i C#

Utvecklare skickar HttpClient-trafik genom proxyservrar av några återkommande skäl, och rätt proxytyp beror på uppgiften.

Undvik IP-blockeringar och hastighetsbegränsningar: Viktigt för web scraping, leadgenerering eller prisbevakning i större skala. En enda IP som bombarderar en sajt blir snabbt blockerad.
Gå förbi geografiska begränsningar: Få åtkomst till regionlåsta API:er eller innehåll genom att routa via proxyservrar i specifika länder.
Dölj din ursprungliga IP-adress: Lägg till ett lager av integritet vid känsligt datauttag eller konkurrensanalys.
Företags- eller compliance-krav: Många organisationer kräver att utgående trafik passerar en central gateway för loggning och styrning.
Test och kvalitetssäkring: Simulera förfrågningar från olika platser eller nätverksmiljöer utan att behöva placera infrastruktur fysiskt där.

Användningsfall	Typiskt proxyval	Varför det passar
Web scraping i stor skala	Roterande residential-proxy	Mer IP-variation, svårare för anti-bot-system att identifiera
Prisbevakning inom e-handel	Residential-proxy eller geoanpassad datacenter-proxy	Regionberoende priser och lagerkontroller
API-åtkomst via en fast gateway	Datacenter-proxy eller företagsproxy	Förutsägbar IP-allowlisting, lägre kostnad
Företagscompliance	Systemproxy, PAC-proxy, autentiserad företagsproxy	Centraliserad loggning och kontroll av utgående trafik
QA och lokaliseringstestning	Landsspecifik proxy-pool	Simulerar verklig åtkomst från målordningar

Proxyanvändning skalar också i ganska förutsägbara steg. Du börjar med en enda statisk proxy för att bekräfta routing. En produktionsscraper går vidare till en pool där begäranden mappas till proxies efter mål-doman, geografi eller felfrekvens. Mogna team går ofta över till en hanterad proxy-gateway där rotation, retries och sessionsaffinitet sköts bakom en enda endpoint.

Proxyrotation är inte någon universallösning. Om en målwebbplats blockerar misstänkt beteende hjälper IP-rotation bara när även begärandetakt, headers, cookies och TLS-fingeravtryck hanteras omsorgsfullt.

Vilken .NET-version stödjer vad: snabb kompatibilitetsöversikt

Att kopiera ett proxyexempel från ett blogginlägg till fel target framework är en vanlig orsak till tysta fel. Den största skiljelinjen är .NET Framework 4.x kontra modern .NET (.NET 6+). Här är vad som fungerar var:

.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 (tillagt i .NET 6)	Ja	Ja
`SocketsHttpHandler` (standardhandler)	Nej	Ja	Ja	Ja
Statisk `HttpClient.DefaultProxy`	Nej	Ja	Ja	Ja
`PooledConnectionLifetime`	Nej	Ja	Ja	Ja

Om du siktar på .NET Framework 4.x bör du hålla dig till HTTP/HTTPS-proxies med HttpClientHandler och WebProxy. SOCKS5 och moderna inställningar för connection pooling kräver .NET 6 eller senare.

En subtil detalj att hålla koll på: HttpClient.DefaultProxy är en statisk egenskap i modern .NET. Om den sätts i delad startkod eller ärvs från miljövariabler som HTTPS_PROXY eller HTTP_PROXY plockar varje HttpClient-instans upp den, om du inte uttryckligen skriver över den i handlern. I containeriserade miljöer är detta en vanlig källa till förvirringen “varför använder min klient en proxy jag aldrig konfigurerat?”.

Steg 1: Skapa ett nytt C# Console-projekt

Öppna terminalen och skapa ett nytt projekt:

dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo

Kontrollera SDK-versionen med dotnet --version. Exemplen i den här guiden utgår från .NET 6+ för full funktionalitet. Om du behöver den senaste LTS-versionen, hämta den från Microsofts nedladdningssida.

Öppna Program.cs i din editor. Det är där allt händer.

Steg 2: Gör en grundläggande HTTP-begäran utan proxy

Innan du konfigurerar en proxy behöver du veta din verkliga utgående IP. Då kan du, när proxyn aktiveras, bekräfta att IP:t faktiskt ändrades.

using System.Net.Http;

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

Kör det. Du bör se din nuvarande publika IP-adress, ungefär så här:

Direkt IP: 203.0.113.10

Spara det värdet i huvudet. Efter nästa steg ska det vara annorlunda.

Steg 3: Konfigurera en WebProxy med HttpClientHandler

Det klassiska mönstret består av tre objekt: en WebProxy, en handler och 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}");

Byt ut proxy.example.com:8080 mot din faktiska proxyendpoint. Om allt är rätt uppsatt ska utdata-IP:t nu matcha proxyns exit-IP — inte din riktiga.

Viktiga egenskaper att förstå:

Proxy — den IWebProxy-instans som handlern använder för routing.
UseProxy = true — säger åt handlern att faktiskt använda den konfigurerade proxyn. Att glömma detta är ett riktigt tidssänke vid felsökning.
BypassProxyOnLocal = false — hindrar handlern från att hoppa över proxyn för destinationer som ser “lokala” ut.
UseDefaultCredentials — styr om handlern skickar Windows standarduppgifter. Detta är inte samma sak som proxyanvändarnamn och lösenord.

Steg 4: Lägg till proxyautentisering med NetworkCredential

De flesta betalda proxy-leverantörer kräver autentisering. Rätt mönster är att sätta uppgifterna på själva 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($"Autentiserad proxy-IP: {ip}");

Många leverantörer ger dig ett URL-format som http://username:password@host:port. I .NET-kod är det bättre att använda NetworkCredential än att bädda in uppgifterna i URI-strängen. Det undviker problem med specialtecken i lösenord och gör gränsen mellan URI och autentisering tydligare.

Jag går igenom det vanligaste autentiseringsfelet — och varför det orsakar 407-fel — i ett särskilt avsnitt längre ned.

Steg 5: Använd eller exportera svarsdatan

För allt som är mer än en snabb IP-kontroll bör du hantera svaret korrekt:

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

if (!response.IsSuccessStatusCode)
{
    Console.WriteLine($"Begäran misslyckades: {(int)response.StatusCode} {response.ReasonPhrase}");
    return;
}

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

För scraping-flöden är den proxade begäran bara transportlagret. Du behöver fortfarande parsing, normalisering, deduplicering, retries och export till Excel, Google Sheets, databaser eller andra mål. Verktyg som Thunderbit kan automatisera extraktion och export — dess Chrome-tillägg hanterar strukturerad datainsamling och gratis export till Google Sheets, Excel, Airtable eller Notion utan att du behöver skriva parserkod.

Exportera scrappad data till Excel, Sheets, Airtable eller Notion Get Started Free

Proxyuppgifter vs. serveruppgifter: misstaget som orsakar 407-fel

Jag har sett det här misstaget i Stack Overflow-trådar, Microsoft Q&A-inlägg och — ska erkännas — i min egen kod.

Skillnaden är enkel men lätt att blanda ihop:

Proxyuppgifter autentiserar dig mot själva proxyservern.
Serveruppgifter autentiserar dig mot målservern.

I HttpClientHandler ligger de på olika egenskaper. Att sätta uppgifterna på fel ställe är den vanligaste orsaken till 407 Proxy Authentication Required-fel.

// ❌ FEL — sätter uppgifter för destinationservern, inte för proxyn
handler.Credentials = new NetworkCredential("user", "pass");

// ✅ RÄTT — sätter uppgifter på själva proxyobjektet
handler.Proxy = new WebProxy("http://proxy:8080")
{
    Credentials = new NetworkCredential("user", "pass")
};

HttpClientHandler.Credentials riktar sig mot destinationen. WebProxy.Credentials riktar sig mot proxyn. Om proxyn svarar med 407 ska uppgifterna ligga på proxyn.

En fälla till: HttpClientHandler.PreAuthenticate styr förhandsautentisering för destinationens autentisering. Den styr inte Proxy-Authorization-headern. Använd den inte som fix för 407.

Så roterar du proxies med HttpClient i C#

Utvecklare frågar om detta hela tiden i forum. Svaret är först lite nedslående: du kan inte byta proxy på en redan aktiv HttpClient-instans. Proxyn sitter på handlern. Handlern sätts vid konstruktion. HttpClient exponerar ingen muterbar Proxy-egenskap.

Den naiva lösningen — new HttpClient(new HttpClientHandler { Proxy = ... }) för varje begäran — skapar ett annat problem. Microsoft varnar uttryckligen för att skapa och kasta klienter per begäran eftersom det kan tömma tillgängliga TCP-portar, då portar inte släpps omedelbart när en anslutning stängs.

Här är tre produktionsdugliga mönster som faktiskt fungerar.

Alternativ 1: Namngivna klienter via IHttpClientFactory

Om din proxyuppsättning är känd vid start är namngivna klienter det minst komplexa alternativet. Varje namngiven klient får sin egen handler-konfiguration, och applikationen hämtar den med namn vid körning.

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

// Vid anrop:
var client = httpClientFactory.CreateClient("proxy-us");

Factoryn hanterar handler-livslängder och undviker anti-mönstret att skapa en ny klient per begäran.

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

För en långlivad klient bakom en proxy-gateway som roterar exit-IP:er vid nya anslutningar tvingar PooledConnectionLifetime anslutningar att återskapas efter en viss tid.

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 här ändrar inte magiskt Proxy-objektet per begäran. Det fungerar bäst med proxy-gateways som tilldelar olika exit-IP:er för varje ny TCP-anslutning, eller med DNS-baserade proxy-pooler där hostnamnet löser upp till olika endpoints över tid.

Alternativ 3: Egen DelegatingHandler för avancerat proxval

När proxyvalet beror på begärans URL, payload eller körningskontext kan en egen routing-handler inspektera varje begäran och skicka den vidare till rätt pipeline av inner handlers.

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 här är en avancerad design. Tråd-säkerhet, disposal, återanvändning av handlers, retry-beteende och loggning blir ditt ansvar. Jag skulle rekommendera den bara när de två första alternativen verkligen inte passar.

Jämförelse av de tre metoderna

Metod	Komplexitet	.NET-version	Tråd-säkerhet	Overhead
Namngivna klienter (IHttpClientFactory)	Låg	.NET Core 2.1+	Hög (immutabel konfiguration)	Låg
SocketsHttpHandler + PooledConnectionLifetime	Medel	.NET 6+	Hög	Låg
Egen DelegatingHandler	Hög	Alla	Beror på implementation	Medel

För de flesta team är namngivna klienter den bästa startpunkten. Gå vidare till PooledConnectionLifetime för stabila roterande gateways, och använd egen routing bara när proxyvalet beror på metadata på begäranivå.

Välj rätt proxyprotokoll: HTTP, HTTPS och SOCKS5

Alla proxies talar inte samma språk, och om du använder fel protokollschema får du förvirrande fel.

HTTP-proxy: Förstår HTTP-begäranden. För vanliga HTTP-mål kan den skicka begäran direkt. För HTTPS-mål skickar klienten en CONNECT-begäran för att skapa en tunnel, och sedan förhandlas TLS genom den tunneln med destinationen. Detta är den vanligaste modellen.

HTTPS-avslutande proxy: Proxyn presenterar sitt eget TLS-certifikat och krypterar om trafiken uppströms. Vanligt i företagslösningar för inspektion och vissa managed scraping-API:er. Kan orsaka certifikatvalideringsfel om klienten inte litar på proxyns certifikatkedja.

SOCKS5-proxy: En TCP-tunnel på transportlagret som fungerar för all TCP-trafik, inte bara HTTP. Vanligt hos leverantörer av residential-proxies. Stöds nativt i .NET 6+.

SOCKS5-exempel:

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 notis om SSL-certifikatvalidering

När du använder HTTPS-avslutande proxies kan du få RemoteCertificateNameMismatch-fel. ServerCertificateCustomValidationCallback kan anpassa valideringen:

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

Använd detta endast i lokal utveckling eller med en betrodd, godkänd TLS-inspekterande proxy. Att blint returnera true stänger av en kritisk säkerhetskontroll och öppnar för man-in-the-middle-attacker. I produktion med vanliga CONNECT- eller SOCKS-proxies ska SSL-validering vara påslagen.

Felsök vanliga proxyfel i C# HttpClient

Den här tabellen kopplar det synliga symptomet till den sannolika grundorsaken och den första fixen du bör prova. Bokmärk gärna det här avsnittet — det täcker de fel som dyker upp oftast i Stack Overflow-trådar och utvecklarforum.

Fel / symptom	Vanlig orsak	Lösning
407 Proxy Authentication Required	Uppgifter satta på `handler.Credentials` i stället för `handler.Proxy.Credentials`; fel användarformat; specialtecken i lösenord som bäddats in i URL	Använd `WebProxy.Credentials = new NetworkCredential(...)`; undvik att bädda in uppgifter i URI; kontrollera leverantörens användarformat
TaskCanceledException / Timeout	Proxyendpoint långsam, otillgänglig, överbelastad eller blockerad av brandvägg; standardtimeout på 100 s är för kort	Testa proxyn med `curl`; öka `HttpClient.Timeout` först efter att du visat att endpointen fungerar; lägg till retries och hälsokontroller
SocketException / Socket exhaustion	Du skapar och kastar `HttpClient` eller handlers per begäran	Använd `IHttpClientFactory`, singleton-klienter eller `SocketsHttpHandler` med pooling-kontroller
SSL RemoteCertificateNameMismatch	HTTPS-inspektion via företags- eller managed proxy	Installera/lita på proxy-CA där det är relevant; använd egen validering endast i kontrollerad utveckling eller godkända MITM-scenarier
302 Redirect loop	Proxy/VPN/captive portal som omdirigerar upprepade gånger	Testa direktanslutning; inspektera `Location`-headers; kontrollera allowlist och autentiseringsportal
HttpRequestException / Ingen anslutning med SOCKS-URL	SOCKS-kod körs på .NET Framework eller äldre .NET; fel schema eller port	Använd .NET 6+ för inbyggt SOCKS-stöd; verifiera `socks5://host:port`; testa mot leverantörens dokumentation
Proxyn verkar ignoreras	`UseProxy = false`; målet bypassas som lokalt; `NO_PROXY`-miljövariabel; handlern är konfigurerad på annat sätt än förväntat	Sätt `UseProxy = true`; kontrollera `HttpClient.DefaultProxy`; rensa eller skriv över miljövariabler; sätt `BypassProxyOnLocal = false`

Snabb felsökningsguide

Lyckades begäran? → Ja: jämför utdata från api.ipify.org med förväntad proxy-IP.
Nej, men det finns en HTTP-statuskod? → 407: fixa proxyuppgifter. 403/429: målservern blockerade eller rate-limitar proxyn. 3xx-loop: proxy eller företagsgateway kan omdirigera.
Ingen statuskod, bara ett undantag? → Timeout: testa proxyåtkomst. Socket- eller certifikatfel: kontrollera pooling, protokoll, TLS och .NET-version.

Användbara första kommandon för att validera proxyn utanför .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/

Om curl fungerar men din C#-kod inte gör det beror skillnaden oftast på auth-scheme, TLS trust store, miljövariabler eller hur uppgifter escapes. Matcha curl-proxy-URL, schema och autentisering exakt, och flytta sedan in uppgifterna i NetworkCredential.

När du bör hoppa över proxyhantering: no-code-alternativet

En stor del av utvecklarna som söker på “HttpClient proxy C#” försöker egentligen inte lära sig proxyteori — de försöker få en scraper att fortsätta fungera. Det är värt att vara ärlig om när egen C#-proxykod är rätt verktyg och när den inte är det.

Bygg en egen C#-scraper med proxyrotation när:

Du behöver full kontroll över begärandelogik, cookies, headers, retries och parsing
Scrapern ska integreras i en befintlig .NET-kodbas eller intern tjänst
Compliance- eller säkerhetskrav innebär att du själv måste äga infrastrukturen från början till slut

Använd ett no-code-verktyg som Thunderbit när:

Målet är strukturerat datauttag från webbplatser, inte HTTP-infrastruktur
Du helst slipper underhålla proxy-pooler, hantera CAPTCHA eller felsöka socket exhaustion
Teamet behöver data i Excel, Google Sheets, Airtable eller Notion utan att skriva parserkod

Thunderbits Chrome-tillägg hanterar proxyrotation och anti-bot-mekanismer automatiskt via sitt molnbaserade scraping-alternativ. Dess API låter utvecklare definiera ett JSON-schema och få tillbaka strukturerad data utan att alls behöva hantera HttpClient eller WebProxy. För team som jobbar med web scraping för prisjämförelse eller leadutvinning är skillnaden i uppsättningstid stor.

Scenario	Egen C# + proxy	Thunderbit
Full kontroll över begärandelogik	Ja	Nej (API-nivåkontroll)
Proxyhantering krävs	Ja	Nej (sköts automatiskt)
Anti-bot / CAPTCHA-hantering	Manuellt eller via tredjepart	Inbyggt
Uppsättningstid	Timmar till dagar	Minuter
Bäst för	Befintliga .NET-kodbaser, anpassade pipelines	Snabb datautvinning, icke-tekniska team, export till kalkylblad

Det här är inte ett argument för att “aldrig använda HttpClient”. Bygger du en produktions-NET-tjänst bör du absolut förstå proxykonfiguration. Men om du lägger timmar på att felsöka 407-fel för ett engångsjobb finns enklare alternativ — och det är inget att skämmas för. Du kan utforska Thunderbits prissättning eller titta på YouTube-kanalen för genomgångar.

Viktiga lärdomar

Grundmönstret är detsamma: WebProxy → handler → HttpClient. Allt efter det handlar om att undvika de operativa misstag som dyker upp i produktion.

Uppgifter ska ligga på proxyn, inte på handlern. Jämförelsesnippet i 407-avsnittet är det viktigaste att minnas.
Skapa inte en ny HttpClient per begäran eller per proxy. Använd IHttpClientFactory för namngivna klienter, SocketsHttpHandler med PooledConnectionLifetime för roterande gateways eller en egen routing-handler för avancerade scenarier.
Kontrollera din .NET-version innan du kopierar SOCKS5- eller SocketsHttpHandler-kod. Kompatibilitetsmatrisen ovan sparar dig från tysta fel.
Testa proxyn utanför .NET först. Ett snabbt curl-kommando eliminerar en hel kategori felsökning.
För strukturerad datautvinning utan proxystrul hanterar verktyg som Thunderbit transportlagret så att du kan fokusera på själva datan.

Nästa gång du stöter på en 407 eller en TaskCanceledException, börja med felsökningstabellen ovan.

Vanliga frågor

Kan jag ändra proxyn på en befintlig HttpClient-instans?

Nej. Proxyn är bunden till handlern, och handlern sätts vid konstruktion. HttpClient exponerar ingen muterbar Proxy-egenskap. För olika proxies behöver du separata handlers och klienter, och hantera dem med IHttpClientFactory-namngivna klienter eller en pool av förkonfigurerade klienter.

Använder HttpClient systemproxyn som standard?

Ja. I modern .NET, om du inte uttryckligen sätter en handler ärver HttpClient systemets standardinställningar för proxy — inklusive miljövariabler som HTTPS_PROXY och HTTP_PROXY via HttpClient.DefaultProxy. För att välja bort detta sätter du uttryckligen UseProxy = false på handlern.

Hur använder jag en SOCKS5-proxy med HttpClient i C#?

Använd new WebProxy("socks5://host:port") tillsammans med SocketsHttpHandler. Nativt SOCKS-stöd kräver .NET 6 eller senare. I .NET Framework 4.x stöds SOCKS5 inte nativt — du behöver ett tredjepartsbibliotek.

Varför får jag hela tiden 407 Proxy Authentication Required?

Troligtvis sätter du uppgifter på handler.Credentials (som riktar sig mot målservern) i stället för handler.Proxy.Credentials (som riktar sig mot proxyn). Se avsnittet “Proxyuppgifter vs. serveruppgifter” ovan för rätt mönster.

Är det säkert att stänga av SSL-certifikatvalidering när man använder proxy?

Endast i lokal utveckling eller när du litar helt på proxy-leverantören (till exempel en managed scraping-API i HTTPS-proxyläge). I produktion med vanliga CONNECT- eller SOCKS-proxies bör SSL-validering vara påslagen för att förhindra man-in-the-middle-attacker.

Testa Thunderbit för enkel web scraping Get Started Free

Läs mer