Cum să folosești un proxy cu HttpClient în C#: modele și soluții

Săptămâna trecută am pierdut o grămadă jenantă de timp uitându-mă la un răspuns 407 Proxy Authentication Required, convins că furnizorul meu de proxy era în pană. De fapt, setasem credențialele pe proprietatea greșită — o rezolvare de două linii care mi-a luat două ore s-o descopăr. Dacă ți se pare familiar, ghidul ăsta e pentru tine.

Configurarea unui proxy cu HttpClient în C# este unul dintre subiectele acelea în care baza e simplă, dar capcanele din producție — epuizarea socketurilor, nepotriviri de versiune SOCKS5, confuzia legată de credențiale — îți mănâncă mult timp real.

Lucrez de ceva vreme cu instrumente de web scraping și extragere de date la Thunderbit, și am văzut aceleași greșeli repetându-se iar și iar, atât în discuțiile noastre de engineering, cât și în comunitățile de dezvoltatori pe care le urmărim. Ghidul ăsta acoperă tot fluxul: configurare, autentificare, rotația proxy-urilor, alegerea protocolului și un tabel de depanare pe care, sincer, mi-aș fi dorit să-l am în ziua în care am început.

Dificultate: Începător spre nivel intermediar
Timp necesar: ~15 minute ca să urmezi pașii, mai mult pentru modele de rotație în producție
De ce ai nevoie: .NET 6+ SDK (pentru SOCKS5 și funcțiile moderne ale handlerului; .NET Framework 4.x funcționează pentru exemplele de bază cu proxy HTTP), un editor de cod și cel puțin un endpoint de proxy pentru test

Ce este HttpClient și de ce are nevoie de proxy?

HttpClient este clasa .NET integrată din System.Net.Http, folosită pentru a trimite cereri HTTP și a primi răspunsuri. Oferă suport pentru async/await, headere personalizate, tokenuri de anulare și configurare bazată pe handler. Microsoft îl descrie ca o clasă pentru trimiterea cererilor HTTP și primirea răspunsurilor HTTP de la o resursă identificată printr-un URI.

Un server proxy este un intermediar care stă între aplicația ta și site-ul țintă. Când trimiți traficul printr-un proxy, site-ul vede adresa IP a proxy-ului, nu pe a ta.

HttpClient în sine nu are o proprietate Proxy. Rutarea prin proxy se configurează în handlerul de bază — fie HttpClientHandler, fie SocketsHttpHandler — care primește o instanță WebProxy. Modelul mental arată așa:

[Aplicația ta C#] → [HttpClient + Handler] → [Server Proxy] → [Site-ul Țintă]

De aceea, „schimbă proxy-ul unui HttpClient deja activ” e o problemă de design, nu doar o simplă atribuire de proprietate. Revin la asta în secțiunea despre rotație.

Încearcă Thunderbit pentru extragere de date mai ușoară

De ce să folosești un proxy cu HttpClient în C#

Dezvoltatorii trimit traficul HttpClient prin proxy-uri din câteva motive recurente, iar tipul potrivit depinde de sarcină.

• Evitarea banărilor IP și a limitărilor de rată: esențial pentru web scraping, lead generation sau monitorizarea prețurilor la scară. Un singur IP care „bombardează” un site va fi blocat repede.
• Ocolirea restricțiilor geografice: accesezi API-uri sau conținut restricționat pe regiuni prin proxy-uri din anumite țări.
• Ascunderea IP-ului sursă: adaugi un strat de confidențialitate pentru colectare de date sensibile sau cercetare competitivă.
• Cerinte corporate sau de conformitate: multe organizații cer ca traficul outbound să treacă printr-un gateway centralizat pentru logging și guvernanță.
• Testare și QA: simulezi cereri din locații sau condiții de rețea diferite fără să implementezi efectiv infrastructură în acele regiuni.

Caz de utilizare	Alegerea tipică de proxy	De ce se potrivește
Web scraping la scară	Proxy-uri rezidențiale rotative	Mai multă diversitate de IP-uri, mai greu de clasificat de sistemele anti-bot
Monitorizarea prețurilor în e-commerce	Proxy rezidențial sau datacenter geo-targetat	Verificări de preț și stoc specifice regiunii
Acces la API printr-un gateway fix	Proxy datacenter sau proxy corporate	Allowlist de IP-uri predictibil, cost mai mic
Conformitate enterprise	Proxy de sistem, proxy PAC, proxy company autentificat	Logging centralizat și control outbound
QA și testare de localizare	Pool de proxy-uri specifice unei țări	Simulează accesul real al utilizatorilor din regiunile țintă

Utilizarea proxy-urilor evoluează și ea în etape previzibile. Începi cu un singur proxy static ca să confirmi rutarea. Un scraper de producție trece la un pool, mapând cererile către proxy-uri în funcție de domeniul țintă, geografie sau rata de eșec. Echipele mature ajung adesea la un proxy gateway gestionat, unde rotația, retry-urile și session affinity sunt administrate printr-un singur endpoint.

Rotația proxy nu e o soluție magică. Dacă un site blochează comportamentul suspect, schimbarea IP-urilor ajută doar atunci când ritmul cererilor, headerele, cookie-urile și fingerprinting-ul TLS sunt gestionate atent.

Ce versiune .NET suportă ce: un tabel rapid de compatibilitate

Să copiezi un fragment de proxy dintr-un blog în framework-ul greșit e o sursă majoră de eșecuri tăcute. Linia de separație cea mai importantă este între .NET Framework 4.x și .NET modern (.NET 6+). Iată ce funcționează și unde:

Capabilitate	.NET Framework 4.x	.NET 6	.NET 7	.NET 8–9
WebProxy + HttpClientHandler	Da	Da	Da	Da
SOCKS5 prin WebProxy("socks5://...")	Nu	Da (adăugat în .NET 6)	Da	Da
SocketsHttpHandler (handlerul implicit)	Nu	Da	Da	Da
HttpClient.DefaultProxy static	Nu	Da	Da	Da
PooledConnectionLifetime	Nu	Da	Da	Da

Dacă vizezi .NET Framework 4.x, rămâi la proxy-uri HTTP/HTTPS cu HttpClientHandler și WebProxy. SOCKS5 și controalele moderne de pooling cer .NET 6 sau mai nou.

Un comportament subtil de urmărit: HttpClient.DefaultProxy este o proprietate statică în .NET modern. Dacă este setată în codul comun de startup sau moștenită din variabile de mediu precum HTTPS_PROXY sau HTTP_PROXY, fiecare instanță HttpClient o va prelua, cu excepția cazului în care suprascrii explicit handlerul. În deploy-urile containerizate, ăsta e un motiv frecvent pentru confuzia de tipul „de ce folosește clientul meu un proxy pe care nu l-am configurat?”.

Pasul 1: Creează un proiect nou C# Console

Deschide terminalul și creează un proiect nou:

dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo

Verifică versiunea SDK-ului cu dotnet --version. Exemplele din ghidul ăsta vizează .NET 6+ pentru acoperire completă a funcțiilor. Dacă ai nevoie de cel mai nou SDK LTS, îl poți descărca de pe pagina de descărcare Microsoft.

Deschide Program.cs în editor. Acolo se întâmplă totul.

Pasul 2: Fă o cerere HTTP de bază (fără proxy)

Înainte să configurezi un proxy, află IP-ul tău real de ieșire. Așa, după ce activezi proxy-ul, poți confirma că IP-ul chiar s-a schimbat.

using System.Net.Http;

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

Rulează-l. Ar trebui să vezi adresa ta IP publică actuală, ceva de genul:

Direct IP: 203.0.113.10

Ține minte valoarea. După pasul următor, ar trebui să fie diferită.

Pasul 3: Configurează un WebProxy cu HttpClientHandler

Modelul clasic folosește trei obiecte: un WebProxy, un handler și clientul.

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

Înlocuiește proxy.example.com:8080 cu endpoint-ul tău real de proxy. Dacă totul e configurat corect, IP-ul afișat ar trebui să corespundă IP-ului de ieșire al proxy-ului, nu celui real.

Proprietăți importante de înțeles:

• Proxy — instanța IWebProxy folosită de handler pentru rutare.
• UseProxy = true — îi spune handlerului să folosească efectiv proxy-ul configurat. (Pare evident, dar să uiți pasul ăsta te poate ține blocat mult la depanare.)
• BypassProxyOnLocal = false — împiedică handlerul să sară peste proxy pentru destinații care par „locale”.
• UseDefaultCredentials — controlează dacă handlerul trimite credențialele implicite Windows. Nu e același lucru cu username/parolă pentru proxy.

Pasul 4: Adaugă autentificare pentru proxy cu NetworkCredential

Majoritatea furnizorilor de proxy plătiți cer credențiale. Modelul corect este să le setezi chiar pe obiectul 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}");

Mulți furnizori oferă un format de URL de genul http://username:password@host:port. Pentru codul .NET, preferă NetworkCredential în locul includerii credențialelor în șirul URI. Evită problemele de escapare cu caractere speciale din parolă și păstrează separarea clară între URI și credențiale.

Cea mai frecventă greșeală de autentificare — și motivul pentru erorile 407 — e explicată într-o secțiune dedicată mai jos.

Pasul 5: Exportă sau folosește datele din răspuns

Pentru orice e mai mult decât o verificare rapidă a IP-ului, tratează răspunsul corect:

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

Pentru fluxurile de scraping, cererea trecută prin proxy e doar stratul de transport. Încă ai nevoie de parsare, normalizare, deduplicare, retry-uri și exporturi în Excel, Google Sheets, baze de date sau alte destinații. Instrumente precum Thunderbit pot automatiza pașii de extragere și export — extensia sa Chrome gestionează extragerea de date structurate și exportul gratuit către Google Sheets, Excel, Airtable sau Notion, fără să scrii cod de parsare.

Exportă datele extrase în Excel, Sheets, Airtable sau Notion Get Started Free

Credențiale pentru proxy vs. credențiale pentru server: greșeala care provoacă erori 407

Am văzut greșeala asta în thread-uri de pe Stack Overflow, postări Microsoft Q&A și — recunosc — chiar în propriul meu cod.

Diferența e simplă, dar foarte ușor de încurcat:

• Credențialele pentru proxy te autentifică la serverul proxy propriu-zis.
• Credențialele pentru server te autentifică la serverul destinație/țintă.

În HttpClientHandler, ele stau pe proprietăți diferite. Dacă setezi credențialele pe proprietatea greșită, de foarte multe ori primești erori 407 Proxy Authentication Required.

// ❌ GREȘIT — setează credențialele pentru serverul destinație, nu pentru proxy
handler.Credentials = new NetworkCredential("user", "pass");

// ✅ CORECT — setează credențialele direct pe obiectul proxy
handler.Proxy = new WebProxy("http://proxy:8080")
{
    Credentials = new NetworkCredential("user", "pass")
};

HttpClientHandler.Credentials se referă la destinație. WebProxy.Credentials se referă la proxy. Dacă proxy-ul returnează 407, credențialele trebuie puse pe proxy.

Încă o capcană: HttpClientHandler.PreAuthenticate controlează pre-autentificarea pentru autentificarea la serverul țintă. Nu controlează headerul Proxy-Authorization. Nu-l folosi ca soluție pentru 407.

Cum rotești proxy-urile cu HttpClient în C#

Dezvoltatorii întreabă asta constant pe forumuri. Răspunsul e, la început, dezamăgitor: nu poți schimba proxy-ul unei instanțe HttpClient deja active. Proxy-ul trăiește pe handler. Handlerul este setat la construirea obiectului. HttpClient nu expune o proprietate mutabilă Proxy.

Soluția naivă — new HttpClient(new HttpClientHandler { Proxy = ... }) la fiecare cerere — creează o altă problemă. Microsoft avertizează explicit că crearea și distrugerea unui client pentru fiecare cerere poate epuiza porturile TCP disponibile, deoarece porturile nu se eliberează imediat după închiderea conexiunii.

Așadar, iată trei modele de producție care chiar funcționează.

Opțiunea 1: Named clients prin IHttpClientFactory

Dacă setul de proxy-uri e cunoscut la pornire, named clients sunt opțiunea cu cea mai mică complexitate. Fiecare client denumit primește propria configurație de handler, iar aplicația îl rezolvă după nume la 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
    });

// La momentul cererii:
var client = httpClientFactory.CreateClient("proxy-us");

Factory-ul gestionează durata de viață a handlerelor și evită anti-pattern-ul clientului creat per cerere.

Opțiunea 2: SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)

Pentru un client de lungă durată în spatele unui proxy gateway care rotește IP-ul de ieșire la conexiuni noi, PooledConnectionLifetime forțează recrearea conexiunilor după o durată configurată.

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

Asta nu schimbă magic obiectul Proxy per cerere. Funcționează cel mai bine cu gateway-uri de proxy care alocă un IP de ieșire diferit la fiecare conexiune TCP nouă sau cu pool-uri de proxy bazate pe DNS, unde hostname-ul rezolvă către endpoint-uri diferite în timp.

Opțiunea 3: DelegatingHandler personalizat pentru selecție avansată de proxy

Când alegerea proxy-ului depinde de URL-ul cererii, payload sau contextul de runtime, un handler de rutare personalizat poate inspecta fiecare cerere și o poate direcționa către pipeline-ul corect de handler intern.

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

Asta e un design avansat. Thread safety, disposal, reutilizarea handlerelor, comportamentul retry și logging-ul devin responsabilitatea ta. L-aș recomanda doar când primele două opțiuni chiar nu se potrivesc.

Comparație între cele trei abordări

Abordare	Complexitate	Versiune .NET	Thread Safety	Overhead
Named clients (IHttpClientFactory)	Mică	.NET Core 2.1+	Ridicată (config imuabilă)	Mic
SocketsHttpHandler + PooledConnectionLifetime	Medie	.NET 6+	Ridicată	Mic
DelegatingHandler personalizat	Mare	Oricare	Depinde de implementare	Mediu

Pentru majoritatea echipelor, named clients sunt punctul de pornire potrivit. Treci la PooledConnectionLifetime pentru gateway-uri de rotație stabile, iar rutarea personalizată doar când alegerea proxy-ului depinde de metadate la nivel de cerere.

Alegerea protocolului proxy potrivit: HTTP, HTTPS și SOCKS5

Nu toate proxy-urile vorbesc aceeași limbă, iar folosirea schemei greșite îți va da erori confuze.

Proxy HTTP: înțelege cereri HTTP. Pentru ținte HTTP simple, poate redirecționa direct cererile. Pentru ținte HTTPS, clientul trimite o cerere CONNECT ca să creeze un tunel, apoi TLS se negociază prin acel tunel cu destinația. ăsta e cel mai comun model.

Proxy cu terminare HTTPS: proxy-ul prezintă propriul certificat TLS și re-criptează traficul către upstream. Îl întâlnești în sistemele enterprise de inspectare și în unele API-uri gestionate de scraping. Poate declanșa erori de validare a certificatului dacă clientul nu are încredere în lanțul de certificate al proxy-ului.

Proxy SOCKS5: un tunel TCP la nivel de transport care funcționează pentru orice trafic TCP, nu doar pentru HTTP. Folosit frecvent de furnizorii de proxy rezidențiali. Suportat nativ în .NET 6+.

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

O notă despre validarea certificatului SSL

Când folosești proxy-uri cu terminare HTTPS, e posibil să vezi erori RemoteCertificateNameMismatch. ServerCertificateCustomValidationCallback poate personaliza validarea:

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

Folosește asta doar în dezvoltare locală sau cu un proxy TLS-intercepting de încredere și aprobat. Dacă returnezi orbește true, dezactivezi o verificare de securitate critică și te expui atacurilor man-in-the-middle. În producție, cu proxy-uri standard CONNECT sau SOCKS, păstrează validarea SSL activă.

Depanarea celor mai comune erori de proxy în C# HttpClient

Tabelul ăsta leagă simptomul vizibil de cauza probabilă și de prima soluție care merită încercată. Merită să-l salvezi la favorite — acoperă erorile care apar cel mai des în thread-urile de pe Stack Overflow și în forumurile de dezvoltatori.

Eroare / Simptom	Cauză comună	Soluție
407 Proxy Authentication Required	Credențialele au fost setate pe handler.Credentials în loc de handler.Proxy.Credentials; format greșit al username-ului; caractere speciale în parola introdusă în URL	Folosește WebProxy.Credentials = new NetworkCredential(...); evită includerea credențialelor în URI; verifică formatul username-ului cerut de furnizor
TaskCanceledException / Timeout	Endpoint-ul proxy e lent, inaccesibil, suprasolicitat sau blocat de firewall; timeout-ul implicit de 100s e prea scurt	Testează proxy-ul cu curl; mărește HttpClient.Timeout doar după ce ai confirmat că endpoint-ul funcționează; adaugă retry-uri și health checks pentru proxy
SocketException / epuizare socket-uri	Crearea și distrugerea lui HttpClient sau a handlerelor la fiecare cerere	Folosește IHttpClientFactory, clienți singleton sau SocketsHttpHandler cu controale de pooling
SSL RemoteCertificateNameMismatch	Interceptare HTTPS de către un proxy corporate sau gestionat	Instalează/ai încredere în CA-ul proxy-ului unde e cazul; folosește validare personalizată doar în medii de dev controlate sau scenarii MITM aprobate
Buclă de redirectare 302	Pagină captive de proxy/VPN corporate sau blocare de allowlist care redirecționează repetat	Testează conexiunea directă; inspectează headerele Location; verifică allowlist-ul proxy-ului și portalul de autentificare
HttpRequestException / fără conexiune cu URL SOCKS	Rulezi cod SOCKS pe .NET Framework sau pe un .NET mai vechi; schemă ori port greșit	Folosește .NET 6+ pentru suport SOCKS nativ; verifică socks5://host:port; testează conform documentației furnizorului
Proxy-ul pare ignorat	UseProxy = false; ținta e ocolită ca locală; variabila de mediu NO_PROXY; handler configurat altfel decât te aștepți	Setează UseProxy = true; inspectează HttpClient.DefaultProxy; golește sau suprascrie variabilele de mediu; setează BypassProxyOnLocal = false

Flux rapid de depanare

1. Cererea a reușit? → Da: compară output-ul de la api.ipify.org cu IP-ul proxy-ului așteptat.
2. Nu, există un cod HTTP? → 407: repară credențialele proxy-ului. 403/429: serverul țintă a blocat sau a limitat rata pentru proxy. Buclă 3xx: proxy-ul sau gateway-ul corporativ poate face redirect.
3. Nu există cod, doar excepție? → Timeout: testează dacă proxy-ul e accesibil. Excepție de socket/certificat: verifică pooling-ul, protocolul, TLS și versiunea .NET.

Comenzi utile pentru a valida proxy-ul în afara .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/

Dacă curl funcționează, dar codul tău C# nu, diferența e de obicei la schemele de autentificare, trust store-ul TLS, variabilele de mediu sau escaparea credențialelor. Potrivește exact URL-ul proxy-ului, schema și autentificarea din curl, apoi mută credențialele în NetworkCredential.

Când să renunți la gestionarea proxy-urilor: alternativa no-code

O parte importantă dintre dezvoltatorii care caută „HttpClient proxy C#” nu încearcă să învețe teoria proxy-urilor — încearcă să țină un scraper în funcțiune. Merită să fim sinceri despre când codul C# custom cu proxy este instrumentul potrivit și când nu este.

Construiește un scraper C# custom cu rotație de proxy când:

• ai nevoie de control total asupra logicii de cerere, cookie-urilor, headerelor, retry-urilor și parsării
• scraperul se integrează într-o bază de cod .NET existentă sau într-un serviciu intern
• cerințele de conformitate sau securitate îți impun să deții infrastructura cap-coadă

Folosește un instrument no-code precum Thunderbit când:

• scopul este extragerea de date structurate de pe site-uri, nu infrastructura HTTP
• nu vrei să întreții pool-uri de proxy, să gestionezi CAPTCHAs sau să depanezi epuizarea socketurilor
• echipa are nevoie de date în Excel, Google Sheets, Airtable sau Notion fără să scrie cod de parsare

Extensia Chrome de la Thunderbit gestionează automat rotația proxy-urilor și măsurile anti-bot prin opțiunea sa de cloud scraping. API-ul le permite dezvoltatorilor să definească o schemă JSON și să primească date structurate înapoi fără să gestioneze deloc HttpClient sau WebProxy. Pentru echipe care fac web scraping pentru comparații de preț sau extragere de lead-uri, diferența de timp de configurare e semnificativă.

Scenariu	C# custom + proxy	Thunderbit
Control total asupra logicii de cerere	Da	Nu (control la nivel de API)
Gestionarea proxy-urilor necesară	Da	Nu (gestionată automat)
Tratare anti-bot / CAPTCHA	Manual sau prin terți	Integrată
Timp de configurare	Ore până la zile	Minute
Cel mai potrivit pentru	Baze de cod .NET existente, pipeline-uri custom	Extragere rapidă de date, echipe non-tehnice, exporturi în spreadsheet

Asta nu înseamnă „nu folosi niciodată HttpClient”. Dacă construiești un serviciu .NET de producție, trebuie absolut să înțelegi configurarea proxy-ului. Dar dacă petreci ore întregi depanând erori 407 pentru o sarcină unică de colectare de date, există opțiuni mai simple — și nu e nicio rușine să le folosești. Poți explora prețurile Thunderbit sau poți vedea canalul YouTube pentru tutoriale.

Idei esențiale

Modelul de bază rămâne același: WebProxy → handler → HttpClient. Tot ce urmează ține de evitarea greșelilor operaționale care apar în producție.

• Credențialele se pun pe proxy, nu pe handler. Fragmentul din secțiunea 407 e cel mai important lucru de reținut.
• Nu crea un HttpClient nou la fiecare cerere sau pentru fiecare proxy. Folosește IHttpClientFactory pentru named clients, SocketsHttpHandler cu PooledConnectionLifetime pentru gateway-uri rotative sau un handler de rutare personalizat pentru scenarii avansate.
• Verifică versiunea .NET înainte să copiezi cod SOCKS5 sau SocketsHttpHandler. Tabelul de compatibilitate de mai sus te scapă de eșecuri tăcute.
• Testează proxy-ul în afara .NET mai întâi. O comandă rapidă curl elimină o categorie întreagă de depanări.
• Pentru extragerea de date structurate fără bătăi de cap cu proxy-ul, instrumente precum Thunderbit gestionează stratul de transport, ca tu să te poți concentra pe date.

Data viitoare când întâlnești un 407 sau o TaskCanceledException, începe cu tabelul de depanare de mai sus.

Întrebări frecvente

Pot schimba proxy-ul unei instanțe HttpClient deja existente?

Nu. Proxy-ul este legat de handler, iar handlerul este setat la construire. HttpClient nu expune o proprietate mutabilă Proxy. Pentru proxy-uri diferite, creează handleri și clienți separați și gestionează-i cu named clients din IHttpClientFactory sau cu un pool de clienți preconfigurați.

Folosește HttpClient proxy-ul sistemului în mod implicit?

Da. În .NET modern, dacă nu setezi explicit un handler, HttpClient moștenește setările implicite de proxy ale sistemului — inclusiv variabile de mediu precum HTTPS_PROXY și HTTP_PROXY prin HttpClient.DefaultProxy. Ca să ieși din acest comportament, setează explicit UseProxy = false pe handler.

Cum folosesc un proxy SOCKS5 cu HttpClient în C#?

Folosește new WebProxy("socks5://host:port") împreună cu SocketsHttpHandler. Suportul nativ pentru proxy SOCKS necesită .NET 6 sau mai nou. În .NET Framework 4.x, SOCKS5 nu este suportat nativ — ai avea nevoie de o bibliotecă terță parte.

De ce primesc mereu 407 Proxy Authentication Required?

Cel mai probabil, setezi credențialele pe handler.Credentials (care se adresează serverului destinație) în loc de handler.Proxy.Credentials (care se adresează proxy-ului). Vezi secțiunea „Credențiale pentru proxy vs. credențiale pentru server” de mai sus pentru modelul corect.

Este sigur să dezactivez validarea certificatului SSL când folosesc un proxy?

Doar în dezvoltare locală sau atunci când ai încredere deplină în furnizorul de proxy (de exemplu, un API de scraping gestionat în mod proxy HTTPS). În producție, cu proxy-uri standard CONNECT sau SOCKS, păstrează validarea SSL activă ca să previi atacurile man-in-the-middle.

Încearcă Thunderbit pentru web scraping fără efort Get Started Free

Află mai mult

• Cele mai bune instrumente automate de web scraping
• Cum să creezi un web scraper
• Cele mai bune servicii de web scraping
• Cel mai bun limbaj pentru web scraping
• Web scraping fără să fii blocat