Residential Proxys sind das, was wir verkaufen, daher mag es seltsam wirken, dass wir darüber schreiben, wann man keinen braucht. Aber Teams, die für jede Aufgabe Proxys kaufen, geben zu viel aus, und Teams, die bei jedem Fehlschlag dem Proxy die Schuld geben, verschwenden Wochen. Zu wissen, welche Seiten eine residentielle IP brauchen, welche gar nichts brauchen und welche etwas ganz anderes benötigen, ist die günstigste Optimierung in der Web-Datensammlung.
Um das konkret zu machen, haben wir einen kleinen Test durchgeführt. Am 9. Oktober 2026 haben wir 30 öffentliche Seiten jeweils dreimal angefragt, von einem Cloud-Server mit einer Rechenzentrums-IP-Adresse, und dann erneut über Shifter Residential Proxys mit US-Exits. Beide Durchläufe nutzten denselben einfachen Python-HTTP-Client. Sechzehn der 30 Seiten funktionierten jedes Mal mit der Rechenzentrums-IP. Drei funktionierten nur über residentielle Exits. Die übrigen elf schlugen auf beide Arten fehl, aus Gründen, die eine residentielle IP nicht behebt.
Der Test
Die Zielseiten deckten sechs Arten von Websites ab: öffentliche APIs und offene Daten, Referenz- und Dokumentationsseiten, Nachrichten-Homepages, E-Commerce-Suchseiten, Reise-Suchseiten und eine Gruppe von Social-, Jobs- und Suchseiten. Jede Anfrage nutzte denselben Desktop-Browser-User-Agent und wurde auf echten Inhalt geprüft, nicht nur auf einen Statuscode: Eine Antwort zählte nur dann als Erfolg, wenn sie einen Marker enthielt, der nur im tatsächlichen Inhalt vorkommt, etwa eine Suchergebniskarte. Blockseiten, die Status 200 zurückgeben, was häufig vorkommt, zählten daher als Fehlschlag.
Wir haben die Marker durch Prüfung gespeicherter Antworten aus beiden Netzwerken vor dem finalen Durchlauf ausgewählt und fünf Kandidatenseiten verworfen, bei denen wir nicht unterscheiden konnten, ob es sich um echten Inhalt, eine Login-Sperre oder eine leere JavaScript-Hülle handelte.
| Kategorie | Seite | Rechenzentrums-IP | Residentielle Exits | Urteil |
|---|---|---|---|---|
| Öffentliche APIs und offene Daten | en.wikipedia.org | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Öffentliche APIs und offene Daten | api.github.com | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Öffentliche APIs und offene Daten | data.sec.gov | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Öffentliche APIs und offene Daten | api.worldbank.org | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Öffentliche APIs und offene Daten | ecb.europa.eu | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Referenz und Dokumentation | docs.python.org | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Referenz und Dokumentation | developer.mozilla.org | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Referenz und Dokumentation | rfc-editor.org | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Referenz und Dokumentation | en.wikipedia.org | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Referenz und Dokumentation | arxiv.org | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Referenz und Dokumentation | stackoverflow.com | 0 von 3 | 0 von 3 | Auf beiden Wegen blockiert |
| Nachrichten | bbc.com | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Nachrichten | reuters.com | 0 von 3 | 0 von 3 | Auf beiden Wegen blockiert |
| Nachrichten | nytimes.com | 0 von 3 | 0 von 3 | Auf beiden Wegen blockiert |
| Nachrichten | theguardian.com | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Nachrichten | edition.cnn.com | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Nachrichten | bloomberg.com | 0 von 3 | 0 von 3 | Auf beiden Wegen blockiert |
| E-Commerce-Suche | amazon.com | 3 von 3 | 2 von 3 | Kein Proxy nötig |
| E-Commerce-Suche | walmart.com | 0 von 3 | 3 von 3 | Residentielle IP nötig |
| E-Commerce-Suche | ebay.com | 0 von 3 | 0 von 3 | Auf beiden Wegen blockiert |
| E-Commerce-Suche | bestbuy.com | 0 von 3 | 0 von 3 | Auf beiden Wegen Timeout |
| E-Commerce-Suche | etsy.com | 0 von 3 | 0 von 3 | Auf beiden Wegen blockiert |
| Reise | booking.com | 0 von 3 | 2 von 3 | Residentielle IP nötig |
| Reise | expedia.com | 0 von 3 | 0 von 3 | Auf beiden Wegen blockiert |
| Reise | airbnb.com | 3 von 3 | 2 von 3 | Kein Proxy nötig |
| Reise | tripadvisor.com | 0 von 3 | 0 von 3 | Auf beiden Wegen blockiert |
| Reise | kayak.com | 0 von 3 | 3 von 3 | Residentielle IP nötig |
| Social, Jobs und Suche | linkedin.com | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Social, Jobs und Suche | indeed.com | 0 von 3 | 0 von 3 | Auf beiden Wegen blockiert |
| Social, Jobs und Suche | google.com | 0 von 3 | 0 von 3 | Braucht einen Browser |
“Auf beiden Wegen blockiert” bedeutet, dass ein einfacher HTTP-Client von beiden Netzwerken blockiert wurde. Ein echter Browser oder eine Scraping-API, die Browser-Prüfungen bewältigt, kann bei diesen Seiten durchaus erfolgreich sein; dieser Test hat das nicht ausprobiert.
Was die Ergebnisse zeigen
Öffentliche APIs, offene Daten und Dokumentation brauchen keinen Proxy. Jede API- und Referenzseite, die wir ausprobiert haben, bis auf eine, funktionierte mit einer Rechenzentrums-IP bei jedem Versuch. Diese Dienste sind dafür gebaut, von Programmen genutzt zu werden. Was sie wollen, ist ein aussagekräftiger User-Agent, vernünftige Anfragenraten und, bei manchen, ein API-Schlüssel. Ein Proxy fügt nur Kosten hinzu, sonst nichts.
Viele große Seiten blockieren Rechenzentrums-IPs überhaupt nicht. Drei der sechs Nachrichten-Homepages, die Amazon-Suche, die Airbnb-Suche und eine LinkedIn-Unternehmensseite lieferten dreimal von drei einem Cloud-Server echten Inhalt. Für die Sammlung geringen Volumens von solchen Seiten ist es vertretbar, ohne Proxy zu beginnen, solange man sich an die Nutzungsbedingungen und Ratenlimits der Seite hält.
Manche Seiten blockieren nach IP-Reputation, und genau dort zählen residentielle Exits. Walmart, Kayak und Booking.com wiesen die Rechenzentrums-IP jedes Mal ab und lieferten Inhalt über residentielle Exits. Diese Seiten bewerten das Netzwerk, aus dem eine Anfrage kommt, und die Adresse eines Cloud-Servers schneidet dabei schlecht ab. Das ist der Fall, für den residentielle Proxys existieren.
Manche Seiten blockieren den Client, nicht die IP. eBay, Etsy, Expedia, Tripadvisor, Indeed, Stack Overflow und drei Nachrichtenseiten blockierten den einfachen Python-Client von beiden Netzwerken aus. Sie prüfen, wie sich der Client verbindet und verhält, etwa seinen TLS-Fingerabdruck, seine HTTP-Header und ob er JavaScript ausführt, bevor sie darauf schauen, woher er kommt. Eine residentielle IP behebt keinen Client, der sich als Skript zu erkennen gibt. Unser Leitfaden zu TLS- und HTTP/2-Fingerprinting erklärt, wie diese Prüfungen funktionieren.
Manche Seiten brauchen einen Browser, egal welches Netzwerk. Google Search lieferte beiden Netzwerken eine Seite, die nach JavaScript verlangte, ohne Ergebnisse im HTML. Für solche Seiten besteht die Wahl zwischen einem Headless-Browser und einer API, die die Daten direkt zurückgibt.
Wie man erkennt, was eine Seite braucht
Man kann die meisten Zielseiten an einem Nachmittag in diese Gruppen einordnen, bevor man überhaupt etwas kauft. Die folgende Funktion ist die Prüfung, die wir im Test verwendet haben: Sie ruft eine Seite ab und entscheidet, ob man den echten Inhalt bekommen hat, eine Blockierung, einen Fehler oder eine leere Hülle.
import re
import requests
BLOCK = re.compile(r"captcha|access denied|are you a robot|just a moment|unusual traffic|"
r"verify you are human|request blocked|pardon our interruption|enable javascript and cookies",
re.IGNORECASE)
HEADERS = {
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36",
"Accept-Language": "en-US,en;q=0.9",
}
def check(url, marker, proxies=None):
"""Did this request get the real content, or a block, an error or an empty shell?"""
try:
response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=30)
except requests.RequestException as error:
return {"url": url, "result": "error", "detail": type(error).__name__}
body = response.text
if response.status_code != 200:
result = "blocked" if response.status_code in (202, 401, 403, 429, 503) else "error"
elif BLOCK.search(body[:20000]) and marker.lower() not in body.lower():
result = "blocked"
elif marker.lower() not in body.lower():
result = "no content"
else:
result = "ok"
return {"url": url, "result": result, "status": response.status_code, "bytes": len(response.content)}Wähle einen Marker, der nur in dem Inhalt vorkommt, den du haben willst, etwa den Klassennamen einer Ergebniskarte oder ein Feldname in einer JSON-Antwort. Verwende kein Wort aus dem Seitentitel: Blockseiten und Login-Sperren wiederholen ihn oft. Führe es dann für einige Seiten jedes Ziels aus:
from check import check
print(check("https://api.github.com/repos/python/cpython", '"full_name"'))
print(check("https://www.ebay.com/sch/i.html?_nkw=laptop", "srp-results")){'url': 'https://api.github.com/repos/python/cpython', 'result': 'ok', 'status': 200, 'bytes': 6617}
{'url': 'https://www.ebay.com/sch/i.html?_nkw=laptop', 'result': 'blocked', 'status': 403, 'bytes': 1832}Führe es dort aus, wo dein Scraper tatsächlich laufen wird (ein Cloud-Server, nicht dein Laptop, falls dort die Produktion läuft), mehrmals über einen Tag verteilt. Die Ergebnisse führen zu einer Entscheidung:
| Was man von einem Cloud-Server aus sieht | Was es meist bedeutet | Was man verwenden sollte |
|---|---|---|
| Durchgehend echter Inhalt | Die Seite blockiert Rechenzentrums-Traffic bei deinem Volumen nicht | Kein Proxy, oder eine Rechenzentrums-IP für Skalierung |
| Blockierungen oder Herausforderungen, und echter Inhalt von einer Heimverbindung | Die Seite blockiert nach IP-Reputation | Residential Proxys |
| Blockierungen von jedem Netzwerk | Die Seite prüft den Client | Ein echter Browser oder eine Scraping-API, meist mit residentiellen IPs darunter |
| Leere Hüllen ohne Daten | Der Inhalt wird durch JavaScript gerendert | Ein Headless-Browser, oder die API, die die Seite aufruft |
| Login-Sperren | Der Inhalt ist nicht öffentlich | Nicht ohne Erlaubnis sammeln |
Zwei Verfeinerungen:
- Das Volumen ändert die Antwort. Eine Seite, die zehn Anfragen von einem Cloud-Server ignoriert, kann zehntausend blockieren. Teste erneut mit der Rate, mit der du tatsächlich laufen willst, nicht nur einmal.
- Der Standort ändert die Antwort. Seiten liefern je nach Land unterschiedlichen Inhalt und wenden unterschiedliche Regeln an. Wenn du Daten brauchst, wie sie aus Deutschland gesehen werden, teste aus Deutschland.
Die mittleren Optionen
Die Wahl besteht nicht nur zwischen keinem Proxy und residentiellen Proxys.
- Rechenzentrums-IPs sind günstig und schnell, und gut geeignet für Seiten, die sie nicht blockieren. Unser Vergleich von ISP- und Rechenzentrums-Proxys behandelt, wann sie ausreichen.
- ISP-Proxys sind statische Adressen, die bei Internetanbietern für Privatkunden registriert sind. Sie eignen sich für lange Sitzungen und Logins in eigenen Konten, wenn man dieselbe IP über Tage hinweg braucht. Shifters ISP-Proxys kommen mit unbegrenztem Traffic, daher eignen sie sich auch für schwere, gleichbleibende Workloads auf Seiten, die sie akzeptieren.
- Eine Scraping-API übernimmt den Browser, Wiederholungsversuche und die IP-Wahl für dich und berechnet pro erfolgreicher Seite statt pro Gigabyte. Sie ist oft die günstigste Option für Seiten, die den Client prüfen, weil man die Browser-Schicht nicht selbst bauen und pflegen muss. Siehe unseren Leitfaden zum Scrapen von JavaScript-lastigen Seiten.
- Residential Proxys sind das richtige Werkzeug, wenn eine Seite das Netzwerk beurteilt, aus dem eine Anfrage kommt: wenn derselbe Client von einer Heimverbindung erfolgreich ist und von einem Cloud-Server scheitert.
FAQ
Brauche ich einen Proxy fürs Web Scraping?
Nicht immer. In unserem Test lieferten 16 von 30 öffentlichen Seiten, einschließlich jeder öffentlichen API und der meisten Dokumentationsseiten, einem Cloud-Server echten Inhalt, ohne Proxy. Teste deine Zielseiten zuerst, von dort, wo dein Scraper laufen wird.
Wann brauche ich einen residentiellen Proxy?
Wenn eine Seite Anfragen von Rechenzentrums-IPs blockiert, aber denselben Client von einer Heimverbindung bedient. In unserem Test verhielten sich drei von 30 Seiten so (Walmart, Kayak und Booking.com).
Warum werde ich mit einem residentiellen Proxy immer noch blockiert?
Meist, weil die Seite den Client prüft, nicht die IP. Viele Seiten blockieren HTTP-Clients, deren TLS-Fingerabdruck, Header oder fehlendes JavaScript sie als Skripte erkennbar machen. Elf der 30 Seiten in unserem Test scheiterten mit einem einfachen Python-Client an beiden Netzwerken. Ein echter Browser oder eine Scraping-API ist die Lösung, nicht eine andere IP.
Reichen Rechenzentrums-Proxys fürs Scraping aus?
Für öffentliche APIs, Dokumentation, viele Nachrichtenseiten und manche große Einzelhändler, ja, bei moderatem Volumen. Für Seiten, die IP-Reputation bewerten, nein. Teste jedes Ziel, statt es anzunehmen.
Fazit
Ein residentieller Proxy löst ein ganz bestimmtes Problem: eine Seite, die Anfragen nach dem Netzwerk beurteilt, aus dem sie kommen. Er hilft nicht bei Seiten, die den Client prüfen, und ist unnötig für öffentliche APIs und Seiten, die Cloud-Traffic nicht blockieren. Teste jedes Ziel dort, wo dein Scraper laufen wird, ordne es in eine dieser Gruppen ein und zahle nur dort für residentiellen Traffic, wo er das Ergebnis verändert. Unsere Best Practices für Web Scraping behandeln den Rest der verantwortungsvollen Sammlung.