Systemeinstellungen des Betriebssystems und eine Browsererweiterung binden einen Proxy einmalig von Hand ein, eignen sich aber nicht für ein Skript oder einen Parser: Dort muss er programmatisch eingebunden werden – im HTTP-Client, in der Session und im Browsertreiber –, samt Behandlung von Verbindungsabbrüchen und einer Prüfung, dass der Datenverkehr tatsächlich über die gewünschte Adresse läuft.

Format des Verbindungsstrings mit Authentifizierung

Die Proxy-Adresse für die Verbindung aus dem Code wird nach einem einheitlichen Schema zusammengesetzt: protocol://login:password@host:port. Das Protokoll legt den Betriebsmodus fest (http, https, socks5), Login und Passwort stehen durch einen Doppelpunkt getrennt vor dem @-Zeichen, danach folgen Host und Port. Die Bibliotheken von HTTP-Clients und die meisten Browsertreiber akzeptieren einen solchen String als Ganzes, ohne dass Login und Passwort separat übergeben werden müssen.

Das Passwort darf das Zeichen @ und andere für URLs reservierte Zeichen nur mit Prozent-Kodierung enthalten – andernfalls schneidet der Parser den String am ersten Sonderzeichen ab, und die Verbindung wird mit falschen Zugangsdaten aufgebaut. Automatisch generierte Logins und Passwörter sollten vor dem Einsetzen mit einer URL-Kodierungsfunktion kodiert werden.

Unterschied zwischen HTTP- und SOCKS-Modus

Der HTTP-Modus arbeitet auf Protokollebene: Der Server versteht die HTTP-Anfrage und kann Header lesen. Bei HTTPS-Verkehr entschlüsselt er nichts, sondern leitet die verschlüsselte TLS-Verbindung per CONNECT-Methode durch. Deshalb eignet sich der HTTP-Modus trotz seines Namens gleichermaßen für http- und https-Adressen.

Der SOCKS-Modus (praktisch immer SOCKS5) arbeitet eine Ebene tiefer – er analysiert das Anwendungsprotokoll nicht, sondern überträgt Bytes zwischen Client und Ziel. SOCKS5 ist transparent für HTTP und beliebige TCP-Verbindungen und unterstützt im Gegensatz zum HTTP-Modus auch UDP – wichtig für DNS und einen Teil der Netzwerkbibliotheken. Die Namensauflösung lässt sich diesem Server übertragen; dann wird der Hostname nicht im Klartext über den lokalen DNS geschickt, was für geosensitive Websites entscheidend ist. Für Scraping genügt in der Regel der HTTP-Modus, für Netzwerk-Tools und Anwendungen mit eigenem Protokoll wird SOCKS5 benötigt.

Einrichtung auf Ebene von Client, Session und Browsertreiber

Die Adresse lässt sich auf drei Ebenen festlegen, und diese sind nicht austauschbar. Auf Anfrageebene wird der Parameter bei jedem Aufruf des Clients neu übergeben; das passt, wenn jede Anfrage über eine eigene Adresse läuft, zum Beispiel bei einer IP-Rotation auf jeder Seite. Auf Session-Ebene wird die Adresse einmalig beim Erstellen der Session oder des Connection-Pools festgelegt, und alle Anfragen darin nutzen denselben Ausgang und eine Keep-Alive-Verbindung. Das senkt den Aufwand für den TLS-Handshake und hält die IP über den gesamten Ablauf konsistent – wichtig für Websites, die die Übereinstimmung der Adresse zwischen den Anmeldeschritten abgleichen.

Die Ebene des Browsertreibers ist komplizierter: Das Standard-Startargument des Browsers akzeptiert in der Regel nur Host und Port, ohne Login und Passwort im String selbst. Für einen Kanal mit Authentifizierung kommt eines der folgenden Schemata zum Einsatz – eine Erweiterung, die den Anmeldedialog abfängt und die Zugangsdaten einsetzt, ein lokaler Server ohne Passwort, der zu einem externen Knoten mit Authentifizierung tunnelt, oder ein Treiber, der Netzwerkereignisse abfängt und die Anfrage des Browsers beantwortet. Eine Schritt-für-Schritt-Anleitung finden Sie im Artikel Proxy für Antidetect-Browser.

Behandlung von Verbindungsfehlern

Fehler des Zwischenknotens unterscheiden sich von Fehlern der Zielwebsite; sie sollten anhand von Code und Ausnahmetyp auseinandergehalten werden, nicht allein daran, dass die Anfrage fehlgeschlagen ist. Verweigerte Authentifizierung – der Server gibt den Code 407 statt der Antwort der Website zurück: Login, Passwort oder Verbindungsstring sind falsch zusammengesetzt, oder der Zugang ist abgelaufen; die Anfrage unverändert zu wiederholen ist sinnlos. Timeout und Verbindungsabbruch – der Knoten antwortet nicht oder bricht die Sitzung vor der Antwort ab; hilfreich sind ein angemessenes Timeout und eine begrenzte Zahl von Wiederholungen mit Pause statt eines sofortigen Retrys.

Ablehnung durch die Zielwebsite über den Proxy – die Website gibt 403, ein Captcha oder eine Weiterleitung zur Prüfung zurück. Das ist kein Verbindungsfehler, sondern ein Signal, dass die Adresse bereits verbraucht ist oder der Plattform aufgrund ihrer Reputation nicht zusagt; die Anfrage mit derselben IP zu wiederholen ist sinnlos – es braucht einen Austausch. Eine funktionierende Adresse lässt sich schon vorab von einer problematischen unterscheiden mithilfe der Qualitätsmetriken für Proxys.

Prüfung, dass die Anfrage tatsächlich über den Proxy lief

Vor dem eigentlichen Ablauf sollten Sie einen beliebigen Dienst aufrufen, der die IP der Anfrage zurückgibt, und diese mit der echten Adresse des Clients vergleichen – eine einzige Anfrage, die den Fall ausschließt, dass die Verbindung formal eingerichtet ist, der Client aber wegen eines Tippfehlers direkt zugreift.

Der zweite Punkt sind die Header eines transparenten Knotens: X-Forwarded-For oder Via mit der ursprünglichen Adresse des Clients darin. Ein solcher Server akzeptiert die Verbindung, gibt aber die echte IP preis; für Aufgaben mit Anonymitätsanforderung ist daher ein nicht transparenter Modus ohne diese Header nötig. Wenn die Adresse bei jeder Session wechselt, sollte die Prüfung in den Ablauf selbst eingebaut werden – mehr dazu im Artikel zur IP-Rotation per API.

Beim Browsertreiber ist die Prüfung aufwendiger: Der Browser kann den eingerichteten Knoten über WebRTC umgehen, das eine direkte P2P-Verbindung aufbaut und die lokale, mitunter auch die öffentliche IP offenlegt. Wenn der Ablauf empfindlich auf ein Leck reagiert, muss WebRTC über einen eigenen Startparameter deaktiviert werden, statt sich auf die Route über den Server zu verlassen.

Häufig gestellte Fragen

Kann man denselben Proxy gleichzeitig für den HTTP-Client und für den Browsertreiber verwenden?

Technisch ja, wenn der Adresstyp beide Modi unterstützt, in der Praxis richtet man jedoch zwei getrennte Verbindungen ein: Client und Treiber haben eine unterschiedliche Wiederholungslogik und Lebensdauer der Verbindung, und ein gemeinsamer Ausgang für zwei Prozesse erhöht das Blockierrisiko wegen eines übereinstimmenden Anfragemusters.

Warum funktioniert der Proxy in einem HTTP-Client, aber in einem anderen nicht, obwohl der Verbindungsstring derselbe ist?

Die Bibliotheken parsen den Verbindungsstring unterschiedlich und verhalten sich bei Umgebungsvariablen unterschiedlich – ein Client liest sie automatisch, ein anderer verlangt die explizite Übergabe des Parameters, ein dritter ignoriert Systemeinstellungen. Der String sollte explizit übergeben werden, ohne sich auf implizites Verhalten zu verlassen.

Muss man die Verbindung zum Proxy nach jeder Anfrage manuell schließen?

Im Session-Modus nicht – die Verbindung wird vom Pool wiederverwendet und bei Leerlauf-Timeout oder beim Schließen beendet. Explizit schließen sollten Sie nur, wenn der Ablauf Verbindungen länger als die Aufgabe selbst offen hält; sonst stößt man bei einem Kanal mit sitzungsbezogener Adressvergabe leicht an das Limit gleichzeitiger Sessions.

Fertige Proxys mit Login und Passwort für den HTTP- und SOCKS5-Modus samt Dokumentation zur Anbindung finden Sie im Bereich Proxys. Das Format der Anfragen und die Limits für die programmatische Integration stehen in der Proxy-API.