Bot-Erkennung 2026Scraper-Fehler bei Cloudflare, DataDome und Akamai diagnostizieren

Ein Scraper, der vor einem Monat noch funktionierte, liefert plötzlich 403-Fehler, Challenge-Seiten oder HTTP-200-Antworten ohne die erwarteten Daten. Der erste Verdacht fällt meist auf ein neues Anti-Bot-Release von Cloudflare, DataDome oder Akamai, und manchmal stimmt das auch. Genauso oft liegt die Ursache aber in einem geänderten Seitentemplate, einem abgelaufenen Session-Cookie, einer neuen Weiterleitung oder einem Worker-Pool, der unbemerkt seine Parallelität verdoppelt hat.

Bevor Sie Proxys rotieren oder Browser-Fingerprints neu aufbauen, sollten Sie herausfinden, wo der Fehler tatsächlich entsteht. Das ist 2026 wichtiger als früher, denn die Erkennung blickt zunehmend über die einzelne Anfrage hinaus: Session-Verhalten, Browser-Integrität und die Art, wie sich ein Client über die Zeit durch eine Website bewegt, können darüber entscheiden, ob die nächste Anfrage durchgelassen oder mit einer Challenge beantwortet wird.

Dieser Beitrag zeigt, was die drei Anbieter 2026 tatsächlich dokumentiert haben, was jede Änderung für eine Scraping-Pipeline bedeutet und wie Sie Fehler praxisnah diagnostizieren, gezielt eskalieren und die Wiederherstellung messen. Der Code liegt in ScraperHub/what-changed-in-cloudflare-datadome-and-akamai-bot-detection-in-2026, einem Diagnose-Framework in Python, das Antworten klassifiziert und verwertbare Ergebnisse ausweist. Es löst keine Challenges und verändert nicht die Identität von Anfragen, und auch sonst tut nichts in diesem Beitrag das.

Was sich 2026 bei der Bot-Erkennung geändert hat

Keine der relevanten Entwicklungen ist ein einzelner neuer Fingerprint oder eine einzelne verpflichtende Challenge. Sie verändern, wann eine Entscheidung fällt, welche Belege in sie einfließen und wie Website-Betreiber verschiedene Arten automatisierten Traffics behandeln können.

Es handelt sich um dokumentierte Ankündigungen und Releases, nicht um Belege dafür, dass jede geschützte Website sie einsetzt. Mehrere Funktionen wurden ohne öffentliches Datum für die allgemeine Verfügbarkeit angekündigt.

Cloudflare: Die Erkennung endet nicht mit der ersten Anfrage

Precursor, im Juli eingeführt, bewertet Browser- und Verhaltenssignale über eine ganze Session. Cloudflares Dokumentation erklärt, dass die fortlaufende Bewertung den Session-Zustand aktualisiert, den das Cookie cf_clearance speichert. Dieser Zustand kann herabgestuft oder ungültig gemacht werden. Für einen Scraper ist das Bestehen der ersten Challenge damit kein stabiles Ergebnis mehr: Auf Zonen mit aktiviertem Precursor können spätere Anfragen das Urteil ändern.

Die Verfügbarkeit muss pro Zone geprüft werden. Das Launch-Changelog spricht von einem Rollout für alle Kunden, während die Ankündigung Precursor als Teil von Enterprise Bot Management einordnet, kostenlos bis zur allgemeinen Verfügbarkeit später im Jahr.

Adaptive Intelligence folgte am 31. August. Das Modell wird laufend mit Live-Traffic neu trainiert und für Kunden von Enterprise Bot Management über Auto Update Machine Learning aktiviert, wodurch periodische, nummerierte Modell-Releases als Meilensteine an Bedeutung verlieren. Die Ankündigung beschrieb kurzlebige Wegwerf-Regeln als noch kommende Komponente; behandeln Sie diese also als geplant, nicht als ausgeliefert.

Parallel dazu trennt Cloudflare die Richtlinien für KI-Crawler inzwischen in separate Search-, Agent- und Training-Controls. Seit dem 15. September erhalten neue Zonen empfohlene Presets, für werbefinanzierte Websites strenger, die Betreiber jederzeit ändern können. Es handelt sich um Entscheidungen der Betreiber, nicht um ein Verbot aller automatisierten Anfragen, und Bot Preference Sync überträgt die gewählten Präferenzen auf Wunsch in robots.txt.

DataDome: Challenge-Integrität und Belege aus dem Browser

DataDomes VM-basierte Verschleierung kompiliert die Logik von Device Check und Slider in Bytecode, den ein eigener Interpreter im Browser ausführt. Der Haupteffekt: Die Challenge lässt sich schwerer per Reverse Engineering analysieren und günstig nachspielen. Eine neue Kategorie von Netzwerk-Fingerprints kommt dadurch nicht hinzu.

Der Bericht zu Proof of Browser beschreibt Prüfungen, die Rendering, WebGL, DOM-Mutationen und Timing kombinieren. Es handelt sich um vom Anbieter beschriebene Mechanismen; weder dieser Beitrag noch das begleitende Repository misst, wie gut sie tatsächlich etwas erkennen. Die Dokumentation zu Device Check erklärt, wie Erkennungsergebnisse die Challenge auslösen.

DataDome hat außerdem Agent Trust am 5. Mai als Paket gebündelt, nachdem im Januar bereits die Unterstützung für Web Bot Auth hinzugekommen war. Identitätsbelege können aus signierter Authentifizierung oder anderen vertrauenswürdigen Mechanismen stammen. Wer den User-Agent eines bekannten Crawlers kopiert, belegt damit weder Identität noch Berechtigung.

Schließlich haben die 3.0-Releases der DataDome-Module für Apache, Nginx, Cloudflare Worker und Fastly die Pfadbehandlung und den Ausschluss statischer Assets geändert. Es sind Integrationsänderungen, die davon abhängen, dass der jeweilige Betreiber aktualisiert, und kein neu eingeführter TLS- oder HTTP/2-Detektor.

Akamai: adaptive Validierung und feinere Bot-Richtlinien

Im März hat Akamai Erweiterungen für Content Protector angekündigt, darunter Schutz für native Apps und das Advanced Validation Framework. AVF kann zusätzliche Geräte- oder Verhaltensdaten anfordern, wenn die passive Analyse kein eindeutiges Ergebnis liefert, optional ergänzt durch eine interaktive Challenge. Die Ankündigung nennt kein öffentliches Datum für die allgemeine Verfügbarkeit.

Außerdem unterteilt Akamai seinen KI-Bot-Traffic inzwischen in feinere Kategorien: Training Crawlers, Search Crawlers sowie Fetchers and Agents, mit passenden Filtern in Web Security Analytics. Sie geben Betreibern feinere Kontrolle und schreiben keine Standardaktion vor.

Die hier ausgewerteten Quellen liefern keine öffentliche Grundlage für die Behauptung, Akamai habe ein neues Kernmodell für Bot Manager, ein neues Format für _abck oder einen neuen Residential-Proxy-Detektor 2026 ausgeliefert. Dieselbe Zurückhaltung gilt für bekannte Techniken anderswo: TLS-Fingerprinting, Browser-Fingerprints und IP-Reputation sind weiterhin wichtig, aber dass es sie gibt, ist keine Ankündigung von 2026.

Den Fehler diagnostizieren, bevor Sie den Scraper ändern

Beginnen Sie mit einer einzigen gesicherten fehlerhaften Antwort. Halten Sie Zeitstempel, angefragte und finale URL, Response-Header und Body, Scraper-Version, Exit-Standort, gegebenenfalls die Session-ID sowie die Parallelität fest, und vergleichen Sie alles mit einer bekannt guten Aufzeichnung. Ohne diese Dimensionen ist es meist Rätselraten, einen Vorfall mit dem Release eines Anbieters in Verbindung zu bringen.

Schließen Sie zuerst die üblichen Anwendungsfehler aus:

1. Markup- oder Parser-Drift: Existiert das erwartete Element noch im rohen HTML?
2. JavaScript-Rendering: Erscheinen die Daten erst nach clientseitiger Ausführung oder in einer späteren Netzwerkantwort?
3. Authentifizierung: Wurde die Anfrage auf ein Login umgeleitet, ging ein Cookie verloren, oder ist ein CSRF-Token abgelaufen?
4. Traffic-Muster: Haben sich Worker-Anzahl, Anfragerate oder Exit-Standort geändert?
5. Weiterleitungen und Varianten: Haben sich kanonische URL, Locale, Geräteversion oder Content-Type geändert?

Klassifizieren Sie dann die Antwort selbst, nicht die Exception, die Ihr Parser geworfen hat.

Anbieter-Marker grenzen die Suche ein, sind für sich genommen aber keine verlässliche Zuordnung. Cloudflare dokumentiert cf-mitigated: challenge; ein cf-ray Header allein ist kein Sperrurteil, denn jede über den Proxy laufende Antwort trägt einen. DataDome-Cookies oder Challenge-Endpunkte liefern zusätzlichen Kontext, und Akamai zugeordnete Cookie-Namen wie _abck und bm_sz beweisen nichts über eine konkrete Durchsetzungsentscheidung.

Das Fetch-Urteil vom inhaltlichen Erfolg trennen

Die Crawling API macht diese Unterscheidung sichtbar. cb_status ist das Urteil von Crawlbase über die Antwort, einschließlich eigener Sperr- und Inhaltsprüfungen. original_status ist normalerweise der Status, den das Ziel gesendet hat. Die finale url macht Weiterleitungen sichtbar, und mit format=json kommen diese Felder zusammen mit dem Body und der Preisstufe domain_complexity an. Eine Anfrage an https://example.com/ lieferte am 7. Oktober 2026:

{
  "original_status": 200,
  "pc_status": 200,
  "cb_status": 200,
  "url": "https://example.com/",
  "domain_complexity": "standard"
}

Keiner dieser Status sagt aus, dass ein Produkttitel, ein Preis oder ein anderes Geschäftsfeld gültig ist. Eine robuste Pipeline validiert diese Felder explizit, als dritte Ebene.

Der Klassifikator des begleitenden Repositorys, zu finden in final/bot_diag/classify.py, macht die Unterscheidung konkret:

# final/bot_diag/classify.py
def classify_response(
    status: int | None,
    body: str,
    headers: Mapping[str, str] | None = None,
    expected_fields: Sequence[str] | None = None,
) -> str:
    header_map = _header_map(headers)
    text = body or ""
    lowered = text.lower()
    if _is_cloudflare_challenge(lowered, header_map) or _is_datadome_challenge(lowered, header_map):
        return LABEL_CHALLENGED
    is_blocked = (
        _is_akamai_block(text, lowered)
        or _is_cloudflare_block(lowered, header_map)
        or _is_datadome_block(status, lowered, header_map)
        or (status in {401, 403, 429} and bool(text.strip()))
    )
    if is_blocked:
        return LABEL_BLOCKED
    return _content_label(status, text, expected_fields)

Das ist ein Auszug, kein eigenständiges Snippet: Imports, Labels und Hilfsfunktionen liegen an anderer Stelle im Paket. Die Funktion gibt eines von vier Labels zurück: blocked, challenged, invalid_content und ok. Der Feld-Validator ist bewusst klein gehalten und unterstützt einfache JSON- und HTML-Muster statt Produktionsschemata. Lesen Sie daher Schritt 3 und seine Fixtures, bevor Sie ihn an Ihre Daten anpassen.

Eine sinnvolle Erweiterung besteht darin, nicht nur das Vorhandensein zu prüfen, sondern auch Feldtypen, plausible Wertebereiche, die Konsistenz zwischen Feldern und die Aktualität. Damit erkennen Sie auch die stille Vergiftung von Antworten, bei der ein technisch erfolgreicher Abruf trotzdem unbrauchbare oder irreführende Werte liefert.

Die Wiederherstellung nach Fehlerklasse wählen

Unterschiedliche Fehler erfordern unterschiedliche Eingriffe. Blinde Rotation und bedingungslose Retries machen die Belege schwerer lesbar und erhöhen Last und Kosten.

Konsistenz von Anfrage und Session. Eine vorgegebene Browser-Identität muss zu Transport, Headern, Cookie-Historie und Navigationsabfolge passen. Nur den User-Agent oder die Exit-IP zu tauschen hilft selten gegen eine Bewertung der Browser-Integrität oder auf Session-Ebene. Halten Sie Exits stabil, wenn ein Workflow von eingeloggter oder zustandsbehafteter Navigation abhängt.

Ausführung im Browser. Rendern Sie, wenn die benötigten Felder von JavaScript abhängen. Das ist teurer und langsamer: Bei der Crawling API wird eine JavaScript-Anfrage zum doppelten Standardtarif abgerechnet. Rendering ist keine Erlaubnis, auf ein Ziel zuzugreifen, und keine universelle Lösung für Challenges. Zur operativen Abwägung siehe Headless-Browser im Vergleich zu Scraping-APIs.

Retry und Eskalation. Setzen Sie bei vorübergehenden Fehlern auf Backoff mit Obergrenze. Korrigieren Sie ungültige URLs und Selektoren, statt sie unverändert zu wiederholen. Untersuchen Sie eine bestätigte Sperre, statt sie mit derselben Anfrage zu bombardieren. Bei der Crawling API sind das die Codes, denen Sie am häufigsten begegnen, und was Sie zuerst tun sollten:

Ein fehlgeschlagener Aufruf liefert außerdem den HTTP-Status 520. Das ist die Statuszeile, kein cb_status, verzweigen Sie also immer anhand des cb_status in der Antwort. Der Eskalationsschritt des Repositorys knüpft seine JavaScript-Eskalation an 520 und 525 und ergänzt page_wait=2000 und ajax_wait. Gleichen Sie das vor der Wiederverwendung mit der Tabelle oben ab: Eskalieren Sie bei 503 und bei einem unerwarteten 207, und werten Sie 705 und 706 als Signal, langsamer zu werden. Die Wartezeiten helfen bei spät gerenderten Inhalten; gegen eine gescheiterte Challenge helfen sie nicht.

Identität und Richtlinie. Für namentlich bekannte, legitime Agenten kann eine signierte Identität mit Registrierung der bessere Weg sein, als beliebigen Browser-Traffic zu imitieren. Cloudflare Web Bot Auth, DataDome Agent Trust und die agentenbezogenen Controls von Akamai gehören zu dieser Ebene. Eine verifizierte Identität garantiert trotzdem keine Autorisierung.

Verwalteter Abruf. Crawlbase bietet die Crawling API für anfrageorientierte Integrationen, Smart AI Proxy für bestehende proxy-kompatible Clients und den Enterprise Crawler für Bulk-Jobs in Warteschlangen samt Zustellung. Verwaltete Infrastruktur erspart den eigenen Betrieb von Browser-Flotten und Proxy-Pools, aber unterstützte Ziele, Latenz, Credits und Fehlerraten müssen Sie trotzdem messen.

Die Wiederherstellung mit dem Begleitprojekt bewerten

Das Repository benötigt Python 3.10+ und enthält sechs aufeinander aufbauende Skripte unter steps/ sowie das Paket bot_diag unter final/. Es ist ein Diagnose-Framework, kein Live-Bypass-Benchmark für irgendeinen Anbieter. Die Pipeline:

1. Beginnen Sie mit einer Anfrage an die Crawling API mit dem Normal token und dem Parameter format=json.
2. Prüfen Sie cb_status, original_status, die finale URL und den Inhalt.
3. Klassifizieren Sie die Antwort und validieren Sie die Pflichtfelder.
4. Wiederholen oder eskalieren Sie nur dort, wo die Fehlerrichtlinie es rechtfertigt.
5. Speichern Sie ein Ergebnis pro URL als CSV und fassen Sie verwertbare Ergebnisse und Retry-Overhead zusammen.
6. Lassen Sie sich pro Domain die Wahl zwischen Smart AI Proxy und der Crawling API anzeigen.

Eine reproduzierbare Baseline ausführen

Klonen Sie das Repository, installieren Sie die Abhängigkeiten und beginnen Sie mit dem synthetischen Pfad, der keinen Token braucht. Aus dem Verzeichnis final heraus:

python -m bot_diag evaluate urls.example.txt --fields price,title --dry-run

Für einen Live-Lauf setzen Sie CRAWLBASE_TOKEN (und CRAWLBASE_JS_TOKEN für die JavaScript-Eskalation), stellen eine URL-Liste bereit, die Sie abrufen dürfen, und führen Folgendes aus:

python -m bot_diag evaluate urls.txt --fields price,title \
  --concurrency 4 --max-retries 2 --out sample_results.csv

Der Evaluator begrenzt die Parallelität auf acht. Er meldet die Quote für ok über alle Eingabe-URLs, die p50- und p95-Latenz pro Anfrageversuch (Nearest-Rank) sowie den Retry-Overhead. Die Latenzangabe enthält keine Backoff-Pausen zwischen Retries, und die CSV enthält eine zusammengefasste Zeile pro URL, nicht eine pro Versuch. Beides ist wichtig, wenn Sie die Zahlen mit der Laufzeit eines Produktionsjobs vergleichen.

Für einen aussagekräftigen Vergleich nehmen Sie eine Stichprobe von etwa 100 bis 200 URLs über repräsentative Seitentypen, wenden auf jede Abrufmethode dieselben Validierungsregeln an und wiederholen den Test an mehr als einem Tag. Segmentieren Sie die Ergebnisse nach Domain, Seitenklasse, Geografie und Rendering-Modus. Synthetische Fixtures testen den Programmablauf; nur echte, autorisierte Stichproben messen die Zuverlässigkeit eines Ziels.

Eine fehlschlagende Domain gezielt umleiten

Das Routing-Beispiel zählt beobachtete Challenges pro normalisiertem Hostnamen. Unterhalb des Standard-Schwellenwerts von drei bleibt es bei Smart AI Proxy; ab diesem Wert verschiebt es die Domain zur Crawling API:

# final/bot_diag/routing.py
def route_domain(
    domain: str,
    challenge_counts: Mapping[str, int],
    *,
    threshold: int = DEFAULT_CHALLENGE_THRESHOLD,
) -> str:
    """Return ``api`` after ``threshold`` challenges, otherwise ``proxy``.

    ``proxy`` means the caller's existing HTTP client should keep using
    ``smartproxy.crawlbase.com:8013``. ``api`` means that domain should move
    to the Crawling API. Counts must already be keyed by ``domain_key``.
    """
    if threshold < 1:
        raise ValueError("threshold must be at least 1")
    key = domain_key(domain)
    if challenge_counts.get(key, 0) >= threshold:
        return API
    return PROXY

Schritt 6 gibt die Entscheidung aus; er baut keine Proxy-Verbindung auf und schaltet auch nicht automatisch um. Der HTTPS-Endpunkt von Smart AI Proxy ist smartproxy.crawlbase.com:8013 mit tokenbasierter Proxy-Authentifizierung, und die Dokumentation zu Smart AI Proxy beschreibt den CrawlbaseAPI-Parameters Header, einschließlich der JavaScript-Optionen. Im Beispiel nutzt die Eskalation zur Crawling API den separaten JavaScript token.

Ein echter Routing-Dienst braucht außerdem ablaufende Zähler, Observability, Circuit-Breaker-Verhalten und einen Weg zurück zur günstigeren Route. Ohne diese verschiebt schon ein kurzer Ausreißer von drei Challenges den Traffic eines Hostnamens dauerhaft.

Kosten pro verwertbarem Ergebnis messen, nicht pro HTTP 200

Sobald dieselbe validierte URL-Stichprobe zwei Ansätze durchlaufen hat, vergleichen Sie Zuverlässigkeit und gesamte Betriebskosten gemeinsam.

url_completion_rate    = urls_with_valid_final_result / input_urls
attempt_success_rate   = successful_attempts / all_fetch_attempts
cost_per_usable_result = total_allocated_cost / validated_results

Die Nenner unterscheiden sich mit Absicht. Die URL-Abschlussquote misst, wie viel vom Job erledigt wurde; die Erfolgsquote der Versuche misst, wie effizient der Abrufpfad ist. Stellen Sie die beiden nicht nebeneinander und nennen Sie beide „Erfolgsquote“.

Rechnen Sie Ausgaben für Proxys und Compute, Credits beim Managed-Anbieter, Retry-Overhead, Browser-Infrastruktur und Wartungsaufwand in der Entwicklung ein, ohne doppelt zu zählen, was ein Managed-Tarif bereits enthält. Bei Crawlbase werden nur erfolgreiche Aufrufe berechnet: 200, 404, 410 und Weiterleitungen des Ziels, leere 200-Bodys (cb_status 207) sowie alle per Opt-in gewählten Status aus custom_success_codes. Sperren und interne Fehler sind kostenlos. domain_complexity ist die Preisstufe, mit der jede berechnete Anfrage multipliziert wird. Lesen Sie den tatsächlichen Verbrauch daher aus der Nutzung in Ihrem Konto und den Preisen von Crawlbase ab, statt ihn aus der Anzahl der Anfragen zu schätzen.

Selbst betriebene Clients können bei berechenbaren Zielen wirtschaftlich sein oder wenn volle Kontrolle über den Browser unverzichtbar ist. Verwalteter Abruf wird attraktiver, sobald die Pflege domainspezifischer Workarounds Entwicklungszeit auffrisst. Keine der beiden Varianten macht es überflüssig, die zurückgelieferten Daten zu validieren.

Fazit

Die wesentlichen Änderungen von 2026 betreffen fortlaufende Belege, Browser-Integrität und feinere Betreiberrichtlinien. Keine davon setzt die alten Fehlerbilder außer Kraft: kaputte Selektoren, abgelaufene Sessions, unkontrollierte Parallelität und unvollständiges Rendering.

Behandeln Sie die Zuverlässigkeit beim Scraping als beobachtbares System: Bewahren Sie Rohantworten auf, trennen Sie das Fetch-Urteil von der Antwort des Ziels, klassifizieren Sie Fehler konservativ, eskalieren Sie gezielt und bewerten Sie das Ergebnis anhand validierter Daten. Das begleitende Repository ist ein Ausgangspunkt für diesen Workflow. Wenn Ihre Abruf-Infrastruktur zum Wartungsengpass wird, schicken Sie dieselben repräsentativen URLs durch Crawlbase und vergleichen Sie die Kosten pro verwertbarem Ergebnis, bevor Sie die Architektur ändern.

Primärquellen

• Cloudflare: Precursor, Precursor-Dokumentation, Adaptive Intelligence, Steuerung von KI-Traffic, Richtlinien für KI-Crawler mit gemischter Nutzung
• DataDome: VM-basierte Verschleierung, Proof of Browser, Agent Trust, Device Check
• Akamai: Erweiterungen für Content Protector, Kategorien für KI-Bot-Traffic, Update zu Web Security Analytics

Häufig gestellte Fragen (FAQs)

Warum besteht ein Scraper eine Challenge und scheitert später?

Auf Websites mit sessionbasierter Bewertung kann spätere Aktivität die Vertrauensentscheidung ändern. Vergleichen Sie Anfragereihenfolge, Cookies, Session-Kontinuität, Rate und Exit-Verhalten, bevor Sie annehmen, dass die erste Challenge der einzige Durchsetzungspunkt war.

Bedeutet ein HTTP 200, dass das Scraping erfolgreich war?

Nein. Er bestätigt nur eine Antwort auf einer Ebene. Eine Challenge-Seite, eine leere Hülle, eine umgeleitete Seite oder plausible, aber falsche Daten können alle mit einem 200 ankommen. Validieren Sie die Felder und ihre Bedeutung, bevor Sie eine URL als abgeschlossen markieren.

Helfen Residential Proxys noch gegen moderne Bot-Erkennung?

Sie helfen bei IP-Reputation und geografischem Zugang, nicht bei fehlender Ausführung im Browser oder inkonsistenten Session-Signalen. Aggressive Rotation pro Anfrage kann zustandsbehaftete Workflows weniger kohärent machen, nicht kohärenter.

Welche Antworten der Crawling API werden berechnet?

Nur erfolgreiche: cb_status 200 (einschließlich 404, 410 und Weiterleitungen des Ziels), leere 200-Bodys, gemeldet als cb_status 207, sowie per Opt-in gewählte Status aus custom_success_codes. Sperren wie 503, 704, 705 und 706 sowie interne Fehler werden nicht berechnet.

Kann Crawlbase den Zugriff auf Websites garantieren, die durch Cloudflare, DataDome oder Akamai geschützt sind?

Kein Anbieter kann jedes Ziel und jede Konfiguration garantieren. Der richtige Test ist eine wiederholbare, autorisierte URL-Stichprobe mit Validierung auf Feldebene und Erfassung von Latenz und Credits, nicht eine einzelne erfolgreiche Anfrage.

NZ

Neil Zamora

Senior Architect · Crawlbase

Senior Architect bei Crawlbase mit Fokus auf den Systemen hinter großflächigem Crawling: Proxy-Rotation, Anti-Bot-Resilienz und den APIs, die diese Komplexität verbergen.

IK

Ian Kalvin

Technical Support Engineer · Crawlbase

Technical Support Engineer bei Crawlbase, der von der Front darüber schreibt, was beim Scraping und bei Proxy-Setups im Produktivbetrieb tatsächlich kaputtgeht.