Im Januar bewiesen 16 Millionen Requests: IP-Blocking ist tot
Eine Scalping-Attacke traf im Januar 2026 eine große E-Commerce-Plattform. 16 Millionen Requests verteilten sich auf 3,9 Millionen eindeutige IP-Adressen. Ein IP-basiertes Rate Limit konnte dem nichts anhaben. Der Angriff war nicht wegen cleveren Codes erfolgreich. Er war erfolgreich, weil die schiere Menge an IPs die traditionelle Erkennung nutzlos machte (SecurityBoulevard, März 2026).
Dieser Vorfall bewies, was die Anti-Bot-Branche schon länger sagt: Die IP-Reputation allein kann Menschen nicht von Bots unterscheiden. Und wenn die Verteidiger weitergezogen sind, müssen Scraper ebenfalls nachziehen.
Die drei Schichten, die das IP-Blocking ersetzt haben
Moderne Bot-Erkennung arbeitet auf drei Ebenen. Nur die erste betrifft deine IP.
Netzwerk-Fingerprinting. Bevor dein Request den Server erreicht, erstellt dein TLS-"Client Hello"-Paket eine Signatur (bekannt als JA3 oder JA4), die die HTTP-Bibliothek identifiziert, die den Request sendet. Pythons requests-Bibliothek, der Standard-Client von Go, Node.js fetch, jeder erzeugt einen eindeutigen Fingerprint. Anti-Bot-Systeme prüfen dies, bevor sie auch nur einen einzigen Header lesen. Wenn deine TLS-Signatur nicht zu einem echten Browser passt, wirst du auf Verbindungsebene blockiert (Reddit r/programming).
Browser-Fingerprinting. Websites prüfen heute mehr als 300 Signale aus der Browser-Umgebung. Canvas-Rendering, WebGL-Ausgabe, Audio-Kontext, installierte Schriftarten, Bildschirmauflösung, Zeitzone, GPU-Infos. Dein User-Agent-String ist das am wenigsten interessante Signal im Stack. Cloudflare, Akamai und DataDome erfassen diese passiv durch JavaScript-Challenges, die vor dem Laden der Seite ausgeführt werden (ScrapingBee, 2026).
Verhaltensanalyse. Dies ist die neueste und am schwersten zu fälschende Ebene. Anti-Bot-Systeme verfolgen heute Mausbewegungen, Scrollgeschwindigkeit, Klickmuster, Tipprhythmus und das Timing zwischen Interaktionen. Echte Menschen bewegen eine Maus nicht in perfekt geraden Linien. Sie machen Pausen, schießen über Buttons hinaus, scrollen unregelmäßig. Bots tun nichts davon oder machen alles viel zu perfekt (r/webdev, 2026).
Die meisten Scraping-Teams kämpfen an der falschen Front
Hier ist die unbequeme Wahrheit: Die meisten Scraping-Teams investieren immer noch hauptsächlich in IP-Infrastruktur. Größere Proxy-Pools, Residential-IPs, rotierende Gateways. Das hat durchaus seine Berechtigung. Die IP-Reputation ist nach wie vor ein wichtiges Signal unter vielen.
Aber der Kauf von 10.000 Residential-IPs hilft nicht, wenn dein TLS-Fingerprint "Python-Skript" schreit oder dein headless Browser Automatisierungs-Flags über navigator.webdriver verrät. Du gibst dein Geld an der falschen Stelle aus.
Ein Entwickler, der 34 Production-Scraper gebaut hat, schrieb über dieses Problem (Dev|Journal, März 2026): Die Lücke zwischen Scraping auf Tutorial-Niveau und dem, was in der Production funktioniert, wird durch Anti-Bot-Systeme definiert, die TLS-Fingerprints und Mausbewegungen analysieren, nicht durch DOM-Selektoren. Die Tutorials bringen dir bei, HTML zu parsen. Die Production lehrt dich, die Erkennung zu überleben.
Und es wird noch schwieriger. Der Report State of Web Scraping 2026 von Browserless stellte fest, dass standardmäßige headless Browser häufiger blockiert werden als echte Browser, weil Anti-Bot-Systeme die spezifischen Fingerprint-Unterschiede zwischen headless und normalem Chrome katalogisiert haben. Die Lücke wird nicht kleiner.
Wenn dein Scraper ständig ausfällt und du dich nur auf Proxy-Rotation konzentrierst, reparierst du vielleicht an der völlig falschen Stelle.
Der Cloudflare-Faktor
Ihr Bot-Management-Produkt führt bei jedem Request eine Verhaltensanalyse durch und bewertet Besucher auf einer Skala von 1 bis 99 basierend auf Dutzenden von Signalen. Turnstile (ihr unsichtbarer CAPTCHA-Ersatz) passt die Schwierigkeit der Challenge dynamisch an, je nachdem, wie menschlich der Besucher wirkt (Cloudflare-Dokumentation).
Gleichzeitig hat Cloudflare eine eigene AI-Crawling-Infrastruktur gestartet. Die Community bemerkte die Ironie (Reddit r/cybersecurity).
Was das praktisch bedeutet: Durch Cloudflare geschützte Websites sind im Jahr 2026 am schwersten zu scrapen, und rund 20 % aller Websites befinden sich hinter ihrem Netzwerk. Wenn deine Scraping-Strategie die Verhaltenserkennung nicht berücksichtigt, hast du ein Fünftel des erreichbaren Webs verloren.
Was im Jahr 2026 wirklich funktioniert
Die Scraper, die Erfolg haben, teilen drei Merkmale.
Erstens passen sie sich an die TLS-Fingerprints echter Browser an. Tools wie curl-impersonate replizieren die exakte TLS-Signatur von Chrome oder Firefox und verhindern so die Erkennung, bevor sie überhaupt beginnt. Kein Header-Spoofing der Welt kann einen unpassenden JA3-Hash retten.
Zweitens nutzen sie echte (oder überzeugend echte) Browser-Umgebungen. Kein headless Chrome mit Standardeinstellungen. Tatsächliche Browser-Instanzen mit konsistenten Fingerprints, die zum vorgegebenen User-Agent passen.
Drittens fügen sie bei geschützten Websites menschenähnliches Verhaltensrauschen hinzu. Zufällige Verzögerungen reichen nicht aus. Das Timing zwischen den Aktionen muss realistischen Verteilungen folgen, und die Pfade der Mausbewegungen benötigen Kurven und Zögern, die organisch wirken.
Die Architektur hat sich also verschoben. Es geht nicht darum, mehr IPs zu haben. Es geht darum, jeden Request so zu gestalten, dass er von einer echten Person, die mit Chrome surft, nicht zu unterscheiden ist.
Das Wettrüsten bei der Erkennung beschleunigt sich
Anti-Bot-Anbieter haben damit begonnen, Bedrohungsdaten in Echtzeit mit ihrer gesamten Kundenbasis zu teilen. Wenn eine Website ein neues Bot-Muster blockiert, lernt jede andere Website im Netzwerk innerhalb von Minuten dazu (SecurityBoulevard, März 2026). Das ist eine grundlegende Änderung gegenüber dem alten Modell, bei dem die Verteidigung jeder Website unabhängig voneinander funktionierte.
Wir glauben, dass dies bedeutet, dass die Kosten für selbstgebaute Scraping-Infrastrukturen weiter steigen werden. Jedes neue Erkennungssignal erfordert Entwicklungszeit, um ihm entgegenzuwirken, und der Zyklus beschleunigt sich. Teams, die die Erkennung auf Infrastrukturebene lösen (smartes Proxy-Routing, Browser-Fingerprinting, TLS-Matching), werden diejenigen abhängen, die weiterhin nur IPs auf das Problem werfen.
Die Frage ist nicht, ob du mehr Proxies brauchst. Es ist die Frage, ob deine Requests menschlich aussehen, noch bevor sie überhaupt den Zielserver erreichen.