SOCKS-Proxien an .NET HttpClient: ënnerstëtzt URI-Schemen

Benotzt déi dokumentéiert SOCKS-Proxy-URI-Schemen vun engem kompatibelen .NET HTTP-Handler, amplaz unzehuelen, datt al Rezepter vun Drëtten nach néideg sinn.

Al Äntwerten empfelen en zousätzlechen SOCKS-Handler, well se op eng eeler .NET-Netzwierkstack zielen. Eng modern ënnerstëtzt .NET HTTP-Stack kann déi dokumentéiert SOCKS-Proxy-URI-Schemen benotzen.

var handler = new HttpClientHandler
{
    Proxy = new WebProxy("socks5://203.0.113.10:1080"),
    UseProxy = true
};
using var client = new HttpClient(handler);

Den Endpunkt ass just illustrativ. D'SOCKS5-Proxy-Lëscht bitt ëffentlech Kandidaten fir dës socks5 WebProxy-URI; benotzt d'Versioun, déi den tatsächlechen Handler ënnerstëtzt. Iwwerpréift den Zilframework, d'Laufzäit, d'Plattform an den tatsächlechen Handler, deen d'Applikatioun benotzt, ier Dir dëst Beispill op en eelere .NET Framework-Prozess uwent.

Déi aktuell Proxy-Dokumentatioun vu Microsoft listet socks4, socks4a a socks5 op. Dës Nimm beschreiwen d'Verhalen vum Protokoll. Eng Portnummer eleng wielt net d'SOCKS-Versioun, an d'Schreifweis socks5h vu curl ass keen universellen URI-Schema, deen all Client akzeptéiert.

Fir en authentifizéierte SOCKS5-Service konfiguréiert d'Zougangsdaten no der Schnëttstell, déi den Handler ënnerstëtzt. SOCKS4 a SOCKS4a bidden net dee selwechte Passwuert-Authentifikatiounsmechanismus.

D'Destinatiouns-URL bleift onverännert. Eng HTTPS-Ufro stellt an iwwerpréift nach ëmmer den TLS vun der Destinatioun iwwer de Proxy-Wee; SOCKS derbäizesetzen ass kee Grond, déi Iwwerpréiwung auszeschalten.

Ähnlech Artikelen