Proxy SOCKS in .NET HttpClient: schemi URI supportati
Usa gli schemi URI proxy SOCKS documentati di un gestore HTTP .NET compatibile invece di presumere che le vecchie ricette di terze parti siano ancora necessarie.
Le vecchie risposte consigliano un gestore SOCKS aggiuntivo perché si rivolgono a uno stack di rete .NET più vecchio. Uno stack HTTP .NET moderno e supportato può usare gli schemi URI proxy SOCKS documentati.
var handler = new HttpClientHandler
{
Proxy = new WebProxy("socks5://203.0.113.10:1080"),
UseProxy = true
};
using var client = new HttpClient(handler);L'endpoint è solo illustrativo. L'elenco di proxy SOCKS5 fornisce candidati pubblici per questo URI socks5 di WebProxy; usa la versione supportata dal gestore effettivo. Controlla il framework di destinazione, il runtime, la piattaforma e il gestore effettivo usato dall'applicazione prima di applicare questo esempio a un processo .NET Framework più vecchio.
La documentazione attuale di Microsoft sui proxy elenca socks4, socks4a e socks5. Questi nomi descrivono il comportamento del protocollo. Un numero di porta da solo non sceglie la versione SOCKS, e la grafia socks5h di curl non è uno schema URI universale accettato da ogni client.
Per un servizio SOCKS5 autenticato, configura le credenziali in base all'interfaccia supportata dal gestore. SOCKS4 e SOCKS4a non forniscono lo stesso meccanismo di autenticazione con password.
L'URL di destinazione resta invariato. Una richiesta HTTPS stabilisce e verifica comunque il TLS di destinazione attraverso il percorso del proxy; aggiungere SOCKS non è un motivo per disattivare tale verifica.