Socket.SendTimeout Does Not Limit a Proxy Connection Attempt
Bound a proxy port probe at connection establishment instead of setting a timeout that only applies to sending data.
A proxy checker sets SendTimeout = 200, calls Connect, and waits much longer than expected. The timeout is attached to an operation the checker has not reached.
Socket.SendTimeout controls synchronous sends. It does not give a synchronous connection attempt a 200 ms deadline. Adding a sleep before Connect only adds another delay.
Cancel the operation that is waiting
On a modern .NET target providing the cancellable overload, an asynchronous probe can apply its budget to connection establishment:
using var budget = new CancellationTokenSource(TimeSpan.FromSeconds(2));
using var client = new TcpClient();
await client.ConnectAsync(proxyHost, proxyPort, budget.Token);The fragment belongs in an async method, with the proxy host and port supplied by the caller; a public candidate from a proxy list can provide those two inputs. Handle cancellation separately from a socket error if the checker reports failure reasons. Disposing the client also keeps completed probes from accumulating sockets.
Older .NET Framework code does not have every modern overload. Use a supported asynchronous connection arrangement and explicitly close the socket when abandoning the attempt. Merely stopping your wait does not establish that an underlying operation has stopped.
The green result is still a small result
A successful TCP connection proves that this client reached a listening endpoint. It has not negotiated SOCKS, authenticated to an HTTP proxy, opened CONNECT or received the desired website response.
Give those later stages their own bounded handling, or carry an intentional overall deadline through them. Otherwise the repaired connection timer can work perfectly while the checker spends another minute waiting for a proxy handshake.