Ein rotierender Proxy ist ein Host und Port, der Ihnen im Laufe der Zeit eine andere Exit-IP gibt, sodass ein Scraper, der tausend Anfragen sendet, diese nicht alle von einer Adresse sendet, die das Ziel drosseln und blockieren kann. Sie zeigen Ihren HTTP-Client auf den rotierenden Endpunkt statt auf die Seite, und die Rotation geschieht dahinter. Das ist der gesamte Mechanismus. Alles andere (pro Anfrage vs. Sticky, Residential vs. Datacenter, selbst bauen vs. kaufen) ist eine darauf aufbauende Entscheidung.
Dieser Leitfaden ist die praktische Version. Er deckt die eine Entscheidung ab, die Ihren Code tatsächlich ändert, eine neue IP bei jeder Anfrage rotieren oder eine IP über eine Sitzung hinweg halten, zeigt ein funktionierendes Python-Beispiel für jeden Fall und sagt dann klar, wann das Zeigen auf einen verwalteten rotierenden Endpunkt dem Zusammenbauen und Betreuen eines eigenen Pools überlegen ist. Wenn Sie den Hintergrund dazu möchten, was ein Proxy überhaupt ist, deckt was ist ein Proxy-Server die Indirektionsschicht ab, auf der all das aufbaut.
Die eine Entscheidung, die zählt: pro Anfrage vs. Sticky Session
Fast jede Frage zu rotierenden Proxies reduziert sich auf eine einzige Entscheidung, und es ist nicht welcher Anbieter. Es ist, ob Sie bei jeder Anfrage eine neue IP wollen oder dieselbe IP über eine Folge von Anfragen gehalten. Die zwei Modi lösen entgegengesetzte Probleme, und die falsche zu wählen ist der häufigste Grund, warum ein Scrape, der "rotierende Proxies verwendet", trotzdem blockiert wird.
| Rotationsmodus | Was er tut | Verwenden Sie ihn für |
|---|---|---|
| Pro Anfrage | Neue Exit-IP bei jeder einzelnen Anfrage | Zustandslose, hochvolumige Lesevorgänge (Preise, Kataloge, Suche) |
| Sticky Session | Hält eine IP für ein festes Fenster oder eine Sitzungs-ID | Logins, Warenkörbe, mehrstufige Abläufe, die wie ein Benutzer aussehen müssen |
Die Logik ist unkompliziert. Wenn jede Anfrage unabhängig ist (Sie rufen eine Produktseite nach der anderen ab und nichts überträgt sich), verteilt eine neue IP pro Anfrage die Last, sodass keine einzelne Adresse ein Rate-Limit auslöst. Aber in dem Moment, in dem Anfragen voneinander abhängen, ein Login der ein Cookie setzt, ein Warenkorb zu dem Sie hinzufügen und dann auschecken, bricht das Rotieren mitten im Ablauf Sie. Die Seite sieht, wie Ihre Sitzung zwischen zwei Klicks von einem Land in ein anderes springt und lässt Sie fallen. Dort wollen Sie eine Sticky Session: dieselbe Exit-IP für die gesamte Sequenz, dann eine neue für den nächsten Benutzer.
Eine Sticky Session rotiert trotzdem, nur an der Grenze einer Sitzung statt einer Anfrage. Sie erhalten eine stabile IP für die Dauer eines eingeloggten Ablaufs und eine andere IP für den nächsten Ablauf. Wenn Sie wirklich eine IP brauchen, die über Läufe hinweg nie wechselt (langfristiges authentifiziertes Scraping), ist das ein statischer Residential / ISP-Proxy, ein anderes Produkt. Der Vergleich ist in ISP vs. Residential Proxies.
Rotation pro Anfrage in Python
Die sauberste Art, pro Anfrage zu rotieren, ist, einen verwalteten Endpunkt das zu tun zu lassen: Sie zeigen Ihren Client auf einen Host und die Exit-IP wechselt im Hintergrund. Für Ihren Code ist es nur ein Proxy, sodass sich an requests nichts ändert außer der Proxy-URL. Hier ist ein minimaler Scrape, der beweist, dass sich die IP bewegt, indem er ein Echo-Service einige Male trifft.
# Per-request rotation: one endpoint, a new exit IP each call. import requests token = "_YOUR_TOKEN_" endpoint = f"http://{token}:@smartproxy.crawlbase.com:8012" proxies = {"http": endpoint, "https": endpoint} # Hit an echo service 3 times; each line should show a different IP. for _ in range(3): resp = requests.get("https://httpbin.org/ip", proxies=proxies, verify=False) print(resp.json()["origin"])
Tauschen Sie httpbin.org/ip gegen Ihr echtes Ziel aus und dieselbe Proxy-Konfiguration leitet jede Anfrage durch eine rotierende Exit-Adresse. Das Flag verify=False überspringt die TLS-Verifizierung, weil der Traffic durch den Tunnel des Proxys geleitet wird; in der Produktion würden Sie requests auf das CA-Paket des Anbieters zeigen statt die Verifizierung zu deaktivieren. Von hier aus ist das Parsen gewöhnliches BeautifulSoup oder was auch immer Sie bereits verwenden, der Proxy ist für es unsichtbar.
Sticky Sessions in Python
Für einen Ablauf, der wie ein Benutzer aussehen muss, halten Sie die Exit-IP über die zusammengehörigen Anfragen hinweg fest. Bei einem verwalteten Endpunkt ist der übliche Mechanismus, eine einzelne requests.Session zu verwenden (damit Cookies gespeichert bleiben) und eine Sitzungskennung zu übergeben, die das Gateway verwendet, um eine IP für ein Fenster zu fixieren. Die Sitzung ist das, was das Login-Cookie von Anfrage zu Anfrage trägt; die fixierte IP ist das, was verhindert, dass die Seite Ihren "Benutzer" mitten im Ablauf teleportieren sieht.
# Sticky session: one IP + one cookie jar across a multi-step flow. import requests token = "_YOUR_TOKEN_" endpoint = f"http://{token}:@smartproxy.crawlbase.com:8012" session = requests.Session() # persists cookies across requests session.proxies = {"http": endpoint, "https": endpoint} # Step 1: log in (sets a cookie). Step 2: read a gated page. # Same IP + same cookie jar make both look like one visitor. session.post("https://example.com/login", data={"user": "u", "pass": "p"}, verify=False) resp = session.get("https://example.com/account/orders", verify=False) print(resp.status_code)
Die genaue Art, wie Sie ein Sticky-Fenster anfordern (ein Header, ein Sitzungstoken im Benutzernamen oder ein dedizierter Port), hängt vom Anbieter ab, also prüfen Sie deren Dokumentation für den Parameternamen. Das Muster ist universell: Halten Sie die IP für die Anfragen, die Zustand teilen, geben Sie sie frei, wenn der Benutzer fertig ist.
Eigene Rotation aufbauen
Sie brauchen nicht unbedingt einen verwalteten Endpunkt, um zu rotieren. Wenn Sie eine Liste von Proxies haben, können Sie selbst eine pro Anfrage auswählen. Das ist es wert zu verstehen, weil es genau zeigt, was ein verwalteter Endpunkt für Sie tut und wo es scheitert.
# Manual rotation: cycle a list of proxies yourself. import requests, itertools pool = [ "http://user:pass@ip1:port", "http://user:pass@ip2:port", "http://user:pass@ip3:port", ] rotation = itertools.cycle(pool) # round-robin instead of random def fetch(url): proxy = next(rotation) return requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=15)
Round-Robin mit itertools.cycle ist vorhersehbarer als zufällige Auswahl, weil es Last gleichmäßig verteilt statt was auch immer der Zufallszahlengenerator bevorzugt zu hammern. Beachten Sie aber, was dieser Code nicht verarbeitet: eine tote IP im Pool, ein Proxy, der eine Blockierseite mit 200-Status zurückgibt, eine fehlgeschlagene Anfrage auf einer anderen Exit-Adresse wiederholen oder IPs entfernen, die markiert wurden. In einem echten Lauf sind diese Fälle der Großteil der Arbeit, und sie sind genau das, was ein verwalteter rotierender Endpunkt für Sie absorbiert. Wenn Sie das vollständige Muster zum Wechseln von Adressen sehen möchten, geht wie man eine IP-Adresse rotiert tiefer auf die Mechanik ein.
Wann ein verwalteter Endpunkt dem eigenen Aufbau überlegen ist
Die manuelle Version oben ist für eine kleine, stabile Liste gegen eine tolerante Seite in Ordnung. Sie hört auf, in Ordnung zu sein, sobald eines davon zutrifft: Das Ziel kämpft aktiv gegen Bots, Sie brauchen echte Benutzer-IPs (Residential oder Mobile) statt Datacenter, Ihr Pool ist groß genug, dass Liveness- und Health-Checks mühsam werden, oder Sie brauchen Wiederholungsversuche und IP-Auswahl pro Anfrage ohne diese Orchestrierung selbst zu schreiben.
Ein verwalteter rotierender Endpunkt fasst all das in einen Host und Port zusammen. Sie zeigen Ihren Client darauf, und er wählt eine Exit-IP aus, rotiert pro Anfrage oder hält eine Sticky Session und versucht es im Hintergrund erneut, wenn eine IP blockiert wird. Ihre Scraping-Logik ändert sich nicht, es ist immer noch nur eine Proxy-URL, aber Pool-Management, Health-Checks und Rotationsrichtlinie hören auf, Ihr Code zu sein. Der ehrliche Kompromiss: Sie geben feinkörnige Kontrolle über einzelne IPs auf im Austausch dafür, keine Flotte zu betreiben. Für das meiste Scraping ist das ein guter Tausch, weil IP-Klempnerarbeiten nicht der Teil des Jobs sind, der Wert schafft.
Es gibt eine Stufe noch darüber. Wenn das Ziel auch einen gerenderten Browser benötigt, CAPTCHA-Challenges sendet oder einen glaubwürdigen Fingerabdruck braucht, ist das Rotieren der IP nur ein Teil des Kampfes, und Backconnect-Proxy vs. Crawling API ist der Vergleich, den Sie lesen sollten. Ein rotierender Endpunkt gibt Ihnen eine saubere IP und tritt zurück; eine Crawling API besitzt Rotation, Rendering und Wiederholungsversuche von Ende zu Ende und gibt Ihnen die fertige Seite.
Smart AI Proxy ist ein rotierender Endpunkt über einen Pool von 140M+ IPs aus Datacenter-, Residential- und Mobile-Exits. Er rotiert pro Anfrage, unterstützt Sticky Sessions für eingeloggte Abläufe und versucht es bei Blockierungen erneut, sodass der obige Code die gesamte Integration ist: Ändern Sie die Proxy-URL und Ihr Scraper funktioniert weiter. Testen Sie Ihr echtes Ziel damit im kostenlosen Tier, bevor Sie sich festlegen. Start free und binden Sie es gegen die API-Dokumentation ein.
Häufige Fehler und wie man sie liest
Rotierende Proxies schlagen auf eine kleine Anzahl erkennbarer Weisen fehl. Zu wissen, welchen Sie gerade sehen, spart stundenlange Raterei.
Sie werden trotzdem blockiert. Meistens eines von zwei Dingen: Sie rotieren pro Anfrage bei einem Ablauf, der eine Sticky Session braucht (also sieht die Seite, wie Ihre Sitzung IPs springt), oder Ihr IP-Typ ist für das Ziel falsch. Eine gehärtete Seite lässt Datacenter-IPs fallen, egal wie schnell Sie rotieren; sie will echte Benutzer-IPs. Passen Sie den IP-Typ an die Abwehrmechanismen an, nicht an die Rotationsgeschwindigkeit; der Typ-Kompromiss ist in Datacenter vs. Residential Proxies dargelegt.
Ein 200, der tatsächlich eine Blockierung ist. Viele Seiten geben eine CAPTCHA- oder "Sind Sie ein Mensch?"-Seite mit einem 200-Status zurück, also reicht es nicht, status_code == 200 zu prüfen. Prüfen Sie den Body auf bekannte Blockierungsmarker (eine Challenge-Zeichenkette, eine unerwartete Weiterleitung, eine verdächtig kurze Antwort), bevor Sie der Antwort vertrauen. Behandeln Sie diese als Fehler und versuchen Sie es mit einer neuen IP erneut.
Authentifizierungsfehler. Ein 407 (oder eine Verbindung, die hängt) bedeutet fast immer, dass die Zugangsdaten in der Proxy-URL falsch oder fehlerhaft sind. Überprüfen Sie das Token und die Form user:pass@host:port. Wenn Sie Proxy-Status-Codes im Allgemeinen debuggen, ordnet wie man Proxy-Status-Fehlercodes löst die häufigen auf Ursachen ab.
Langsam oder Timeout. Residential- und Mobile-Exits leiten durch Verbraucherverbindungen und sind von Natur aus langsamer als Datacenter. Setzen Sie ein vernünftiges timeout (das Beispiel verwendet 15 Sekunden) und einen Wiederholungsversuch, statt einen einzelnen langsamen Exit den gesamten Lauf zu blockieren. Wenn ein verwalteter Endpunkt generell Timeouts hat, ist das ein Signal des Anbieters, kein Code-Fehler.
Best Practices, die tatsächlich etwas bewegen
Die meisten "Best Practices"-Listen sind Füllmaterial. Diese wenigen ändern Ihre Blockierungsrate tatsächlich. Dosieren Sie Ihre Anfragen statt zu burst-en (Rotation verteilt IPs, aber tausend Anfragen in einer Sekunde aus jedem Pool sieht trotzdem automatisiert aus). Rotieren Sie Ihren User-Agent neben der IP, denn ein fester UA über tausende "verschiedene" IPs ist verräterisch. Passen Sie den IP-Typ an das Ziel an statt reflexartig das teuerste Tier zu kaufen. Und für die Produktion verwenden Sie einen Anbieter mit klarer Logging-Richtlinie statt gescrapte kostenlose Proxy-Listen, die langsam, kurzlebig und ein echtes Sicherheitsrisiko sind, behandelt in sind Proxies sicher. Wenn Ihr Endziel breiter als Rotation allein ist, setzt wie man Websites scrapet ohne blockiert zu werden diese in Kontext.
Wichtigste Erkenntnisse
- Die eigentliche Entscheidung ist pro Anfrage vs. Sticky. Neue IP pro Anfrage für zustandslose Lesevorgänge; eine gehaltene IP über eine Sitzung für Logins und mehrstufige Abläufe.
-
Für Ihren Code ist ein rotierender Endpunkt nur eine Proxy-URL. Zeigen Sie
requestsauf einen Host und die IP wechselt im Hintergrund; das Parsen bleibt unverändert. - Eigene Rotation aufzubauen ist leicht bis es das nicht mehr ist. Health-Checks, Entfernen toter IPs, Wiederholungsversuche und Erkennung von "200-das-ist-eine-Blockierung" sind der Großteil der echten Arbeit.
- IP-Typ an die Abwehrmechanismen anpassen, nicht an die Rotationsgeschwindigkeit. Schnelle Rotation von Datacenter-IPs rettet Sie nicht bei einem gehärteten Ziel.
- Ein verwalteter Endpunkt tauscht IP-Kontrolle gegen keine Flotte zu betreiben. Für das meiste Scraping ist das der richtige Tausch.
Häufig gestellte Fragen
Wie verwende ich einen rotierenden Proxy in Python?
Zeigen Sie Ihren HTTP-Client auf den rotierenden Endpunkt statt auf das Ziel. Mit requests bauen Sie ein Proxies-Dict ({"http": url, "https": url}), wobei die URL der Host, Port und die Zugangsdaten Ihres Anbieters sind, und übergeben es an jedes requests.get oder requests.post. Die Exit-IP wechselt im Hintergrund, sodass sich Ihr Parsing-Code überhaupt nicht ändert. Testen Sie es, indem Sie ein Echo-Service wie httpbin.org/ip einige Male anfragen und bestätigen, dass sich die IP unterscheidet.
Was ist der Unterschied zwischen Rotation pro Anfrage und einer Sticky Session?
Rotation pro Anfrage gibt Ihnen bei jeder Anfrage eine neue Exit-IP, was Last verteilt und für zustandslose, hochvolumige Lesevorgänge geeignet ist. Eine Sticky Session hält eine IP über eine Folge von Anfragen, was Sie für Logins, Warenkörbe und jeden mehrstufigen Ablauf brauchen, der wie ein einzelner Benutzer aussehen muss. Verwenden Sie pro Anfrage für unabhängige Lesevorgänge und Sticky immer wenn Anfragen voneinander abhängen.
Warum werde ich trotzdem mit einem rotierenden Proxy blockiert?
Die zwei üblichen Ursachen sind das Rotieren pro Anfrage bei einem Ablauf, der eine Sticky Session braucht (die Seite sieht also Ihre Sitzung mitten im Ablauf IPs springen), und die Verwendung des falschen IP-Typs. Ein gehärtetes Ziel lässt Datacenter-IPs unabhängig davon fallen, wie schnell Sie rotieren. Passen Sie den IP-Typ an die Abwehrmechanismen an, halten Sie eine Sticky Session für zustandsbehaftete Abläufe und prüfen Sie, ob eine "200"-Antwort tatsächlich eine CAPTCHA-Seite ist.
Soll ich Proxies selbst rotieren oder einen verwalteten Endpunkt verwenden?
Selbst aufbauen funktioniert für eine kleine, stabile Liste gegen eine tolerante Seite. Ein verwalteter Endpunkt gewinnt, sobald Sie echte Benutzer-IPs, einen großen Pool, Health-Checking, Wiederholungsversuche oder IP-Auswahl pro Anfrage benötigen, weil er all das hinter einem Host und Port absorbiert. Leistungs- und Kostenbereiche variieren nach Ziel und Anbieter; es sind keine festen Konstanten. Der Tausch ist die Aufgabe von IP-Kontrolle dafür, keine Flotte zu betreiben.
Funktionieren rotierende Proxies für Scraping hinter einem Login?
Ja, aber Sie müssen eine Sticky Session verwenden, keine Rotation pro Anfrage. Halten Sie dieselbe Exit-IP und dasselbe Cookie-Jar über den Login und die folgenden geschlossenen Seiten hinweg, sodass die Seite einen konsistenten Besucher sieht. Wenn Sie eine IP brauchen, die über viele separate Läufe hinweg fest bleibt, ist das ein statischer Residential (ISP) Proxy statt eines rotierenden.
Wie schnell kann ich Anfragen durch einen rotierenden Proxy senden?
Schneller als von einer einzelnen IP, weil die Rotation Anfragen über viele Adressen verteilt, aber Rotation ist keine Lizenz zum Burst-en. Tausend Anfragen in einer Sekunde aus jedem Pool lesen sich trotzdem als automatisiert. Dosieren Sie Ihre Anfragen, setzen Sie ein Timeout und einen Wiederholungsversuch und rotieren Sie Ihren User-Agent neben der IP. Residential- und Mobile-Exits sind von Natur aus langsamer als Datacenter, planen Sie das also in Ihre Timeouts ein.
Crawlen Sie jede Website im großen Maßstab, ohne gegen die Infrastruktur zu kämpfen.
Crawlbase übernimmt Proxys, Fingerprints und CAPTCHAs, damit Ihr Team Datenpipelines ausliefert, statt Crawl-Infrastruktur zu pflegen. 1.000 Anfragen kostenlos, keine Karte erforderlich.
