Überprüfung eines kostenlosen Proxys, bevor Sie ihm echten Traffic anvertrauen

Kostenlose Proxys versagen häufiger, als sie funktionieren. Eine öffentliche Liste durchläuft Zehntausende von Kandidaten, und Ihre Aufgabe ist es, die kleine Teilmenge zu finden, die derzeit aktiv, schnell genug und nicht bösartig ist. Fünf Tests, jeder kostengünstig, werden nacheinander ausgeführt.

Test 1: TCP-Erreichbarkeit

curl --connect-timeout 5 --proxy http://1.2.3.4:8080 \
     -s -o /dev/null -w "%{http_code}\n" \
     https://api.ipify.org

Ein Exit-Code ungleich Null oder eine leere Antwort bedeutet, dass der Proxy tot ist. Etwa 60–80 % einer freien Liste werden diesen Test zu einem beliebigen Zeitpunkt nicht bestehen. Überspringen Sie ihn sofort und wiederholen Sie ihn nicht.

Test 2: Überprüfung der Egress-IP

Derselbe Aufruf gibt die öffentliche IP zurück, von der die Anfrage ausgegangen ist. Wenn sie 1.2.3.4 entspricht – der Adresse des Proxys – leitet der Proxy den Datenverkehr korrekt weiter. Wenn sie Ihrer lokalen IP entspricht, ist der Proxy defekt oder transparent: Er hat die Verbindung akzeptiert, aber nicht tatsächlich über sich selbst weitergeleitet. Behandeln Sie das als Fehler, auch wenn TCP erfolgreich war.

Test 3: Header-Transparenz

curl --proxy http://1.2.3.4:8080 https://httpbin.org/headers

Die Antwort gibt die Header zurück, die das Ziel erhalten hat. Achten Sie auf X-Forwarded-For, Via oder Forwarded mit Ihrer echten IP. Wenn Sie diese finden, arbeitet der Proxy im transparenten oder anonymen Modus und nicht im Elite-Modus. Bei HTTPS über CONNECT ist dies irrelevant – das Ziel sieht nur den TLS-Handshake, keine Anwendungsheader – aber bei Klartext-HTTP bestimmt es, ob der Proxy für den Zweck geeignet ist.

Test 4: Latenz unter Last

Einzelzeitmessungen sind verrauscht. Führen Sie zehn serielle Anfragen durch den Proxy aus und nehmen Sie den Median. Alles über zwei Sekunden ist für interaktive Arbeit unbrauchbar. Unter 500 Millisekunden ist es konkurrenzfähig zu gar keinem Proxy. Dazwischen ist der Proxy für Batch-Scraping geeignet, aber nicht zum Surfen.

Test 5: TLS-Fingerprint-Integrität

Verbinden Sie sich durch den Proxy mit einem bekannten TLS-Endpunkt und überprüfen Sie, ob die Zertifikatskette mit der übereinstimmt, die Sie ohne Proxy erhalten. Eine Abweichung bedeutet, dass der Proxy TLS abfängt – ein Man-in-the-Middle-Angriff, bei dem Ihr „verschlüsselter“ Datenverkehr ab dem Proxy tatsächlich nicht mehr verschlüsselt ist. Dies ist bei korrekt konfigurierten SOCKS-Proxys selten (sie können TLS nicht sehen), tritt aber bei falsch konfigurierten Unternehmens-HTTPS-Proxys und gelegentlich bei bösartigen öffentlichen Knoten auf. openssl s_client -proxy 1.2.3.4:8080 -connect example.com:443 gibt die Kette aus.

Ein praktischer Workflow

Holen Sie die Liste, filtern Sie nach Land und Protokoll, verteilen Sie die fünf Tests auf einen parallelen Pool von etwa 50 Workern und behalten Sie die Überlebenden. Aus 100 rohen Kandidaten liefert ein typischer Durchlauf 5–15 brauchbare Einträge. Die Verfallsrate beträgt bei HTTP und HTTPS etwa 30–60 Minuten, bei SOCKS etwas länger – planen Sie eine Aktualisierung in diesem Rhythmus ein und speisen Sie die überlebende Menge in Ihren Scraper oder Ihre Browserkonfiguration ein. Zwischenspeichern Sie die Testergebnisse für die Lebensdauer eines Batches und testen Sie beim nächsten Batch erneut.