La settimana scorsa ho perso una quantità imbarazzante di tempo fissando una risposta 407 Proxy Authentication Required, convinto che il mio provider proxy avesse qualche problema. In realtà avevo messo le credenziali nella proprietà sbagliata: una correzione di due righe che mi è costata due ore per trovarla. Se ti sembra una scena già vista, questa guida fa proprio per te.
La configurazione del proxy con HttpClient in C# è uno di quegli argomenti in cui il pattern di base è semplice, ma i problemi di produzione — esaurimento dei socket, differenze tra implementazioni SOCKS5, confusione sulle credenziali — finiscono per farti perdere un sacco di tempo.
Lavoro da tempo con strumenti di web scraping ed estrazione dati in Thunderbit, e ho visto gli stessi errori ripetersi più e più volte, sia nelle discussioni del nostro team engineering sia nelle community di sviluppatori che seguiamo. In questa guida vedremo tutto il percorso: configurazione, autenticazione, rotazione dei proxy, scelta del protocollo e una tabella di troubleshooting che avrei voluto avere il primo giorno.
Difficoltà: Da principiante a intermedio
Tempo necessario: ~15 minuti per seguire gli esempi, di più per i pattern di rotazione in produzione
Cosa ti serve: SDK .NET 6+ (per SOCKS5 e le funzionalità moderne degli handler; .NET Framework 4.x va bene per i casi base con proxy HTTP), un editor di codice e almeno un endpoint proxy da testare
Cos’è HttpClient e perché ha bisogno di un proxy?
HttpClient è la classe integrata di .NET in System.Net.Http per inviare richieste HTTP e ricevere risposte. Supporta async/await, header personalizzati, cancellation token e configurazione basata su handler. Microsoft lo descrive come una classe per inviare richieste HTTP e ricevere risposte HTTP da una risorsa identificata da un URI.
Un server proxy è un intermediario che si mette tra la tua applicazione e il sito di destinazione. Quando instradi il traffico attraverso un proxy, il sito vede l’IP del proxy invece del tuo.
HttpClient da solo non ha una proprietà Proxy. Il routing tramite proxy si configura nell’handler sottostante — HttpClientHandler oppure SocketsHttpHandler — che accetta un’istanza di WebProxy. Il modello mentale è questo:
[La tua app C#] → [HttpClient + Handler] → [Server Proxy] → [Sito di destinazione]
Ecco perché “cambiare il proxy su un HttpClient già attivo” è un problema di architettura, non una semplice assegnazione di proprietà. Ne parliamo meglio nella sezione sulla rotazione.
Prova Thunderbit per estrarre dati più facilmente
Perché usare un proxy con HttpClient in C#
Gli sviluppatori instradano il traffico di HttpClient tramite proxy per varie esigenze ricorrenti, e il tipo di proxy giusto dipende dall’obiettivo.
- Evitare blocchi IP e limiti di velocità: fondamentale per web scraping, lead generation o monitoraggio prezzi su larga scala. Un singolo IP che martella un sito viene bloccato in fretta.
- Aggirare restrizioni geografiche: accedi ad API o contenuti bloccati per area passando da proxy in paesi specifici.
- Nascondere l’IP di origine: aggiungi un livello di privacy per raccolta dati sensibili o ricerche competitive.
- Requisiti aziendali o di compliance: molte aziende impongono che il traffico in uscita passi da un gateway centralizzato per logging e governance.
- Testing e QA: simula richieste da luoghi o condizioni di rete diverse senza dover distribuire infrastruttura in quelle aree.
| Caso d’uso | Scelta proxy tipica | Perché è adatto |
|---|---|---|
| Web scraping su larga scala | Proxy residenziali rotanti | Più diversità di IP, più difficile da classificare per i sistemi anti-bot |
| Monitoraggio prezzi e-commerce | Proxy residenziali o datacenter geo-targetizzati | Controlli su prezzi e disponibilità specifici per area |
| Accesso API tramite gateway fisso | Proxy datacenter o proxy aziendale | Allowlist IP prevedibile, costo più basso |
| Compliance aziendale | Proxy di sistema, proxy PAC, proxy aziendale autenticato | Logging centralizzato e controllo del traffico in uscita |
| QA e test di localizzazione | Pool di proxy specifici per paese | Simula l’accesso reale da regioni target |
L’uso dei proxy evolve anche in fasi abbastanza prevedibili. Si parte con un singolo proxy statico per verificare il routing. Uno scraper in produzione passa poi a un pool, associando le richieste ai proxy in base al dominio di destinazione, all’area geografica o al tasso di errore. I team più maturi spesso adottano un proxy gateway gestito, dove rotazione, retry e session affinity vengono gestiti dietro un unico endpoint.
La rotazione dei proxy non è una soluzione magica. Se un sito blocca comportamenti sospetti, cambiare IP aiuta solo se anche ritmo delle richieste, header, cookie e fingerprint TLS sono gestiti con attenzione.
Quale versione .NET supporta cosa: una rapida matrice di compatibilità
Copiare uno snippet proxy da un blog nel target framework sbagliato è una delle principali cause di errori silenziosi. La distinzione più importante è tra .NET Framework 4.x e .NET moderno (.NET 6+). Ecco cosa funziona e dove:
| Funzionalità | .NET Framework 4.x | .NET 6 | .NET 7 | .NET 8–9 |
|---|---|---|---|---|
WebProxy + HttpClientHandler | Sì | Sì | Sì | Sì |
SOCKS5 tramite WebProxy("socks5://...") | No | Sì (aggiunto in .NET 6) | Sì | Sì |
SocketsHttpHandler (handler predefinito) | No | Sì | Sì | Sì |
HttpClient.DefaultProxy statico | No | Sì | Sì | Sì |
PooledConnectionLifetime | No | Sì | Sì | Sì |
Se lavori su .NET Framework 4.x, resta su proxy HTTP/HTTPS con HttpClientHandler e WebProxy. SOCKS5 e i controlli moderni sul pooling richiedono .NET 6 o successivo.
Un comportamento sottile da tenere d’occhio: HttpClient.DefaultProxy è una proprietà statica nel .NET moderno. Se viene impostata in codice di startup condiviso o ereditata da variabili d’ambiente come HTTPS_PROXY o HTTP_PROXY, ogni istanza di HttpClient la userà, a meno che tu non la sovrascriva esplicitamente nell’handler. Nei deployment containerizzati, questa è una causa molto comune del classico “perché il mio client sta usando un proxy che non ho mai configurato?”.
Passo 1: crea un nuovo progetto console C#
Apri il terminale e crea un nuovo progetto:
dotnet new console -n ProxyHttpClientDemo
cd ProxyHttpClientDemo
Controlla la versione dell’SDK con dotnet --version. Gli esempi di questa guida si basano su .NET 6+ per coprire tutte le funzionalità. Se ti serve l’ultima LTS, scaricala dalla pagina download di Microsoft.
Apri Program.cs nel tuo editor. È lì che succede tutto.
Passo 2: fai una richiesta HTTP di base (senza proxy)
Prima di configurare un proxy, identifica il tuo IP di uscita reale. Così, una volta attivato il proxy, puoi verificare subito che l’IP sia davvero cambiato.
using System.Net.Http;
using var client = new HttpClient();
var ip = await client.GetStringAsync("https://api.ipify.org/");
Console.WriteLine($"Direct IP: {ip}");
Esegui il codice. Dovresti vedere il tuo attuale indirizzo IP pubblico, per esempio:
Direct IP: 203.0.113.10
Tienilo da parte. Nel passaggio successivo dovrebbe essere diverso.
Passo 3: configura un WebProxy con HttpClientHandler
Il pattern classico prevede tre oggetti: un WebProxy, un handler e il 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}");
Sostituisci proxy.example.com:8080 con il tuo endpoint proxy reale. Se tutto è configurato bene, l’IP restituito dovrebbe corrispondere all’IP di uscita del proxy, non al tuo reale.
Proprietà chiave da capire:
Proxy— l’istanzaIWebProxyusata dall’handler per il routing.UseProxy = true— dice all’handler di usare davvero il proxy configurato. Sembra banale, ma dimenticarlo fa perdere parecchio tempo in debug.BypassProxyOnLocal = false— impedisce all’handler di saltare il proxy per destinazioni che sembrano “locali”.UseDefaultCredentials— controlla se l’handler invia le credenziali predefinite di Windows. Non è la stessa cosa di username/password del proxy.
Passo 4: aggiungi l’autenticazione del proxy con NetworkCredential
La maggior parte dei provider proxy a pagamento richiede credenziali. Il pattern corretto consiste nell’impostarle direttamente sull’oggetto 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}");
Molti provider offrono un formato URL come http://username:password@host:port. Nel codice .NET, però, è meglio usare NetworkCredential invece di incorporare le credenziali nella stringa URI. Così eviti problemi di escaping con caratteri speciali nella password e tieni separati in modo esplicito URI e credenziali.
Più avanti vedremo l’errore di autenticazione più comune — e perché genera errori 407 — in una sezione dedicata.
Passo 5: esporta o usa i dati della risposta
Per qualsiasi cosa vada oltre un rapido controllo IP, gestisci correttamente la risposta:
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);
Nei flussi di scraping, la richiesta tramite proxy è solo il livello di trasporto. Servono comunque parsing, normalizzazione, deduplicazione, retry ed export verso Excel, Google Sheets, database o altre destinazioni. Strumenti come Thunderbit possono automatizzare le fasi di estrazione ed export: la sua estensione Chrome gestisce l’estrazione di dati strutturati e l’export gratuito verso Google Sheets, Excel, Airtable o Notion senza dover scrivere codice di parsing.
Esporta i dati estratti in Excel, Sheets, Airtable o Notion Get Started Free
Credenziali del proxy vs credenziali del server: l’errore che causa i 407
Ho visto questo errore nei thread di Stack Overflow, nei post di Microsoft Q&A e — lo ammetto — anche nel mio codice.
La distinzione è semplice, ma facile da confondere:
- Le credenziali del proxy ti autenticano sul server proxy stesso.
- Le credenziali del server ti autenticano sul server di destinazione.
In HttpClientHandler queste informazioni stanno su proprietà diverse. Impostare le credenziali sulla proprietà sbagliata è la prima causa degli errori 407 Proxy Authentication Required.
// ❌ SBAGLIATO — imposta le credenziali del server di destinazione, non del proxy
handler.Credentials = new NetworkCredential("user", "pass");
// ✅ CORRETTO — imposta le credenziali direttamente sull’oggetto proxy
handler.Proxy = new WebProxy("http://proxy:8080")
{
Credentials = new NetworkCredential("user", "pass")
};
HttpClientHandler.Credentials si riferisce al server di destinazione. WebProxy.Credentials si riferisce al proxy. Se il proxy restituisce 407, le credenziali vanno sul proxy.
Un’altra trappola: HttpClientHandler.PreAuthenticate controlla il comportamento di pre-autenticazione per l’autenticazione del server di destinazione. Non controlla l’header Proxy-Authorization. Non usarlo come soluzione ai 407.
Come ruotare i proxy con HttpClient in C#
Gli sviluppatori chiedono continuamente questo tema nei forum. La prima risposta è deludente: non puoi cambiare il proxy su un’istanza HttpClient già in uso. Il proxy vive nell’handler. L’handler viene definito al momento della creazione. HttpClient non espone una proprietà Proxy modificabile.
La soluzione ingenua — new HttpClient(new HttpClientHandler { Proxy = ... }) per ogni richiesta — crea un altro problema. Microsoft avverte esplicitamente che creare e distruggere client per ogni richiesta può esaurire le porte TCP disponibili, perché le porte non vengono rilasciate subito dopo la chiusura della connessione.
Ecco quindi tre pattern validi in produzione.
Opzione 1: client nominati tramite IHttpClientFactory
Se il set di proxy è noto all’avvio, i client nominati sono l’opzione più semplice. Ogni client nominato ha la propria configurazione dell’handler, e il codice applicativo lo recupera per nome a 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
});
// Al momento della richiesta:
var client = httpClientFactory.CreateClient("proxy-us");
La factory gestisce la durata degli handler ed evita l’antipattern del client creato per ogni richiesta.
Opzione 2: SocketsHttpHandler + PooledConnectionLifetime (.NET 6+)
Per un client a lunga vita dietro un proxy gateway che ruota gli IP di uscita su nuove connessioni, PooledConnectionLifetime forza la ricreazione delle connessioni dopo un intervallo configurato.
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);
Questo non cambia magicamente l’oggetto Proxy a ogni richiesta. Funziona meglio con gateway proxy che assegnano un IP di uscita diverso a ogni nuova connessione TCP, oppure con pool di proxy basati su DNS in cui l’hostname risolve su endpoint diversi nel tempo.
Opzione 3: DelegatingHandler personalizzato per selezione avanzata del proxy
Quando la scelta del proxy dipende dall’URL della richiesta, dal payload o dal contesto di runtime, un handler di routing personalizzato può ispezionare ogni richiesta e inoltrarla al corretto pipeline di handler interni.
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);
}
}
Si tratta di una soluzione avanzata. Thread safety, disposal, riuso degli handler, comportamento dei retry e logging diventano responsabilità tua. La consiglierei solo se le prime due opzioni non si adattano davvero.
Confronto tra i tre approcci
| Approccio | Complessità | Versione .NET | Thread safety | Overhead |
|---|---|---|---|---|
| Client nominati (IHttpClientFactory) | Bassa | .NET Core 2.1+ | Alta (config immutabile) | Basso |
| SocketsHttpHandler + PooledConnectionLifetime | Media | .NET 6+ | Alta | Basso |
| DelegatingHandler personalizzato | Alta | Qualsiasi | Dipende dall’implementazione | Medio |
Per la maggior parte dei team, i client nominati sono il punto di partenza giusto. Passa a PooledConnectionLifetime per gateway di rotazione stabili, e usa il routing personalizzato solo quando la scelta del proxy dipende da metadati della singola richiesta.
Scegliere il protocollo proxy giusto: HTTP, HTTPS e SOCKS5
Non tutti i proxy parlano lo stesso linguaggio, e usare lo schema sbagliato genera errori poco chiari.
Proxy HTTP: capisce richieste HTTP. Per target HTTP semplici, può inoltrarle direttamente. Per target HTTPS, il client invia una richiesta CONNECT per creare un tunnel, poi il TLS viene negoziato attraverso quel tunnel con il server di destinazione. È il modello più comune.
Proxy HTTPS con terminazione: il proxy presenta il proprio certificato TLS e re-cripta il traffico verso l’upstream. È comune nei sistemi aziendali di ispezione e in alcune API gestite per scraping. Può generare errori di validazione del certificato se il client non si fida della catena certificativa del proxy.
Proxy SOCKS5: un tunnel TCP a livello di trasporto che funziona per qualsiasi traffico TCP, non solo HTTP. Molto usato dai provider di proxy residenziali. Supportato nativamente in .NET 6+.
Esempio 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);
Una nota sulla validazione dei certificati SSL
Quando usi proxy HTTPS con terminazione, potresti vedere errori RemoteCertificateNameMismatch. Il ServerCertificateCustomValidationCallback permette di personalizzare la validazione:
var handler = new HttpClientHandler
{
ServerCertificateCustomValidationCallback =
HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
};
Usalo solo in sviluppo locale o con un proxy TLS-intercepting fidato e approvato. Restituire sempre true disattiva un controllo di sicurezza critico e ti espone ad attacchi man-in-the-middle. In produzione, con proxy standard CONNECT o SOCKS, lascia attiva la validazione SSL.
Troubleshooting degli errori proxy più comuni in C# HttpClient
Questa tabella associa il sintomo visibile alla causa più probabile e alla prima correzione da provare. Ti consiglio di salvarla: copre gli errori che compaiono più spesso nei thread di Stack Overflow e nei forum degli sviluppatori.
| Errore / sintomo | Causa comune | Correzione |
|---|---|---|
| 407 Proxy Authentication Required | Credenziali impostate su handler.Credentials invece che su handler.Proxy.Credentials; formato username errato; caratteri speciali nella password incorporata nell’URL | Usa WebProxy.Credentials = new NetworkCredential(...); evita di incorporare credenziali nell’URI; verifica il formato username richiesto dal provider |
| TaskCanceledException / Timeout | Endpoint proxy lento, irraggiungibile, sovraccarico o bloccato dal firewall; timeout predefinito di 100s troppo breve | Testa il proxy con curl; aumenta HttpClient.Timeout solo dopo aver verificato che l’endpoint funzioni; aggiungi retry e controlli di salute del proxy |
| SocketException / esaurimento socket | Creazione e distruzione di HttpClient o handler per ogni richiesta | Usa IHttpClientFactory, client singleton oppure SocketsHttpHandler con controlli di pooling |
| SSL RemoteCertificateNameMismatch | Intercettazione HTTPS da parte di proxy aziendali o gestiti | Installa/fida della CA del proxy dove appropriato; usa la validazione personalizzata solo in sviluppo controllato o in scenari MITM approvati |
| Loop di redirect 302 | Pagina captive del proxy/VPN aziendale o blocco da allowlist che reindirizza ripetutamente | Testa la connessione diretta; ispeziona gli header Location; controlla allowlist e portale di autenticazione del proxy |
| HttpRequestException / nessuna connessione con URL SOCKS | Codice SOCKS eseguito su .NET Framework o .NET più vecchio; schema o porta errati | Usa .NET 6+ per il supporto SOCKS nativo; verifica socks5://host:port; prova con la documentazione del provider |
| Il proxy sembra ignorato | UseProxy = false; destinazione bypassata perché considerata locale; variabile d’ambiente NO_PROXY; handler configurato in modo diverso dal previsto | Imposta UseProxy = true; controlla HttpClient.DefaultProxy; svuota o sovrascrivi le variabili d’ambiente; imposta BypassProxyOnLocal = false |
Flusso rapido di debug
- La richiesta è andata a buon fine? → Sì: confronta l’output di
api.ipify.orgcon l’IP proxy atteso. - No, c’è un codice HTTP? → 407: correggi le credenziali del proxy. 403/429: il target ha bloccato o limitato il proxy. Loop 3xx: il proxy o il gateway aziendale potrebbe reindirizzare.
- Nessun codice HTTP, solo un’eccezione? → Timeout: verifica la raggiungibilità del proxy. Eccezione socket/certificato: controlla pooling, protocollo, TLS e versione .NET.
Comandi utili per validare il proxy fuori da .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/
Se curl funziona ma il codice C# no, la differenza di solito sta nello schema di autenticazione, nel trust store TLS, nelle variabili d’ambiente o nell’escaping delle credenziali. Allinea esattamente URL proxy, schema e autenticazione di curl, poi sposta le credenziali in NetworkCredential.
Quando evitare la gestione manuale dei proxy: l’alternativa no-code
Una parte significativa degli sviluppatori che cercano “HttpClient proxy C#” non sta davvero cercando di studiare la teoria dei proxy: sta cercando di far stare in piedi uno scraper. Vale la pena essere sinceri su quando il codice C# personalizzato è lo strumento giusto e quando no.
Costruisci uno scraper C# personalizzato con rotazione proxy quando:
- ti serve pieno controllo sulla logica delle richieste, cookie, header, retry e parsing
- lo scraper deve integrarsi in una codebase .NET esistente o in un servizio interno
- i requisiti di compliance o sicurezza impongono che tu gestisca l’infrastruttura end-to-end
Usa uno strumento no-code come Thunderbit quando:
- l’obiettivo è estrarre dati strutturati da siti web, non gestire infrastruttura HTTP
- preferisci non mantenere pool di proxy, gestire CAPTCHA o debuggare esaurimenti di socket
- il team ha bisogno dei dati in Excel, Google Sheets, Airtable o Notion senza scrivere codice di parsing
L’estensione Chrome di Thunderbit gestisce automaticamente la rotazione proxy e le misure anti-bot tramite l’opzione di scraping cloud. La sua API permette agli sviluppatori di definire uno schema JSON e ricevere dati strutturati senza dover gestire HttpClient o WebProxy. Per i team che fanno web scraping per il confronto prezzi o estrazione lead, la differenza nei tempi di setup è enorme.
| Scenario | C# personalizzato + proxy | Thunderbit |
|---|---|---|
| Controllo completo sulla logica delle richieste | Sì | No (controllo a livello API) |
| Gestione proxy richiesta | Sì | No (gestita automaticamente) |
| Gestione anti-bot / CAPTCHA | Manuale o di terze parti | Integrata |
| Tempo di setup | Da ore a giorni | Minuti |
| Ideale per | Codebase .NET esistenti, pipeline personalizzate | Estrazione rapida, team non tecnici, export in fogli di calcolo |
Non è un invito a “non usare mai HttpClient”. Se stai costruendo un servizio .NET in produzione, devi assolutamente conoscere la configurazione dei proxy. Ma se stai perdendo ore a debuggare errori 407 per un’attività una tantum di raccolta dati, esistono opzioni più semplici — e non c’è nulla di male a usarle. Puoi esplorare i prezzi di Thunderbit oppure guardare il canale YouTube per tutorial pratici.
Punti chiave da ricordare
Il pattern di base non cambia: WebProxy → handler → HttpClient. Tutto il resto serve a evitare gli errori operativi che emergono in produzione.
- Le credenziali vanno sul proxy, non sull’handler. Lo snippet affiancato nella sezione sui 407 è la cosa più importante da ricordare.
- Non creare un nuovo
HttpClientper ogni richiesta o per ogni proxy. UsaIHttpClientFactoryper i client nominati,SocketsHttpHandlerconPooledConnectionLifetimeper gateway rotanti, oppure un handler di routing personalizzato per scenari avanzati. - Controlla la tua versione .NET prima di copiare codice SOCKS5 o
SocketsHttpHandler. La matrice di compatibilità sopra ti evita errori silenziosi. - Testa il proxy fuori da .NET prima di tutto. Un rapido comando
curlelimina un’intera categoria di problemi di debug. - Per l’estrazione di dati strutturati senza grattacapi sui proxy, strumenti come Thunderbit gestiscono il livello di trasporto così puoi concentrarti sui dati.
La prossima volta che incontri un 407 o una TaskCanceledException, parti dalla tabella di troubleshooting qui sopra.
FAQ
Posso cambiare il proxy su un’istanza HttpClient già esistente?
No. Il proxy è legato all’handler, e l’handler viene impostato al momento della creazione. HttpClient non espone una proprietà Proxy modificabile. Per usare proxy diversi, crea handler e client separati e gestiscili con client nominati di IHttpClientFactory o con un pool di client preconfigurati.
HttpClient usa il proxy di sistema per impostazione predefinita?
Sì. Nel .NET moderno, se non imposti esplicitamente un handler, HttpClient eredita le impostazioni proxy predefinite del sistema, incluse le variabili d’ambiente come HTTPS_PROXY e HTTP_PROXY tramite HttpClient.DefaultProxy. Per escluderlo, imposta esplicitamente UseProxy = false nell’handler.
Come uso un proxy SOCKS5 con HttpClient in C#?
Usa new WebProxy("socks5://host:port") con SocketsHttpHandler. Il supporto nativo per i proxy SOCKS richiede .NET 6 o successivo. Su .NET Framework 4.x, SOCKS5 non è supportato nativamente: ti servirebbe una libreria di terze parti.
Perché continuo a ricevere 407 Proxy Authentication Required?
Molto probabilmente stai impostando le credenziali su handler.Credentials (che punta al server di destinazione) invece che su handler.Proxy.Credentials (che punta al proxy). Vedi sopra la sezione “Credenziali del proxy vs credenziali del server” per il pattern corretto.
È sicuro disattivare la validazione dei certificati SSL quando uso un proxy?
Solo in sviluppo locale o quando ti fidi completamente del provider proxy (ad esempio un’API di scraping gestita in modalità proxy HTTPS). In produzione, con proxy standard CONNECT o SOCKS, lascia attiva la validazione SSL per prevenire attacchi man-in-the-middle.
Prova Thunderbit per fare web scraping senza sforzo Get Started Free
Scopri di più
