Residential proxies sind das, was wir verkaufen, daher mag es seltsam erscheinen, 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 Residential IP benötigen, welche gar nichts brauchen und welche etwas ganz anderes benötigen, ist die günstigste Optimierung bei der Webdatenerfassung.
Um das konkret zu machen, haben wir einen kleinen Test durchgeführt. Am 9. Oktober 2026 haben wir 30 öffentliche Seiten jeweils dreimal von einem Cloud-Server mit einer Datacenter-IP-Adresse angefragt, und dann erneut über Shifter Residential Proxies mit US-Exits. Beide Durchläufe verwendeten denselben einfachen Python-HTTP-Client. Sechzehn der 30 Seiten funktionierten bei jedem Versuch über die Datacenter-IP. Drei funktionierten nur über Residential Exits. Die übrigen elf schlugen auf beide Arten fehl, aus Gründen, die eine Residential IP nicht beheben kann.
Unser Test: 30 Seiten, Datacenter IP vs. Residential Proxies
Die Ziele deckten sechs Arten von Seiten ab: öffentliche APIs und offene Daten, Referenz- und Dokumentationsseiten, Nachrichten-Homepages, E-Commerce-Suchseiten, Reise-Suchseiten und eine Reihe von Social-, Job- und Suchseiten. Jede Anfrage verwendete 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 wählten die Marker, indem wir gespeicherte Antworten aus beiden Netzwerken vor dem endgültigen Durchlauf untersuchten, und verwarfen fünf Kandidatenseiten, bei denen wir nicht unterscheiden konnten, ob es sich um echten Inhalt, eine Login-Sperre oder eine leere JavaScript-Hülle handelte.
| Kategorie | Seite | Datacenter IP | Residential 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 beide Arten blockiert |
| Nachrichten | bbc.com | 3 von 3 | 3 von 3 | Kein Proxy nötig |
| Nachrichten | reuters.com | 0 von 3 | 0 von 3 | Auf beide Arten blockiert |
| Nachrichten | nytimes.com | 0 von 3 | 0 von 3 | Auf beide Arten 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 beide Arten 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 | Residential IP nötig |
| E-Commerce-Suche | ebay.com | 0 von 3 | 0 von 3 | Auf beide Arten blockiert |
| E-Commerce-Suche | bestbuy.com | 0 von 3 | 0 von 3 | Auf beide Arten Timeout |
| E-Commerce-Suche | etsy.com | 0 von 3 | 0 von 3 | Auf beide Arten blockiert |
| Reisen | booking.com | 0 von 3 | 2 von 3 | Residential IP nötig |
| Reisen | expedia.com | 0 von 3 | 0 von 3 | Auf beide Arten blockiert |
| Reisen | airbnb.com | 3 von 3 | 2 von 3 | Kein Proxy nötig |
| Reisen | tripadvisor.com | 0 von 3 | 0 von 3 | Auf beide Arten blockiert |
| Reisen | kayak.com | 0 von 3 | 3 von 3 | Residential 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 beide Arten blockiert |
| Social, Jobs und Suche | google.com | 0 von 3 | 0 von 3 | Benötigt einen Browser |
„Auf beide Arten 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, könnte bei diesen Seiten durchaus erfolgreich sein; dieser Test hat das nicht ausprobiert.
Nach Kategorien ergeben sich die Ergebnisse wie folgt:
| Kategorie | Seiten | Kein Proxy nötig | Residential IP nötig | Auf beide Arten fehlgeschlagen |
|---|---|---|---|---|
| Öffentliche APIs und offene Daten | 5 | 5 | 0 | 0 |
| Referenz und Dokumentation | 6 | 5 | 0 | 1 |
| Nachrichten | 6 | 3 | 0 | 3 |
| E-Commerce-Suche | 5 | 1 | 1 | 3 |
| Reisen | 5 | 1 | 2 | 2 |
| Social, Jobs und Suche | 3 | 1 | 0 | 2 |
| Gesamt | 30 | 16 | 3 | 11 |
Was der 30-Seiten-Test zeigt
Öffentliche APIs, offene Daten und Dokumentation benötigen keinen Proxy. Jede API und Referenzseite, die wir ausprobiert haben, bis auf eine, funktionierte bei jedem Versuch von einer Datacenter-IP aus. Diese Dienste sind dafür gebaut, von Programmen genutzt zu werden. Was sie wollen, ist ein aussagekräftiger User-Agent, vernünftige Anfrageraten und, bei manchen, ein API-Schlüssel. Ein Proxy verursacht nur Kosten und bringt sonst nichts.
Viele große Seiten blockieren Datacenter-IPs überhaupt nicht. Drei der sechs Nachrichten-Homepages, die Amazon-Suche, die Airbnb-Suche und eine LinkedIn-Unternehmensseite lieferten dreimal von drei Versuchen echten Inhalt an einen Cloud-Server. Für die Datenerfassung in geringem Umfang von solchen Seiten ist es vernünftig, ohne Proxy zu beginnen, solange man sich an die Nutzungsbedingungen und Ratenbegrenzungen der Seite hält.
Amazon und Airbnb funktionierten jeweils dreimal von drei Versuchen über die Datacenter-IP und zweimal von drei über Residential Exits. Bei drei Versuchen pro Seite liegt ein Fehlschlag innerhalb der normalen Schwankung, nicht als Beleg dafür, dass Residential IPs dort schlechter abschneiden. Jede Residential-Anfrage verlässt eine andere Heimverbindung, und ein einzelner Exit kann langsam sein oder kürzlich von derselben Seite erkannt worden sein, auf eine Weise, wie es bei einem festen Cloud-Server nicht der Fall ist. Die Lehre daraus ist, mehrmals zu testen, bevor man sich entscheidet, was die untenstehende Prüfung einfach macht.
Manche Seiten blockieren nach IP-Reputation, und genau dort kommen Residential Exits ins Spiel. Walmart, Kayak und Booking.com wiesen die Datacenter-IP jedes Mal zurück und lieferten Inhalt über Residential Exits. Diese Seiten bewerten das Netzwerk, aus dem eine Anfrage kommt, und die Adresse eines Cloud-Servers schneidet dabei schlecht ab. Das ist genau der Fall, für den Residential Proxies 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. 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 Residential 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 benötigen einen Browser, egal welches Netzwerk. Die Google-Suche lieferte beiden Netzwerken eine Seite, die nach JavaScript verlangte, ohne Ergebnisse im HTML. Bei solchen Seiten besteht die Wahl zwischen einem Headless-Browser und einer API, die die Daten direkt zurückgibt.
Wie man herausfindet, was eine Seite benötigt
Man kann die meisten Ziele an einem Nachmittag in diese Gruppen einsortieren, bevor man überhaupt etwas kauft. Die Funktion unten ist die Prüfung, die wir im Test verwendet haben: Sie ruft eine Seite ab und entscheidet, ob man den echten Inhalt, eine Blockierung, einen Fehler oder eine leere Hülle erhalten hat.
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ählen Sie einen Marker, der nur im gewünschten Inhalt vorkommt, etwa den Klassennamen einer Ergebniskarte oder ein Feldnamen in einer JSON-Antwort. Verwenden Sie kein Wort aus dem Seitentitel: Blockseiten und Login-Sperren wiederholen ihn oft. Führen Sie die Prüfung dann bei einigen Seiten pro Ziel 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ühren Sie die Prüfung von dort aus, wo Ihr Scraper tatsächlich laufen wird (ein Cloud-Server, nicht Ihr Laptop, falls dort die Produktion läuft), mehrmals über einen Tag verteilt. Die Ergebnisse lassen sich einer Entscheidung zuordnen:
| Was Sie von einem Cloud-Server aus sehen | Was es normalerweise bedeutet | Was zu verwenden ist |
|---|---|---|
| Echter Inhalt, durchgehend | Die Seite blockiert Datacenter-Traffic bei Ihrem Volumen nicht | Kein Proxy, oder eine Datacenter IP für Skalierung |
| Blockierungen oder Challenges, aber echter Inhalt von einer Heimverbindung | Die Seite blockiert nach IP-Reputation | Residential Proxies |
| Blockierungen von jedem Netzwerk | Die Seite prüft den Client | Ein echter Browser oder eine Scraping-API, meist mit Residential IPs im Hintergrund |
| Leere Hüllen ohne Daten | Der Inhalt wird per JavaScript gerendert | Ein Headless-Browser, oder die API, die die Seite aufruft |
| Login-Sperren | Der Inhalt ist nicht öffentlich | Nicht ohne Erlaubnis erfassen |
Zwei Verfeinerungen:
- Das Volumen verändert die Antwort. Eine Seite, die zehn Anfragen von einem Cloud-Server ignoriert, kann zehntausend blockieren. Testen Sie erneut bei der geplanten Rate, nicht nur einmal.
- Der Standort verändert die Antwort. Seiten liefern je nach Land unterschiedliche Inhalte und wenden unterschiedliche Regeln an. Wenn Sie Daten benötigen, wie sie aus Deutschland erscheinen, testen Sie aus Deutschland.
Wann ortsspezifische Daten einen Residential Proxy benötigen
Unser Test stellte eine Frage: Liefert die Seite überhaupt ihren Inhalt? Eine zweite Frage ist oft wichtiger: Liefert sie den Inhalt, den eine echte Person an einem bestimmten Ort sehen würde?
Ein Cloud-Server befindet sich an einer Handvoll Rechenzentrumsstandorte, und viele Seiten erkennen Rechenzentrumsadressen und zeigen ihnen eine Standardversion: die globale Startseite, Preise in US-Dollar, keinen lokalen Lagerbestand oder gar keine Werbung. Wenn Ihre Aufgabe davon abhängt, was Nutzer in einem bestimmten Land oder einer bestimmten Stadt sehen, benötigen Sie einen Exit dort, in einem Netzwerk, das diese Nutzer tatsächlich verwenden. Das betrifft:
- Lokale Suchergebnisse und Rankings, die sich nach Stadt unterscheiden.
- Preise, Verfügbarkeit und Lieferoptionen, die Einzelhändler und Reiseseiten nach Markt festlegen.
- Anzeigen und Landingpages, die Werbetreibende nach Standort ausrichten und die oft nicht an Datacenter-Traffic ausgeliefert werden. Deren Prüfung ist der Kern der Anzeigenverifizierung.
- Inhalte, die nach Land lizenziert oder eingeschränkt sind.
In diesen Fällen blockiert die Seite möglicherweise nie eine Datacenter-IP, und Sie würden trotzdem die falschen Daten erfassen, ohne einen Residential Exit am richtigen Ort.
Die mittleren Optionen
Die Wahl besteht nicht nur zwischen keinem Proxy und Residential Proxies.
- Datacenter IPs sind günstig und schnell und eignen sich gut für Seiten, die sie nicht blockieren. Unser Vergleich von ISP- und Datacenter-Proxys behandelt, wann sie ausreichen.
- ISP-Proxys sind Adressen, die bei Internetanbietern für Privatkunden registriert sind und für Sie über einen längeren Zeitraum gehalten werden. Sie eignen sich für lange Sitzungen und Logins bei Ihren eigenen Konten. Shifters ISP-Proxys bleiben während der gesamten Abrechnungsperiode in der von Ihnen gewählten Stadt und beim gewählten ISP (ASN) und beinhalten unbegrenzten Traffic, sodass sie sich auch für umfangreiche, gleichmäßige Workloads auf Seiten eignen, die sie akzeptieren.
- Eine Scraping-API übernimmt den Browser, Wiederholungsversuche und die IP-Auswahl für Sie und berechnet pro erfolgreicher Seite statt pro Gigabyte. Sie ist oft die günstigste Option für Seiten, die den Client prüfen, weil Sie die Browser-Schicht nicht selbst bauen und pflegen müssen. Siehe unseren Leitfaden zum Scraping JavaScript-lastiger Seiten.
- Residential Proxies 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ür Web Scraping?
Nicht immer. In unserem Test lieferten 16 von 30 öffentlichen Seiten, darunter jede öffentliche API und die meisten Dokumentationsseiten, echten Inhalt an einen Cloud-Server ohne Proxy. Testen Sie Ihre Ziele zuerst, von dort, wo Ihr Scraper laufen wird.
Wann brauche ich einen Residential Proxy?
Wenn eine Seite Anfragen von Datacenter-IPs blockiert, aber denselben Client von einer Heimverbindung aus bedient. In unserem Test verhielten sich drei von 30 Seiten (Walmart, Kayak und Booking.com) auf diese Weise.
Warum werde ich trotz Residential 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 identifizieren. Elf der 30 Seiten in unserem Test scheiterten bei beiden Netzwerken mit einem einfachen Python-Client. Ein echter Browser oder eine Scraping-API ist die Lösung, nicht eine andere IP.
Reichen Datacenter-Proxys fürs Scraping aus?
Für öffentliche APIs, Dokumentation, viele Nachrichtenseiten und manche großen Einzelhändler, ja, bei moderatem Volumen. Für Seiten, die die IP-Reputation bewerten, nein. Testen Sie jedes Ziel, statt es anzunehmen.
Was ist der Unterschied zwischen einer Datacenter IP und einer Residential IP?
Eine Datacenter IP gehört einem Hosting- oder Cloud-Anbieter. Eine Residential IP gehört einem Internetanbieter für Privatkunden und wird von einer echten Heimverbindung genutzt. Viele Seiten vertrauen Residential-Adressen mehr, weil gewöhnliche Besucher sie verwenden.
Wie teste ich, ob eine Seite Datacenter-IPs blockiert?
Fragen Sie einige Seiten von einem Cloud-Server ab und prüfen Sie die Antwort auf einen Marker, der nur im echten Inhalt vorkommt, nicht nur auf den Statuscode. Wiederholen Sie dies dann über einen Residential Exit. Wenn der Cloud-Server abgewiesen wird und der Residential Exit bedient wird, blockiert die Seite nach IP-Reputation.
Brauche ich für ortsspezifische Daten einen Residential Proxy?
In der Regel ja. Selbst Seiten, die Cloud-Server nie blockieren, zeigen ihnen oft eine Standardversion der Seite. Um die lokalen Ergebnisse, Preise oder Anzeigen zu sehen, die Nutzer in einem Land oder einer Stadt sehen, benötigen Sie einen Exit an diesem Ort.
Warum funktionierten Amazon und Airbnb in Ihrem Test über Residential Proxys seltener?
Jede Seite scheiterte einmal bei drei Residential-Versuchen, was bei drei Versuchen innerhalb der normalen Schwankung liegt. Jede Residential-Anfrage verlässt eine andere Heimverbindung, und ein einzelner Exit kann langsam sein oder kürzlich von der Seite erkannt worden sein. Testen Sie mehrmals, bevor Sie eine Schlussfolgerung ziehen.
Fazit
Ein Residential 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. Testen Sie jedes Ziel von dort, wo Ihr Scraper laufen wird, ordnen Sie es einer dieser Gruppen zu, und bezahlen Sie nur dort für Residential-Traffic, wo er das Ergebnis verändert. Unsere Best Practices für Web Scraping behandeln den Rest der verantwortungsvollen Datenerfassung.