Старыя адказы раяць дадатковы SOCKS-апрацоўшчык, бо яны накіраваны на старэйшы сеткавы стек .NET. Сучасны падтрыманы HTTP-стек .NET можа выкарыстоўваць дакументаваныя схемы URI SOCKS-проксі.

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

Канчатковы пункт прыведзены для прыкладу. Спіс SOCKS5-проксі прапануе публічныя кандыдаты для гэтага socks5 WebProxy URI; выкарыстоўвайце версію, якую падтрымлівае фактычны апрацоўшчык. Праверце мэтавую платформу, асяроддзе выканання, платформу і фактычны апрацоўшчык, які выкарыстоўвае праграма, перш чым ужываць гэты прыклад да старога працэсу .NET Framework.

Бягучая дакументацыя Microsoft па проксі пералічвае socks4, socks4a і socks5. Гэтыя назвы апісваюць паводзіны пратаколу. Адзін нумар порта не выбірае версію SOCKS, і напісанне socks5h у curl не з'яўляецца ўніверсальнай схемай URI, якую прымае кожны кліент.

Для аўтэнтыфікаванай службы SOCKS5 наладзьце ўліковыя даныя згодна з інтэрфейсам, які падтрымлівае апрацоўшчык. SOCKS4 і SOCKS4a не прадастаўляюць такі ж механізм аўтэнтыфікацыі па паролі.

URL прызначэння застаецца нязменным. Запыт HTTPS па-ранейшаму ўсталёўвае і правярае TLS прызначэння праз шлях проксі; даданне SOCKS не з'яўляецца прычынай адключаць гэтую праверку.

Падобныя артыкулы