Web Scraping Proxies: Welcher Typ ist für welche Aufgabe am besten geeignet?

Die Wahl eines Proxys für Scraping ist eigentlich eine Frage des Ziels, nicht des Proxys. Eine Seite ohne Schutzmaßnahmen und eine Seite hinter DataDome benötigen völlig unterschiedliche Konfigurationen, und für die erste residentielle Tarife zu zahlen verschwendet Geld, während Datacenter-IPs auf die zweite anzusetzen Zeit verschwendet.

Dieser Leitfaden behandelt, welcher Proxy-Typ zu welcher Scraping-Aufgabe passt, wie man sie betreibt, ohne blockiert zu werden, und wann eine Scraping-API die bessere Antwort ist als reine Proxys.

Die vier Typen, für Scraping

Typ	IP-Quelle	Geschwindigkeit	Blockrate	Kosten	Am besten geeignete Scraping-Aufgabe
Datacenter	Hosting-Anbieter	Am höchsten	Hoch bei geschützten Seiten	Am niedrigsten	Ungeschützte Seiten, APIs, Massenabruf
Residentiell	Consumer-ISPs, echte Haushalte	Mäßig	Niedrig	Mittel, pro GB	Einzelhandel, Reisen, Suche, alles Geschützte
ISP	Consumer-ISPs, im Rechenzentrum gehostet	Hoch	Niedrig bis mäßig	Pro IP pro Monat	Eingeloggte Sitzungen, langlaufende Aufgaben
Mobil	Mobilfunkanbieter	Mäßig bis niedrig	Am niedrigsten	Am höchsten	Die schwierigsten Ziele, App-APIs

Eine Korrektur, die es wert ist, gemacht zu werden, denn das Gegenteil wird vielfach veröffentlicht und dieser Artikel hat es zuvor wiederholt: Datacenter-IPs werden nicht von ISPs bereitgestellt. Sie sind bei Hosting- und Cloud-Anbietern registriert und laufen niemals über einen Consumer-Internetanbieter. Genau deshalb sind sie identifizierbar: Die Bereiche sind öffentlich, sodass eine Seite sie auf Anhieb klassifizieren kann.

ISP- und Mobil-Proxys sind beide für Scraping relevant und werden bei Vergleichen wie diesem meist ausgelassen. ISP-Proxys sind die Antwort, wann immer ein Scrape einen Login voraussetzt, weil die Adresse konstant bleibt. Mobil-Proxys sind das letzte Mittel für Ziele, die alles andere aushebeln.

Rotation und Session-Handling

Die Rotationsstrategie ist wichtiger als der Proxy-Typ, wenn es darum geht, nicht blockiert zu werden.

Rotation pro Anfrage liefert für jede Anfrage eine neue IP. Das ist die richtige Standardeinstellung für das Sammeln unabhängiger Seiten: Produktlisten, Suchergebnisse, Verzeichniseinträge. Keine einzelne Adresse sammelt ein verdächtiges Muster an.

Sticky Sessions halten eine IP für eine festgelegte Dauer, typischerweise 1 bis 30 Minuten. Verwenden Sie diese, wann immer Anfragen voneinander abhängen: Paginierung mit einem Cursor, alles nach einem Login, mehrstufige Checkout-Abläufe. Eine Session, die mitten im Ablauf die IP wechselt, sieht wie Kontodiebstahl aus und wird herausgefordert.

Die praktische Regel: Pro Anfrage rotieren, es sei denn, etwas im Ablauf erfordert Kontinuität, dann das kürzeste Sticky-Fenster halten, das dies abdeckt.

Anfragerate und Nebenläufigkeit

Die meisten Blockierungen werden durch die Rate verursacht, nicht durch den Proxy-Typ. Eine residentielle IP, die eine Seite 20 Mal pro Sekunde trifft, ist offensichtlicher automatisiert als eine Datacenter-IP, die sie einmal alle 10 Sekunden trifft.

• Rate pro IP. Bei einer geschützten Seite sollte jede Adresse auf etwa eine Anfrage alle 2 bis 5 Sekunden begrenzt werden. Bei einer ungeschützten Seite können Sie deutlich aggressiver vorgehen.
• Nebenläufigkeit. Der Gesamtdurchsatz ist gleichzeitige Adressen multipliziert mit der Rate pro IP. Um sicher 10 Anfragen pro Sekunde zu erreichen, möchten Sie eher 30 bis 50 Adressen gleichzeitig im Einsatz haben, nicht 10 Adressen, die dreimal schneller arbeiten.
• Randomisieren. Feste Intervalle sind selbst eine Signatur. Fügen Sie Jitter hinzu, damit die Abstände variieren.
• Bei Fehlern zurückfahren. Wenn die Fehlerraten steigen, verlangsamen Sie statt aggressiver zu wiederholen. Wiederholtes Versuchen in eine Blockierung hinein ist der Weg, wie aus einem weichen Rate-Limit ein harter Bann wird.

Header und Fingerprints

Eine IP bringt Sie bis zur Tür. Die Anfrage muss dann korrekt aussehen, sobald sie dort ist.

• Senden Sie einen vollständigen, kohärenten Header-Satz. Echte Browser senden Accept, Accept-Language, Accept-Encoding, User-Agent und Sec-Ch-Ua in einer konsistenten Kombination. Ein einzelner User-Agent bei einer ansonsten kargen Anfrage ist ein starkes Bot-Signal.
• Halten Sie die Header-Geschichte konsistent mit der IP. Eine deutsche IP, die Accept-Language: en-US sendet, ist eine Diskrepanz, die es zu vermeiden gilt, wenn Sie geografisch gezielt vorgehen.
• Passen Sie TLS- und HTTP-Verhalten an den Client an, für den Sie sich ausgeben. Fortgeschrittene Systeme erstellen Fingerprints des TLS-Handshakes und der HTTP/2-Frame-Reihenfolge, sodass ein Python-Client, der vorgibt, Chrome zu sein, unabhängig von den Headern erkennbar ist.
• Verwenden Sie einen echten Browser, wenn die Seite einen benötigt. Seiten, die Inhalte per JavaScript rendern, benötigen einen Headless-Browser, und Headless-Browser haben eigene Fingerprints, die verwaltet werden müssen.

Moderne Anti-Bot-Systeme

Cloudflare, DataDome, PerimeterX und Akamai sind keine IP-Sperrlisten. Sie bewerten eine Kombination aus Adressreputation, Anfrage-Fingerprint, Verhalten und Ergebnissen von JavaScript-Herausforderungen.

Das hat zwei Konsequenzen. Allein IPs zu rotieren wird sie nicht besiegen, weil Ihr Fingerprint unverändert bleibt. Und eine residentielle IP ist notwendig, aber nicht ausreichend: Sie entfernt das einfachste Signal und lässt die schwierigeren übrig.

Wenn Sie auf eines stoßen:

1. Lesen Sie die Antwort richtig. Ein 403 mit einer Challenge-Seite ist etwas anderes als ein 429-Rate-Limit und braucht eine andere Lösung. Prüfen Sie den Body, nicht nur den Statuscode.
2. Verlangsamen Sie zuerst. Die Rate ist das Günstigste, was man ändern kann, und oft die eigentliche Ursache.
3. Steigen Sie auf der Vertrauensleiter auf. Von Datacenter zu residentiell, von residentiell zu mobil.
4. Rendern Sie die Challenge. Wenn die Seite JavaScript-Ausführung erfordert, wird ein einfacher HTTP-Client niemals bestehen, egal welche IP er verwendet.
5. Überdenken Sie den Ansatz. Wenn ein Ziel mehr durch Wiederholungsversuche kostet, als die Daten wert sind, ist eine verwaltete API günstiger, als weiter dagegen zu kämpfen.

Kosten, Volumen und wann eine API zu verwenden ist

Die Schätzung eines Projekts beginnt mit dem Seitengewicht. Eine typische HTML-Seite ist 0,5 bis 2 MB groß, sodass 100.000 Seiten etwa 50 bis 200 GB ausmachen. Das Rendern von JavaScript vervielfacht dies um ein Mehrfaches, da auch Skripte, Stile und Bilder abgerufen werden.

Die Zahl, die Ihre Rechnung tatsächlich bestimmt, ist die Blockrate. Ein Setup, das 40% der Anfragen fehlschlägt und diese wiederholt, zahlt diese Bandbreite doppelt. Billige Proxys mit hoher Fehlerrate kosten häufig pro erfolgreicher Seite mehr als teure.

Reine Proxys sind die richtige Wahl, wenn Sie den Scraper kontrollieren, das Ziel bekannt ist und Sie die niedrigsten Kosten pro Einheit wünschen. Eine verwaltete API ist die bessere Wahl, wenn sich das Ziel stark wehrt, wenn Sie andernfalls Browser-Fingerprints und Challenge-Löser warten müssten, oder wenn Entwicklungszeit die knappe Ressource ist statt Geld.

Shifters Web Scraping API übernimmt Proxy-Rotation, JavaScript-Rendering und Challenges hinter einer einzigen Anfrage, und die SERP API tut dasselbe speziell für Suchergebnisse, die ansonsten zu den schwierigeren Zielen gehören, die es zu pflegen gilt. Für reine Proxys decken residentielle Proxys und ISP-Proxys die beiden Enden der Session-Frage ab, und aktuelle Preise finden Sie auf der Preisseite.

Ein kurzer Entscheidungsrahmen

• Ziel hat keinen Bot-Schutz und Sie benötigen Volumen günstig: Datacenter-Proxys.
• Ziel limitiert die Rate oder stellt Challenges, kein Login involviert: rotierende residentielle Proxys.
• Scrape erfordert eine eingeloggte Sitzung oder muss eine Identität halten: ISP-Proxys.
• Ziel besiegt residentielle Proxys, oder Sie benötigen App-Level-Zugriff: Mobil-Proxys.
• Ziel kostet mehr an Wartung, als die Daten wert sind: eine Scraping-API.

Die meisten realen Projekte kombinieren diese. Das Sammeln läuft über rotierende residentielle Proxys, die Handvoll authentifizierter Dashboards läuft über ISP, und das eine unmögliche Ziel läuft über die API.

Fazit

Es gibt keinen einzigen besten Proxy für Scraping. Passen Sie den Typ daran an, wie stark sich das Ziel verteidigt, passen Sie die Rotation daran an, ob Ihre Anfragen voneinander abhängen, und behandeln Sie die Anfragerate als das Erste, was Sie anpassen sollten, wenn Blockierungen auftreten.

Für die umfassendere Taxonomie siehe Arten von Proxys, und für den Anwendungsfall im Detail den Überblick zu Web Scraping.