Socket.SendTimeout не ограничава опит за връзка през прокси

Проверяващият прокси задава SendTimeout = 200, извиква Connect и чака много по-дълго от очакваното. Таймаутът е прикачен към операция, до която проверяващият още не е стигнал.

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 метод, като хостът и портът на проксито се подават от извикващия; публичен кандидат от списък с проксита може да предостави тези два входа. Обработвайте отмяната отделно от грешка на сокета, ако проверяващият съобщава причини за неуспех. Освобождаването на клиента също пречи на завършените проверки да трупат сокети.

По-старият код на .NET Framework не разполага с всеки съвременен overload. Използвайте поддържана асинхронна схема за връзка и изрично затваряйте сокета, когато се отказвате от опита. Самото спиране на вашето чакане не доказва, че подлежаща операция е спряла.

Зеленият резултат все още е малък резултат

Успешната TCP връзка доказва, че този клиент е достигнал до слушаща крайна точка. Тя не е договаряла SOCKS, не се е удостоверявала пред HTTP прокси, не е отваряла CONNECT и не е получавала желания отговор на сайта.

Дайте на тези по-късни етапи собствена ограничена обработка или прекарайте през тях умишлен общ краен срок. Иначе поправеният таймер за връзка може да работи безупречно, докато проверяващият прекарва още една минута в чакане на прокси ръкостискане.