Socket.SendTimeout begrenzt keinen Proxy-Verbindungsversuch

Ein Proxy-Checker setzt SendTimeout = 200, ruft Connect auf und wartet viel länger als erwartet. Das Timeout hängt an einer Operation, die der Checker noch nicht erreicht hat.

Socket.SendTimeout steuert synchrone Sends. Einem synchronen Verbindungsversuch gibt es keine Frist von 200 ms. Ein Sleep vor Connect fügt nur eine weitere Verzögerung hinzu.

Die wartende Operation abbrechen

Auf einem modernen .NET-Ziel mit der abbrechbaren Überladung kann eine asynchrone Prüfung ihr Budget auf den Verbindungsaufbau anwenden:

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

Das Fragment gehört in eine async-Methode, wobei Proxy-Host und -Port vom Aufrufer kommen; ein öffentlicher Kandidat aus einer Proxy-Liste kann diese beiden Eingaben liefern. Behandeln Sie den Abbruch getrennt von einem Socket-Fehler, wenn der Checker Fehlergründe meldet. Das Freigeben des Clients verhindert außerdem, dass abgeschlossene Prüfungen Sockets ansammeln.

Älterer .NET-Framework-Code hat nicht jede moderne Überladung. Verwenden Sie eine unterstützte asynchrone Verbindungsregelung und schließen Sie den Socket ausdrücklich, wenn Sie den Versuch aufgeben. Das bloße Beenden Ihres Wartens belegt nicht, dass eine zugrunde liegende Operation beendet wurde.

Das grüne Ergebnis ist immer noch ein kleines Ergebnis

Eine erfolgreiche TCP-Verbindung belegt, dass dieser Client einen lauschenden Endpunkt erreicht hat. Sie hat kein SOCKS ausgehandelt, sich nicht an einem HTTP-Proxy authentifiziert, kein CONNECT geöffnet und keine gewünschte Website-Antwort erhalten.

Geben Sie diesen späteren Phasen ihre eigene begrenzte Behandlung, oder führen Sie eine bewusste Gesamtfrist durch sie hindurch. Sonst kann der reparierte Verbindungstimer einwandfrei funktionieren, während der Checker eine weitere Minute auf einen Proxy-Handshake wartet.