Socket.SendTimeout не ограничивает попытку подключения через прокси

Ограничьте проверку порта прокси при установке соединения, а не задавайте тайм-аут, который действует только на отправку данных.

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

Socket.SendTimeout управляет синхронной отправкой. Он не даёт синхронной попытке соединения 200-миллисекундный срок. Сон перед Connect лишь добавляет ещё одну задержку.

Отмените ожидающую операцию

На современной платформе .NET с отменяемой перегрузкой асинхронная проверка может применить свой бюджет к установке соединения:

using var budget = new CancellationTokenSource(TimeSpan.FromSeconds(2));
using var client = new TcpClient();
await client.ConnectAsync(proxyHost, proxyPort, budget.Token);

Фрагмент относится к async-методу, а хост и порт прокси передаёт вызывающий; публичный кандидат из списка прокси может дать эти два входных значения. Обрабатывайте отмену отдельно от ошибки сокета, если проверщик сообщает причины отказа. Освобождение клиента также не даёт завершённым проверкам накапливать сокеты.

Старый код .NET Framework не имеет всех современных перегрузок. Используйте поддерживаемую асинхронную схему соединения и явно закрывайте сокет, когда отказываетесь от попытки. Просто остановить своё ожидание не доказывает, что нижележащая операция остановилась.

Зелёный результат — всё ещё маленький результат

Успешное TCP-соединение доказывает, что этот клиент достиг слушающей конечной точки. Оно не согласовало SOCKS, не прошло проверку подлинности на HTTP-прокси, не открыло CONNECT и не получило нужный ответ сайта.

Дайте этим поздним этапам собственную ограниченную обработку или проведите через них намеренный общий срок. Иначе исправленный таймер соединения может работать безупречно, пока проверщик тратит ещё минуту на ожидание рукопожатия прокси.

Похожие статьи