Socket.SendTimeout не го ограничува обидот за прокси врска
Ограничете ја проверката на прокси портата при воспоставување на врската наместо да поставувате timeout што важи само за испраќање податоци.
Проверувачот на прокси поставува SendTimeout = 200, го повикува Connect и чека многу подолго од очекуваното. Timeout-от е врзан за операција до која проверувачот сè уште не стигнал.
Socket.SendTimeout ги контролира синхроните испраќања. Не му дава на синхрон обид за врска рок од 200 ms. Додавањето сон пред Connect додава само уште едно доцнење.
Откажете ја операцијата што чека
На современа .NET цел што го нуди откажливиот overload, асинхроната проверка може да го примени својот буџет на воспоставувањето на врската:
using var budget = new CancellationTokenSource(TimeSpan.FromSeconds(2));
using var client = new TcpClient();
await client.ConnectAsync(proxyHost, proxyPort, budget.Token);
Фрагментот припаѓа во async метод, а хостот и портата на проксито ги дава повикувачот; јавен кандидат од список со прокси може да ги даде тие два влеза. Откажувањето обработувајте го одделно од socket грешка ако проверувачот наведува причини за неуспех. Ослободувањето на клиентот исто така спречува завршените проверки да собираат socket-и.
Постариот .NET Framework код ги нема сите современи overload-и. Користете поддржан асинхрон распоред на врска и експлицитно затворете го socket-от кога се откажувате од обидот. Самото запирање на вашето чекање не докажува дека основната операција запрела.
Зелениот резултат е сè уште мал резултат
Успешна TCP врска докажува дека овој клиент стигнал до крајна точка што слуша. Таа не преговарала SOCKS, не се автентицирала на HTTP прокси, не отворила CONNECT ниту го примила саканиот одговор на веб-страницата.
Дајте им на тие подоцнежни фази сопствено ограничено ракување или проведете низ нив намерен вкупен рок. Инаку поправениот тајмер за врска може совршено да работи додека проверувачот троши уште една минута чекајќи прокси ракување.