Ein Scraper funktioniert im Testlauf einwandfrei.
Dann richtet man ihn auf eine echte Website und erhält:
403 Forbidden.
Oder ein CAPTCHA.
Oder die Seite wird in Chrome geladen, gibt aber etwas völlig anderes zurück als dein Skript.
Man ändert die IP-Adresse. Es funktioniert für ein paar Anfragen und wird dann wieder blockiert.
Genau für diese Art von Problemen wurde DataDome entwickelt, um sie für automatisierten Traffic zu erzeugen.
Wichtig zu verstehen ist, dass DataDome nicht einfach fragt:
„Ist diese IP verdächtig?“
Moderne Bot-Erkennung funktioniert viel eher so:
„Passen diese IP-Adresse, diese Netzwerkverbindung, dieser Browser, dieses Gerät, dieses Anfrage-Muster und diese Sitzung zusammen?“
Dieser Unterschied erklärt, warum der Wechsel des Proxys manchmal hilft, warum er oft nicht hilft und warum ein Scraper, der auf HTTP-Ebene völlig normal aussieht, dennoch scheitern kann.
Dieser Leitfaden erklärt, wie DataDome funktioniert, welche Signale es nutzen kann, wie eine DataDome-Sperre aussieht, warum sich Browser und Skripte unterschiedlich verhalten und wo Proxys, Browser-Automatisierung und Scraping-APIs ins Bild passen.
Was ist DataDome?
DataDome ist eine Plattform zum Schutz vor Bots und Online-Betrug, die von Websites, mobilen Anwendungen und APIs genutzt wird, um legitime Nutzer von automatisiertem oder böswilligem Datenverkehr zu unterscheiden.
Websitebetreiber nutzen Systeme wie DataDome, um folgende Aktivitäten einzudämmen:
- unbefugtes Scraping;
- Credential Stuffing;
- Versuche, Konten zu übernehmen;
- die Erstellung gefälschter Konten;
- Missbrauch von Beständen;
- Zahlungsbetrug;
- automatisiertes Scannen nach Sicherheitslücken;
- aggressive Bots;
- unerwünschte KI-Agenten.
Für jemanden, der öffentliche Webdaten sammelt, steht DataDome auf der anderen Seite der Gleichung.
Ihre Anfrage erreicht eine geschützte Website, doch bevor die Anwendung entscheidet, welche Inhalte zurückgegeben werden sollen, kann DataDome die Anfrage auswerten und entscheiden, ob sie legitim, verdächtig oder automatisiert erscheint.
Das Ergebnis kann sein:
Zulassen
Die Anfrage wird normal fortgesetzt.
Geräteprüfung
Es wird eine zusätzliche Browser-/Geräteüberprüfung durchgeführt.
CAPTCHA
Der Client erhält eine interaktive Aufgabe.
Blockieren
Die Anfrage wird abgelehnt.
Deshalb können zwei Anfragen an genau dieselbe URL zu völlig unterschiedlichen Antworten führen.
Die URL hat sich nicht geändert.
Der Client hingegen schon.
So funktioniert DataDome
Ein nützliches vereinfachtes Modell sieht wie folgt aus:
Client → geschützte Website/DataDome → Erkennungsentscheidung → Website
Der Erkennungsschritt ist der Punkt, an dem die meisten Probleme mit Scrapern auftreten.
DataDome kann Signale aus mehreren Ebenen einer Verbindung auswerten, anstatt sich auf einen einzigen einfachen Indikator zu verlassen.
Zu diesen Ebenen können gehören:
| Ebene | Beispielsignale |
|---|
| Netzwerk | IP-Adresse, ASN, Netzwerk-Reputation |
| TLS | TLS-Fingerabdruck und Verbindungseigenschaften |
| HTTP | Header, Header-Konsistenz, Anfrageeigenschaften |
| Browser | Browser-Fingerabdruck und Umgebung |
| Gerät | Betriebssystem, Hardware und Ausführungssignale |
| JavaScript | Ergebnisse aus clientseitigen Prüfungen |
| Sitzung | Cookies und Kontinuität zwischen Anfragen |
| Verhalten | Zeitablauf und Interaktionsmuster |
| Reputation | Frühere Aktivitäten im Zusammenhang mit der Infrastruktur |
Keine einzelne Zeile beweist zwangsläufig, dass eine Anfrage automatisiert ist.
Der Mehrwert ergibt sich aus dem Vergleich aller Zeilen miteinander.
Eine private IP-Adresse mit einem unmöglichen Browser-Fingerabdruck kann dennoch verdächtig erscheinen.
Ein scheinbar perfekter User-Agent, der von einem inkonsistenten TLS-Client stammt, kann dennoch verdächtig erscheinen.
Ein echter Browser, der Hunderte von sich stark wiederholenden Anfragen generiert, kann dennoch verdächtig erscheinen.
Das ist der grundlegende Unterschied zwischen modernen Anti-Bot-Systemen und alten IP-Blockierungssystemen.
DataDome-Erkennung: Die wichtigsten Ebenen
1. IP-Reputation
Die IP-Reputation ist nach wie vor wichtig.
Eine IP-Adresse kann eine Vorgeschichte haben.
Beispielsweise kann eine Infrastruktur einen schlechten Ruf entwickeln, wenn große Mengen an missbräuchlichem oder offensichtlich automatisiertem Datenverkehr von ihr ausgehen.
DataDome kann berücksichtigen, ob der Datenverkehr von folgenden Quellen stammt:
- bekannter Hosting-Infrastruktur;
- Rechenzentrums-Adressbereichen;
- gemeinsam genutzten Proxys;
- Residential-Proxys;
- kostenlosen öffentlichen Proxy-Netzwerken;
- zuvor verdächtigen Adressen.
Die IP-Reputation ist jedoch nur ein Indikator.
Deshalb sind Aussagen wie:
„Verwende einen Residential-Proxy, dann kann DataDome dich nicht erkennen.“
irreführend sind.
Eine Residential-Adresse kann eine Netzwerkanfrage zwar eher wie gewöhnlichen Verbraucherverkehr aussehen lassen.
Sie kann jedoch nicht automatisch dafür sorgen, dass der Rest der Anfrage konsistent ist.
2. HTTP-Header
Browser senden eine erkennbare Sammlung von Headern.
Auch Automatisierungstools senden Header.
Das Interessante daran ist nicht nur, ob eine Anfrage einen „User-Agent
“ enthält.
Es geht darum, ob die Anfrage als Ganzes Sinn ergibt.
Stellen Sie sich zum Beispiel einen Client vor, der vorgibt, eine aktuelle Chrome-Version zu sein, dabei aber eine Reihe von Headern sendet, die normalerweise nicht zu diesem Browser passen.
Einzeln betrachtet mag jeder Wert plausibel erscheinen.
In ihrer Gesamtheit jedoch möglicherweise nicht.
Moderne Bot-Erkennung kann nach solchen Unstimmigkeiten suchen.
Die bloße Änderung von „
User-Agent: Mozilla/5.0...
“ verwandelt eine einfache HTTP-Bibliothek nicht in Chrome.
3. TLS-Fingerprinting
Bevor HTTP-Daten über HTTPS ausgetauscht werden, baut der Client eine TLS-Verbindung auf.
Verschiedene Clients können unterschiedliche TLS-Merkmale aufweisen.
Ein Browser, eine Python-HTTP-Bibliothek, ein Befehlszeilen-Client und eine andere Laufzeitumgebung können verschlüsselte Verbindungen auf unterschiedliche Weise herstellen.
Diese Muster lassen sich zu Fingerabdrücken zusammenfassen.
Die Dokumentation von DataDome verweist ausdrücklich auf TLS-Fingerprinting, einschließlich JA3- und JA4-Informationen, als Teil der Daten, die bei der Auswertung des Datenverkehrs herangezogen werden können.
Dies stellt ein erhebliches Problem für vereinfachte Scraping-Konfigurationen dar.
Ihre HTTP-Header könnten beispielsweise angeben:
Chrome unter Windows
während die zugrunde liegende Netzwerkverbindung überhaupt nicht der Chrome-Version entspricht, die Sie angeblich verwenden.
Das Ändern eines HTTP-Headers führt nicht automatisch zu einer Änderung des darunterliegenden TLS-Stacks.
Dies ist ein Grund, warum das reine HTTP-Spoofing letztendlich an seine Grenzen stößt.
4. Browser-Fingerprinting
Sobald JavaScript ausgeführt werden kann, steht der Anti-Bot-Erkennung eine wesentlich umfangreichere Umgebung zur Verfügung.
Ein echter Browser gibt eine Vielzahl von Informationen über sich selbst und das Gerät preis, auf dem er ausgeführt wird.
Zu den potenziellen Signalen gehören Merkmale in Bezug auf:
- die Browserversion;
- das Betriebssystem;
- die Hardware;
- die CPU;
- den Arbeitsspeicher;
- die Grafikumgebung;
- unterstützte Browser-APIs;
- das Rendering-Verhalten;
- die Unterstützung von Funktionen;
- Anzeichen für Automatisierung.
Die Schwierigkeit bei der Automatisierung besteht nicht darin, einen einzigen glaubwürdigen Wert zu erzeugen.
Es geht darum, Hunderte von untereinander konsistenten Werten zu erzeugen.
Angenommen, ein automatisierter Browser gibt an, auf einem bestimmten Betriebssystem zu laufen, während sich andere Teile seiner Umgebung jedoch wie ein anderes verhalten.
Oder die gemeldeten Hardware-Eigenschaften passen nicht zu dem angegebenen Gerät.
Oder die Automatisierung verändert gängige Fingerabdruck-Eigenschaften, lässt sekundäre Signale jedoch unverändert.
Der Browser mag überzeugend wirken, wenn man fünf offensichtliche Eigenschaften untersucht.
Ein Erkennungssystem muss sich jedoch nicht auf fünf beschränken.
5. Erkennung von headless und automatisierten Browsern
Playwright, Puppeteer und Selenium sind unglaublich nützlich.
Sie sind zudem nicht unsichtbar.
Das Starten von Chromium stellt Ihrem Scraper eine echte Browser-Engine zur Verfügung, die viele Probleme löst, die ein einfacher HTTP-Client nicht bewältigen kann:
- Ausführung von JavaScript;
- Rendering;
- Cookies;
- Browser-APIs;
- dynamische Inhalte;
- Navigationsstatus.
Aber „echte Browser-Engine“ bedeutet nicht „von einem normalen Nutzer nicht zu unterscheiden“.
Automatisierungs-Frameworks können erkennbare Unterschiede hervorrufen.
Die eigene Erkennungsdokumentation von DataDome enthält ausdrücklich Erkennungskategorien für automatisierte und headless Browser, darunter Browser, die von Puppeteer, Selenium und Playwright gesteuert werden.
Das bedeutet, dass diese einfache Architektur:
Playwright + Proxy
nicht als universelle Anti-Bot-Lösung betrachtet werden sollte.
Auf einer Website funktioniert sie möglicherweise einwandfrei, auf einer anderen scheitert sie jedoch schnell.
6. JavaScript und Device Check
DataDome kann vom Client auch eine zusätzliche Verifizierung anfordern.
Ein Mechanismus hierfür ist Device Check.
Anstatt sofort ein sichtbares CAPTCHA anzuzeigen, wird JavaScript im Browser ausgeführt, um die Umgebung zu bewerten.
Laut DataDome erfasst der „Device Check“ Hunderte von Signalen und führt mehrere Prüfungen durch, um Automatisierungs-Frameworks, gefälschte Umgebungen und programmatischen Zugriff zu erkennen.
Für einen echten Besucher kann dies ohne erkennbare Unterbrechung ablaufen.
Für einen Scraper entsteht dadurch ein wichtiger Unterschied zwischen:
HTTP-Client
und:
Browser, der in der Lage ist, die erwartete clientseitige Logik auszuführen
Wenn Ihr Scraper nur den anfänglichen HTML-Code herunterlädt und alles ignoriert, was im Browser geschieht, kann er möglicherweise niemals die vollständige Interaktion reproduzieren, die von der geschützten Website erwartet wird.
7. Verhaltenserkennung
Selbst ein technisch überzeugender Browser kann sich dennoch seltsam verhalten.
Betrachten wir zwei Sitzungen.
Sitzung A
Ein Nutzer:
- öffnet eine Produktseite;
- liest 14 Sekunden lang;
- öffnet eine weitere Seite;
- scrollt;
- kehrt zurück;
- sucht;
- öffnet ein Suchergebnis.
Sitzung B
Ein Crawler:
- fragt Produkt 1 ab;
- fragt 300 ms später Produkt 2 ab;
- fragt 300 ms später Produkt 3 ab;
- wiederholt dies hunderte Male.
Beide Sitzungen können Chrome verwenden.
Beide können private IP-Adressen verwenden.
Ihr Verhalten unterscheidet sich offensichtlich.
Die Verhaltenserkennung ermöglicht es einem Anti-Bot-System, Muster statt einzelner Anfragen zu berücksichtigen.
Dies ist insbesondere bei großem Umfang von Bedeutung.
Ein Scraper, der einmal erfolgreich ist, ist nicht unbedingt ein Scraper, der 100.000 Anfragen bewältigen kann.
8. Konsistenz der Sitzung
Moderne Websites sind zustandsbehaftet.
Cookies, der Browserstatus, IP-Adressen und der Anforderungsverlauf sind allesamt Teil einer Sitzung.
Automatisierung lässt sich leichter erkennen, wenn diese Elemente miteinander in Widerspruch stehen.
Beispiele hierfür sind:
- Die IP-Adresse ändert sich ständig, während dasselbe Sitzungs-Cookie bestehen bleibt;
- Die Browser-Identität ändert sich mitten in einer Sitzung;
- Die Navigation springt plötzlich zu nicht zusammenhängenden Ressourcen;
- Cookies, die aus einem früheren Schritt erwartet werden, tauchen nie auf;
- Jede Anfrage verhält sich wie die eines völlig neuen Besuchers.
Aus diesem Grund kann das blinde Wechseln der IP-Adresse bei jeder Anfrage einen Scraper manchmal weniger glaubwürdig machen, anstatt ihn glaubwürdiger erscheinen zu lassen.
Eine Rotation ist sinnvoll.
Kontinuität ist sinnvoll.
Die richtige Wahl hängt von der Arbeitslast ab.
Wie sieht eine DataDome-Sperre aus?
DataDome muss nicht auf jede verdächtige Anfrage auf dieselbe Weise reagieren.
Es gibt verschiedene mögliche Ergebnisse, auf die Sie stoßen können.
403-Antwort
Das deutlichste Signal ist eine HTTP-Antwort mit dem Status „403 Forbidden“.
Gehen Sie jedoch nicht davon aus, dass jeder 403-Fehler im Internet von DataDome stammt.
Überprüfen Sie immer die tatsächliche Antwort.
CAPTCHA-Seite
Anstelle der Zielseite kann die Antwort eine DataDome-Herausforderung enthalten.
Geräteprüfung
Der Browser führt möglicherweise eine unsichtbare Überprüfung durch, bevor der Zugriff fortgesetzt wird.
Dies ist beim Debuggen besonders verwirrend, da die Seite in Ihrem normalen Browser möglicherweise schließlich funktioniert, ohne dass Sie jemals ein CAPTCHA zu sehen bekommen.
Blockierungsseite
Datenverkehr, der als ausreichend verdächtig eingestuft wird, kann eine direkte Blockierungsantwort erhalten.
Unterschiedliches Verhalten in Chrome und Ihrem Scraper
Dies ist einer der deutlichsten Hinweise darauf, dass das Problem nicht an der URL selbst liegt.
Wenn:
Chrome → Inhalt
aber:
Anfragen/cURL/benutzerdefiniertes Skript → Challenge
liegt der Unterschied wahrscheinlich irgendwo im Client, in der Netzwerkidentität, in der Browserausführung oder in der Sitzung.
Warum es nicht ausreicht, nur die IP-Adresse zu ändern
Ein Proxy verändert einen wichtigen Teil der Anfrage:
den scheinbaren Ursprung des Datenverkehrs.
Das ist wertvoll.
Aber Folgendes ändert sich dadurch nicht automatisch:
- Ihre HTTP-Implementierung;
- der TLS-Fingerabdruck;
- die Browserumgebung;
- die JavaScript-Ausführung;
- den Browser-Fingerabdruck;
- Cookies;
- das Timing der Anfrage;
- das Navigationsverhalten;
- die Sitzungslogik.
Betrachten Sie den gesamten Stack:
**IP
- TLS
- HTTP
- Browser
- Gerät
- Sitzung
- Verhalten**
Ein Proxy verändert in erster Linie die erste Schicht.
Das kann ausreichen, wenn die IP-Reputation der Grund für das Scheitern einer Anfrage ist.
Es reicht jedoch nicht aus, wenn mehrere Schichten nicht miteinander übereinstimmen.
Rechenzentrums- vs. Privathaushalts-Proxys mit DataDome
Es gibt keinen universellen „DataDome-Proxy“.
Verschiedene Proxy-Typen lösen unterschiedliche Netzwerkprobleme.
Rechenzentrums-Proxys
Rechenzentrums-IPs sind schnell, kostengünstig und äußerst nützlich für viele Automatisierungsaufgaben.
Ihr Nachteil bei stark geschützten Verbraucher-Websites besteht darin, dass ihre Netzwerkherkunft leichter als Hosting-Infrastruktur klassifiziert werden kann.
Das bedeutet nicht, dass jede Anfrage aus einem Rechenzentrum blockiert wird.
Es bedeutet, dass die IP-Adresse selbst weniger Anhaltspunkte dafür liefert, dass der Client einem gewöhnlichen Verbraucher ähnelt.
Privathaushalts-Proxys
Privathaushalts-Proxys leiten Anfragen über IP-Adressen weiter, die mit Internetverbindungen von Privathaushalten verbunden sind.
Dies kann ein passenderes Netzwerkprofil für Workloads bieten, die öffentliche, an Verbraucher gerichtete Websites betreffen.
Eine Residential-IP ist jedoch nicht gleichbedeutend mit einem Menschen.
DataDome dokumentiert ausdrücklich Modelle, die in der Lage sind, automatisierten Datenverkehr zu identifizieren, der über Residential-Proxys geleitet wird.
Die sinnvolle Sichtweise auf Residential-Proxys lautet daher:
bessere Netzwerkidentität
nicht:
automatische Umgehung des Bot-Schutzes
ISP-Proxys
ISP-Proxys können stabile Sitzungen bieten, während sie IP-Adressbereiche nutzen, die mit privaten Internetdienstanbietern (ISPs) verbunden sind.
Für Workflows, die eine konsistente Identität über eine längere Sitzung hinweg erfordern, kann diese Stabilität von großem Wert sein.
Auch hier spielt der Rest des Clients weiterhin eine Rolle.
Warum eine ständige Proxy-Rotation nach hinten losgehen kann
„Häufiger rotieren“ klingt nach einem naheliegenden Ratschlag.
Das ist jedoch nicht immer richtig.
Stellen Sie sich eine Website-Sitzung vor, die fünf Minuten dauert.
Ein echter Nutzer würde normalerweise während des größten Teils dieser Sitzung dieselbe Netzwerkidentität beibehalten.
Wenn Ihre Automatisierung alle drei Anfragen das Land oder das Netzwerk wechselt, dabei aber dieselben Cookies und dieselbe Kontositzung beibehält, kann diese Kombination unnatürlich wirken.
Für manche Workloads sind rotierende Sitzungen angemessen.
Für andere sorgen „sticky sessions“ für ein kohärenteres Verhalten.
Eine Proxy-Strategie sollte zur Struktur der Anwendung passen, auf die Sie zugreifen.
Was ist mit CAPTCHA-Lösern?
CAPTCHA ist nicht unbedingt der Ausgangspunkt des Entscheidungsprozesses bei DataDome.
Es kann eine Reaktion sein, nachdem eine andere Erkennungsmaßnahme die Sitzung bereits als verdächtig eingestuft hat.
Diese Unterscheidung ist wichtig.
Das Lösen eines CAPTCHAs behebt nicht automatisch:
- einen verdächtigen Browser-Fingerabdruck;
- einen inkonsistenten TLS-Stack;
- eine schlechte IP-Reputation;
- ein unmögliches Sitzungsverhalten.
DataDome hat öffentlich darüber gesprochen, CAPTCHA-Farmen und automatisierte Umgebungen auch dann noch zu erkennen, wenn eine Herausforderung bereits gelöst wurde.
Das Lösen eines CAPTCHAs als das gesamte Problem zu betrachten, lässt also das größere System drumherum außer Acht.
Warum ein Scraper heute funktioniert und morgen versagt
Dies ist eine weitere häufige Quelle für Verwirrung.
An Ihrem Code ändert sich nichts.
Plötzlich sinkt die Erfolgsquote.
Das bedeutet nicht zwangsläufig, dass das Ziel seine Website umgestaltet hat.
Bot-Management-Systeme ändern kontinuierlich ihre Erkennungslogik.
Auch andere Variablen ändern sich:
- Die IP-Reputation entwickelt sich weiter;
- Browser-Versionen werden aktualisiert;
- Die Richtlinien der Website ändern sich;
- Das Datenverkehrsvolumen steigt;
- Ihr Anfragemuster ändert sich;
- Ein Ziel aktiviert strengere Schutzmaßnahmen für einen bestimmten Endpunkt.
Das Scraping gegen moderne Anti-Bot-Systeme ist daher ein operatives Problem und kein einmaliges Konfigurationsproblem.
DataDome und Playwright
Playwright ist nützlich, wenn eine Website eine echte Browserausführung erfordert.
Es kann JavaScript laden, mit Seiten interagieren und den Browserstatus beibehalten.
Dadurch ist es für moderne Websites deutlich leistungsfähiger als eine einfache HTTP-Anfrage-Bibliothek.
Allerdings sorgt Playwright nicht automatisch dafür, dass der Datenverkehr „menschlich“ wirkt.
Die geschützte Website kann weiterhin folgende Faktoren auswerten:
- Browsereigenschaften;
- Anzeichen von Automatisierung;
- Netzwerkidentität;
- Sitzungen;
- Anfragehäufigkeit;
- Verhalten.
Aus diesem Grund kann ein Playwright-Scraper in der Entwicklungsphase erfolgreich sein, im großen Maßstab jedoch unzuverlässig werden.
Browser-Automatisierung löst das Problem der Browserausführung.
Sie löst jedoch nicht jede Anti-Bot-Schicht rund um den Browser.
DataDome und Puppeteer
Das gleiche Prinzip gilt für Puppeteer.
Die Verwendung von Chromium bietet dem Crawler eine wesentlich reichhaltigere Client-Umgebung als reines HTTP.
Das ist nützlich für:
- clientseitig gerenderte Anwendungen;
- dynamische Seiten;
- JavaScript-Navigation;
- Inhalte, die nach dem anfänglichen HTML geladen werden;
- Anwendungen, die Cookies oder den Browserstatus erfordern.
Aber der Browser, die IP-Adresse und das Verhalten müssen weiterhin eine zusammenhängende Sitzung bilden.
Puppeteer ist ein Framework zur Browser-Automatisierung.
Es ist keine Unsichtbarkeitsschicht.
Der Scraping-Stack, auf den es wirklich ankommt
Anstatt zu fragen:
„Welcher Proxy umgeht DataDome?“
ist es sinnvoller, in Schichten zu denken.
| Problem | Relevante Schicht |
|---|
| Schlechte IP-Reputation | Proxy/Netzwerk |
| Falscher Standort | Geografisch ausgerichteter Proxy |
| JavaScript erforderlich | Browser/Rendering |
| Dynamische Inhalte | Browser/Rendering |
| TLS-Inkonsistenz | HTTP/Browser-Stack |
| Nicht übereinstimmender Browser-Fingerabdruck | Browserumgebung |
| Instabilität der Sitzung | Cookie-/Sitzungsverwaltung |
| Übermäßiges Anfragemuster | Crawling-Architektur |
| CAPTCHA/Challenge | Challenge-Behandlung |
| Ständige Anti-Bot-Wartung | Verwaltete Scraping-Infrastruktur |
Dadurch lässt sich die Fehlerbehebung deutlich beschleunigen.
Man hört auf, jedes Problem durch den Austausch des Proxys lösen zu wollen.
Drei Möglichkeiten, Daten von einer durch DataDome geschützten Website zu erfassen
Für die rechtmäßige Datenerfassung, bei der Sie Zugriff auf die Zielseite haben, gibt es im Wesentlichen drei Architekturen.
1. Den Scraper selbst erstellen
Sie haben die volle Kontrolle über:
- den HTTP-Client;
- den Browser;
- den Proxy;
- Sitzung;
- Wiederholungslogik;
- Parsing;
- Rendering;
- Überwachung.
Vorteile:
Maximale Kontrolle.
Nachteile:
Maximaler Wartungsaufwand.
Dies ist sinnvoll, wenn Ihr Workflow so ungewöhnlich ist, dass es sich lohnt, den gesamten Stack selbst zu betreiben.
2. Proxys mit Ihrem eigenen Browser oder Scraper verwenden
Architektur:
Ihr Scraper → Proxy-Netzwerk → Ziel
So behalten Sie die Kontrolle über die Anwendung, während Sie die Netzwerkinfrastruktur auslagern.
Dies ist nützlich, wenn Ihre Hauptprobleme folgende Aspekte betreffen:
- IP-Reputation;
- geografisches Targeting;
- Parallelität;
- Netzwerkrotation;
- stabile Sitzungen.
Geonode Residential Proxies unterstützen beispielsweise geografisches Targeting sowie sowohl rotierende als auch „sticky“ Sitzungskonfigurationen.
Ihre Anwendung bleibt jedoch für alles oberhalb der Proxy-Ebene verantwortlich.
3. Verwenden Sie eine Scraping-API
Architektur:
Ihre Anwendung → Scraping-API → Ziel
Anstatt Browser, Proxy-Auswahl und Extraktionsinfrastruktur selbst zu verwalten, senden Sie die URL an einen Dienst, der für die Erfassung von Webdaten ausgelegt ist.
Dies ist oft die bessere Lösung, wenn die eigentliche Anforderung lautet:
„Gib mir den Seiteninhalt.“
anstatt:
„Ich möchte ein Team für Anti-Bot-/Browser-Infrastruktur unterhalten.“
„Scraper API“ von Geonode kann beispielsweise gerenderte Seiteninhalte als HTML oder Markdown zurückgeben und bietet JavaScript-Rendering, verwaltete Proxy-Infrastruktur, Geo-Targeting, Stapelverarbeitung und Crawling.
Der entscheidende Unterschied liegt in der Verantwortung für die Komplexität.
Bei Proxys:
kontrollieren Sie den Stack.
Bei einer Scraping-API:
verwaltet die Scraping-Plattform einen größeren Teil des Stacks.
Keines der beiden Modelle ist grundsätzlich besser.
Sie lösen unterschiedliche technische Probleme.
Proxy vs. Browser vs. Scraping-API
| Lösung | IP-Adresse ändern | JS ausführen | Browser verwalten | Daten extrahieren | Wartung durch Sie |
|---|
| Nur Proxy | Ja | Nein | Nein | Nein | Hoch |
| Playwright + Proxy | Ja | Ja | Sie | Sie | Hoch |
| Puppeteer + Proxy | Ja | Ja | Sie | Sie | Hoch |
| Scraping-API | Verwaltet | Ja, sofern unterstützt | Verwaltet | Verwaltet | Geringer |
Deshalb ist der Ratschlag „Verwende einfach private Proxys“ unvollständig.
Manchmal ist genau das genau das, was jemand braucht.
Manchmal ist der Proxy nur ein Teil eines viel größeren Problems.
Fehlerbehebung bei DataDome-Blockierungen
Wenn Anfragen fehlschlagen, sollten Sie nicht zehn Dinge gleichzeitig ändern.
Diagnostizieren Sie die jeweilige Ebene.
Problem: Funktioniert im Browser, schlägt im Skript fehl
Mögliche Untersuchungsbereiche:
- JavaScript-Ausführung;
- Unterschiede bei HTTP/TLS-Clients;
- Browser-Fingerabdruck;
- Cookies;
- Sitzungsstatus.
Eine Änderung der IP-Adresse hat möglicherweise keine Auswirkungen, wenn der Fehler vom Client ausgeht.
Problem: Funktioniert zunächst, wird dann blockiert
Prüfen Sie:
- die Anfragefrequenz;
- wiederholte Navigationsmuster;
- IP-/Sitzungsrotation;
- zunehmende Probleme mit der IP-Reputation;
- die Konsistenz der Sitzung.
Die erste Anfrage und die tausendste Anfrage sind nicht gleichwertig.
Problem: IP des Rechenzentrums scheitert, private IP funktioniert
Die Netzwerkreputation ist wahrscheinlich ein wichtiger Faktor bei der Entscheidung.
Das beweist jedoch noch nicht, dass andere Signale ignoriert werden.
Problem: Auch der private Proxy scheitert
Schließen Sie nicht sofort darauf, dass der private Proxy schlecht ist.
Untersuchen Sie:
- Browser-/Client-Fingerabdruck;
- TLS-Merkmale;
- JavaScript-Anforderungen;
- Cookies;
- Anfragemuster;
- Sitzungsaufbau.
Problem: CAPTCHA erscheint wiederholt
Eine CAPTCHA-Schleife kann darauf hindeuten, dass die gesamte Sitzung weiterhin verdächtig erscheint.
Betrachten Sie die Herausforderung als Symptom, nicht unbedingt als Ursache.
Problem: Verschiedene Länder liefern unterschiedliche Ergebnisse
Prüfen Sie, ob:
- sich die Website selbst je nach geografischem Standort unterschiedlich verhält;
- sich die Verfügbarkeit der Inhalte ändert;
- der Cookie-Status konsistent bleibt;
- die IP-Geolokalisierung mit der beabsichtigten Sitzung übereinstimmt.
Erkennt DataDome Privat-Proxys?
Ja, das kann es.
Dies geht ausdrücklich aus der Dokumentation zur Erkennung von DataDome hervor.
Das bedeutet jedoch nicht, dass jede Anfrage über einen Privat-Proxy blockiert wird.
Wäre dies der Fall, würden legitime Nutzer hinter gemeinsam genutzten Privathaushaltsnetzwerken enorme Probleme mit Fehlalarmen verursachen.
Die zutreffendere Aussage lautet:
Eine Privat-IP ist ein Indiz, kein Beweis für einen menschlichen Besucher.
Moderne Erkennungsmechanismen kombinieren dieses Indiz mit weiteren Anhaltspunkten.
Erkennt DataDome Playwright?
DataDome dokumentiert Erkennungsmodelle, die Browser abdecken, die über Automatisierungs-Frameworks wie Playwright, Puppeteer und Selenium gesteuert werden.
Das bedeutet nicht, dass jede Playwright-Sitzung automatisch blockiert wird.
Es bedeutet jedoch, dass die Annahme:
„Playwright verwendet einen echten Browser, daher kann es nicht erkannt werden“
falsch ist.
Verwendet DataDome Browser-Fingerprinting?
Ja.
Browser- und Geräte-Fingerprinting sind Teil der Erkennungsarchitektur von DataDome.
Dadurch kann das System Informationen vergleichen, die vom Browser und der Ausführungsumgebung bereitgestellt werden, anstatt sich auf einfache Identifikatoren wie den User-Agent-Header zu verlassen.
Verwendet DataDome TLS-Fingerprinting?
Die DataDome-Dokumentation verweist auf TLS-Fingerabdrücke und empfiehlt JA3- und JA4-Fingerabdrücke als Signale, die für die Integrationen der Schutz-API verfügbar sind.
Dies ist von Bedeutung, da die TLS-Verbindung hergestellt wird, bevor die normale Webanwendungslogik die Anfrage sieht.
Ein Scraper kann daher perfekt bearbeitete HTTP-Header aufweisen und dennoch einen anderen Netzwerk-Fingerabdruck auf niedrigerer Ebene preisgeben.
Nutzt DataDome maschinelles Lernen?
DataDome beschreibt seine Modelle zur Bedrohungserkennung als auf maschinellem Lernen basierend und kontinuierlich aktualisiert.
Maschinelles Lernen ist keine Zauberei.
Sein praktischer Wert liegt hier in der Fähigkeit, viele Signale und Muster zu kombinieren, anstatt sich auf eine statische Regel zu verlassen, wie zum Beispiel:
IP nach 100 Anfragen blockieren.
Kann DataDome KI-Agenten blockieren?
Ja.
Der Markt für Bot-Management dehnt sich zunehmend über traditionelle Scraper hinaus auf KI-Agenten und LLM-Crawler aus.
DataDome unterstützt nun ausdrücklich die Identifizierung und Authentifizierung kommerzieller Bots und KI-Agenten, während nicht authentifizierter automatisierter Datenverkehr den Richtlinien zur Bedrohungserkennung unterliegen kann.
Dies dürfte zunehmend an Bedeutung gewinnen, da immer mehr KI-Systeme Websites direkt durchsuchen und mit ihnen interagieren.
Lässt sich DataDome umgehen?
Das ist in der Regel die falsche technische Frage.
Es gibt keinen permanenten Header, Proxy-Typ oder Browser-Flag, der ein modernes Erkennungssystem außer Kraft setzen kann.
Eine Konfiguration, die für einen Endpunkt bei einem bestimmten Datenverkehrsaufkommen funktioniert, kann versagen:
- auf einem anderen Endpunkt;
- in größerem Maßstab;
- mit einer anderen Browserversion;
- nach einer Änderung der Erkennungsmodelle.
Bei legitimen Webdaten-Workloads lautet die nachhaltigere Frage:
Welcher Teil meines Scraping-Stacks führt dazu, dass die Anfrage als Automatisierung eingestuft wird, und möchte ich diese Ebene selbst verwalten?
Manchmal liegt die Antwort in der Netzwerkinfrastruktur.
Verwenden Sie eine geeignete Proxy-Konfiguration.
Manchmal liegt die Antwort im Rendering.
Verwenden Sie einen Browser.
Manchmal liegt die Antwort im gesamten operativen Stack.
Verwenden Sie eine verwaltete Scraping-API.
Und manchmal besteht die richtige Antwort darin, stattdessen eine offizielle API oder eine andere autorisierte Datenquelle zu nutzen.
DataDome vs. Cloudflare
DataDome und Cloudflare überschneiden sich in Teilen des Marktes für Bot-Management, sollten jedoch nicht als identische Produkte betrachtet werden.
Cloudflare bietet eine umfassende Infrastrukturplattform, die CDN, DNS, WAF, DDoS-Abwehr und Funktionen zum Bot-Management umfasst.
DataDome konzentriert sich hingegen speziell auf die Erkennung von Bots und Online-Betrug auf Websites, in mobilen Anwendungen und über APIs.
Aus der Perspektive eines Scraper-Entwicklers lautet die Erkenntnis jedoch ähnlich:
Moderner Anti-Bot-Schutz wirkt über mehrere Ebenen hinweg.
Eine funktionierende Strategie kann sich nicht allein auf die Änderung eines einzigen HTTP-Headers stützen.
DataDome vs. CAPTCHA
DataDome ist kein CAPTCHA-Dienst.
CAPTCHA ist eine mögliche Reaktion nach der Erkennung.
Das eigentliche System, das entscheidet, ob ein Client verdächtig ist, kommt davor.
Diese Unterscheidung ist wichtig, da Entwickler oft enormen Aufwand darauf verwenden, das „CAPTCHA zu lösen“, während sie die Signale ignorieren, die zur Anzeige der Sicherheitsabfrage geführt haben.
Die bessere Frage lautet:
Warum wurde diese Sitzung überhaupt einer Sicherheitsabfrage unterzogen?
Wann Residential-Proxys sinnvoll sind
Residential-Proxys sind nützlich, wenn die Netzwerkebene eine Rolle spielt.
Beispiele hierfür sind legitime Anwendungsfälle im Zusammenhang mit:
- geografisch spezifischen öffentlichen Inhalten;
- lokalisierten Suchergebnissen;
- regionalen Preisen;
- Produktverfügbarkeit;
- Marktforschung;
- verteilter Web-Erfassung.
Sie sind besonders nützlich, wenn Sie die volle Kontrolle über Ihren eigenen Scraper behalten möchten.
Die Residential-Proxys von Geonode bieten Residential-IP-Routing mit geografischer Ausrichtung und konfigurierbarem Sitzungsverhalten.
Ein Proxy sollte jedoch das bleiben, was er tatsächlich ist:
Netzwerkinfrastruktur.
Er ist kein Browser.
Er ist kein CAPTCHA-System.
Er ist keine Scraping-Engine.
Und er repariert keinen defekten Fingerabdruck automatisch.
Wann ein „Scraper API“ sinnvoller ist
Ein „Scraper API“ wird attraktiv, wenn die Anti-Bot-Wartung beginnt, die Entwicklung zu dominieren.
Sie sollten zumindest eine verwaltete API in Betracht ziehen, wenn Ihr Team mehr Zeit mit folgenden Aufgaben verbringt:
- Browser-Upgrades;
- Wiederholungslogik;
- Proxy-Orchestrierung;
- Rendering;
- Datenextraktion;
- Sitzungsverwaltung;
- fehlgeschlagene Anfragen;
als mit der eigentlichen Nutzung der Daten.
Mit Geonode Scraper API kann eine Anwendung URLs senden und extrahiertes HTML oder Markdown empfangen, während der Dienst das Rendering und die Proxy-Infrastruktur hinter der Anfrage verwaltet.
Der Kompromiss ist klar:
Eine eigene Entwicklung bietet mehr Kontrolle.
Die Nutzung einer API erspart Infrastrukturarbeit.
Entscheiden Sie sich je nachdem, was Ihr Produkt tatsächlich benötigt.
FAQ
Was ist DataDome?
DataDome ist eine Plattform zum Schutz vor Bots und Online-Betrug, die darauf ausgelegt ist, automatisierten und böswilligen Datenverkehr auf Websites, in mobilen Anwendungen und über APIs zu erkennen.
Wie erkennt DataDome Bots?
Die Plattform kombiniert mehrere Signale, darunter IP-Reputation, HTTP- und Browser-Fingerabdrücke, TLS-Merkmale, Geräteinformationen, Verhaltensmuster und Erkennungsmodelle auf Basis von maschinellem Lernen.
Warum blockiert DataDome meinen Scraper?
Es gibt selten einen einzigen, allgemeingültigen Grund. Die IP-Adresse, der HTTP/TLS-Client, die Browserumgebung, die JavaScript-Unterstützung, die Konsistenz der Sitzung oder das Anfrageverhalten können alle eine Rolle spielen.
Verwendet DataDome CAPTCHA?
Ja, CAPTCHA kann eine Maßnahme gegen verdächtigen Datenverkehr sein. DataDome kann auch eine unsichtbare Geräteprüfung durchführen oder Anfragen direkt blockieren.
Was ist die DataDome-Geräteprüfung?
Die Geräteprüfung ist ein zusätzlicher Verifizierungsmechanismus, der clientseitige Prüfungen durchführt, ohne dass zwangsläufig eine sichtbare Benutzerinteraktion erforderlich ist. Sie wertet Geräte- und Ausführungssignale aus und kann den Client je nach Ergebnis zulassen, abfragen oder blockieren.
Kann ich DataDome umgehen, indem ich meinen User-Agent ändere?
Das Ändern des User-Agents verändert nur einen HTTP-Wert. Es ändert nicht automatisch die TLS-Verbindung, die Browserumgebung, den Geräte-Fingerabdruck, Cookies oder das Verhalten.
Kann DataDome „Headless Chrome“ erkennen?
DataDome dokumentiert ausdrücklich Erkennungskategorien für „Headless“- und automatisierte Browser, einschließlich Browser, die über Puppeteer, Selenium und Playwright instrumentiert sind.
Kann DataDome Playwright erkennen?
Es kann Merkmale identifizieren, die mit der Browser-Automatisierung in Verbindung stehen, einschließlich Playwright-gesteuerter Umgebungen. Die Verwendung von Playwright bedeutet nicht automatisch, dass eine Sitzung blockiert wird, sie sollte jedoch nicht als grundsätzlich unsichtbar angesehen werden.
Kann DataDome Puppeteer erkennen?
Ja, DataDome dokumentiert Erkennungsmodelle, die Puppeteer-basierte Automatisierung und Puppeteer Extra Stealth abdecken.
Kann DataDome private Proxys erkennen?
DataDome verfügt über Erkennungsmodelle für Datenverkehr, der über private Proxys geleitet wird. Eine private IP-Adresse kann nach wie vor nützlich sein, da sie die Netzwerkidentität verändert, macht automatisierten Datenverkehr dadurch jedoch nicht automatisch legitim.
Sind Residential-Proxys für von DataDome geschützte Websites besser geeignet als Rechenzentrums-Proxys?
Residential-Proxys können eine Netzwerkidentität bereitstellen, die dem normalen Verbraucherverkehr näherkommt, was auf verbraucherorientierten Websites nützlich sein kann. Die richtige Wahl hängt jedoch weiterhin vom Ziel, der Arbeitslast und anderen Erkennungsschichten ab.
Benötige ich einen Browser, um eine von DataDome geschützte Website zu scrapen?
Nicht jede geschützte Seite erfordert einen Browser. Websites, die auf clientseitiges Rendering oder Device Check setzen, benötigen jedoch möglicherweise die Ausführung von echtem JavaScript und einen Browserstatus, den ein einfacher HTTP-Client nicht bereitstellen kann.
Warum erhalte ich 403-Fehler von DataDome?
Ein 403-Fehler kann darauf hindeuten, dass die Anfrage als verdächtig oder automatisiert eingestuft wurde. Vergewissern Sie sich, dass die Antwort tatsächlich von DataDome stammt, bevor Sie davon ausgehen, dass das Anti-Bot-System dafür verantwortlich ist.
Warum funktioniert die Seite manuell, aber nicht in Python?
Ihr normaler Browser und die Python-HTTP-Bibliothek erzeugen sehr unterschiedliche Netzwerk-, TLS-, HTTP-, JavaScript- und Browserumgebungen. Ein Anti-Bot-System kann einige dieser Unterschiede erkennen.
Warum funktioniert mein Scraper für einige Anfragen und bricht dann ab?
Mögliche Ursachen sind Verhaltenserkennung, Ratenmuster, Änderungen der IP-Reputation oder inkonsistente Sitzungen. Anti-Bot-Systeme können Aktivitäten über mehrere Anfragen hinweg auswerten, anstatt jede Anfrage isoliert zu beurteilen.
Löst die Proxy-Rotation das Problem mit DataDome?
Nicht von allein.
Die Rotation ändert die Netzwerkidentität. Sie ändert jedoch nicht automatisch den Browser-Fingerabdruck, den TLS-Client, die JavaScript-Umgebung oder das Anfrageverhalten.
Ist eine Scraping-API besser als Proxys?
Sie lösen unterschiedliche Probleme.
Verwenden Sie Proxys, wenn Sie die Kontrolle über Ihren Scraper behalten möchten und in erster Linie eine Netzwerkinfrastruktur benötigen.
Verwenden Sie eine Scraping-API, wenn Sie möchten, dass ein größerer Teil der Infrastruktur für Browser, Proxy, Rendering und Extraktion für Sie verwaltet wird.
Fazit
Das Wichtigste, was man über DataDome wissen muss, ist, dass es kein einheitliches „Bot-Signal“ gibt.
Moderne Anti-Bot-Erkennung betrachtet mehrere Ebenen gleichzeitig.
Eine Anfrage ist nicht nur eine IP-Adresse.
Sie ist:
eine IP-Adresse,
die eine TLS-Verbindung herstellt,
HTTP-Header sendet,
von einem Browser oder einer Anwendung aus,
innerhalb einer Sitzung,
mit einem Verlauf
und einem Verhaltensmuster.
Je besser diese Elemente miteinander übereinstimmen, desto glaubwürdiger wirkt der Client.
Deshalb kann das Wechseln der IP-Adresse zwar ein Problem beheben, fünf andere jedoch unberührt lassen.
Deshalb löst Playwright zwar die Ausführung von JavaScript, ohne jedoch jedes Erkennungsproblem zu lösen.
Und deshalb gibt es überhaupt erst verwaltete Scraping-APIs.
Wenn Sie vollständige Kontrolle benötigen, bauen Sie den Stack selbst auf und nutzen Sie Proxys als Netzwerkinfrastruktur.
Wenn Sie in erster Linie zuverlässige Webinhalte benötigen, ohne sich um die Verwaltung von Browsern und die Proxy-Koordination kümmern zu müssen, nutzen Sie eine Scraping-API.
Wichtig ist, zu wissen, welche Ebene Sie tatsächlich beheben möchten.
