Eine IP – Tausende von Menschen: Wie CGNAT IP-Sperren umgeht

Eineinhalb Jahrzehnte lang basierte der Schutz von Websites auf der Annahme: Eine IP-Adresse ist eine Entität, die bestraft werden kann. Ingenieure von Cloudflare haben gemessen, wie stark diese Annahme gebrochen ist, und die Zahlen veröffentlicht. Die wichtigste davon ist überraschend: Adressen, hinter denen Hunderte von echten Menschen sitzen, erhalten dreimal häufiger eine Geschwindigkeitsbegrenzung als gewöhnliche. Wir analysieren, was CGNAT ist, warum mobile Proxys widerstandsfähiger sind als andere – und warum der „Crowd-Effekt“ keine Entschuldigung mehr ist.

Warum „einfach IP sperren“ keine kostengünstige Lösung mehr ist

Jeder Schutz vor Automatisierung – Blockliste, Rate-Limit, Anomalie-Detektor – geht davon aus, dass hinter der Adresse ein klar identifizierbarer Nutzer steht. Adresse gesperrt – Täter bestraft. Die Kosten eines Fehlers werden dabei als null betrachtet: Nun, man hat einen Bot nicht durchgelassen.

Diese Arithmetik ist genau solange gültig, wie tatsächlich ein Nutzer hinter der Adresse steht. Bei einer IP-Adresse aus einem Rechenzentrum ist das der Fall: Eine Adresse – eine gemietete Entität, eine Sperre kostet die Website nichts. Bei einem Heimprovider ist es ein Haushalt, auch fast null. Bei einem Mobilfunkanbieter kann sich hinter einer öffentlichen Adresse jedoch ein ganzes Stadtviertel verbergen. Und dort wird die Sperre plötzlich zu einer kostenpflichtigen Maßnahme: Zusammen mit dem Scraper schaltet die Website Hunderte von echten Kunden ab, die nichts falsch gemacht haben.

Genau diese Asymmetrie der Kosten – und nicht die „Magie der mobilen IPs“ – bestimmt, wer hart bestraft wird und wer verschont bleibt. Und sie hat einen konkreten technischen Namen.

Was ist CGNAT und warum ist es bei Anbietern allgegenwärtig?

CGNAT (Carrier-Grade NAT, auch LSN – Large Scale NAT) ist die Adressübersetzung auf Anbieterebene und nicht auf der Ebene eines Heimrouters. Formal ist die Grundlage in RFC 6598 (April 2012) dokumentiert: Für die Bedürfnisse der Anbieter-Translater wurde der Bereich 100.64.0.0/10 reserviert – 4.194.304 Adressen, die nicht im globalen Netzwerk geroutet werden und die Grenze des Anbieters nicht überschreiten sollten.

Die Motivation im Text der RFC wird direkt formuliert: Der Adressraum IPv4 ist fast erschöpft, aber Anbieter sind verpflichtet, das Wachstum der IPv4-Kunden zu unterstützen, bis IPv6 vollständig ausgerollt ist. Der Block /10 wurde als minimale Größe gewählt, die es ermöglicht, CGN regional auszurollen, ohne verschachtelte Übersetzer zu bauen.

Bei Mobilfunkanbietern ist der Adressmangel am ausgeprägtesten: Es gibt Millionen von Abonnenten, aber nur Zehntausende von öffentlichen IPv4-Adressen. Daher ist CGNAT für sie keine Option, sondern die Norm. Eine öffentliche Adresse bedient Hunderte und in Spitzenzeiten sogar Tausende von Sitzungen, und die Abonnentenadresse wechselt ständig – beim Umschalten zwischen Türmen, beim Wiederverbinden von Sitzungen, beim Bandbreitenmanagement.

Hieraus ergibt sich der gesamte praktische Wert von mobilen Proxys: Sie erhalten nicht eine „saubere“ IP, sondern eine Adresse, die die Website nicht ohne begleitenden Schaden abschalten kann.

Was genau hat Cloudflare gemessen?

In der Studie „One IP address, many users: detecting CGNAT to reduce collateral effects“ (Vasilis Giotas und Marwan Fayad, veröffentlicht am 29. Oktober 2025, aktualisiert am 15. Juli 2026) löst Cloudflare die umgekehrte Aufgabe: zu lernen, Adressen hinter der Anbieter-Translierung zu unterscheiden, um mildere Maßnahmen anzuwenden.

Die Methodik besteht aus mehreren unabhängigen Quellen:

• Verteilte Traceroute von über 9000 Knoten von RIPE Atlas – um Adressen aus 100.64.0.0/10 auf dem Weg zu erfassen;
• WHOIS- und PTR-Einträge – Suche nach Markern cgnat, cgn, lsn in Namen und Beschreibungen;
• Öffentliche Kataloge von Anonymisierern – zur Sammlung von Adressen von VPN und Proxys;
• XGBoost-Modell auf Basis von Client-Signalen, Verhalten auf Transportebene, Verkehrsvolumen und Vielfalt der Richtungen, mit Aggregation sowohl nach einzelner IP als auch nach Subnetz /24.

Die Größe der Trainingsdaten: 200.000 CGNAT-Adressen, 180.000 VPN- und Proxy-Adressen, 900.000 gewöhnliche Adressen, Aufteilung 70/30, zehnfache Kreuzvalidierung. Die angegebene Qualität – Genauigkeit 0,98, gewichteter F1 0,97, log loss 0,04, macro-AUC 0,9946.

Ein separates Detail, über das in der Branche wenig gesprochen wird: Das Verhältnis von User-Agents zu Adressen ist in Afrika deutlich höher als in anderen Regionen. Die historische Verteilung großer IPv4-Blöcke fiel vor Jahrzehnten Nordamerika und Europa zu – und heute führt das dazu, dass Nutzer aus sich entwickelnden Regionen häufiger unter kollektiver Bestrafung leiden. Cloudflare bezeichnet dies als sozioökonomische Verzerrung.

Die Hauptzahl: Rate-Limit dreimal häufiger

Das zentrale Ergebnis der Studie klingt kontraintuitiv für alle, die daran gewöhnt sind, mobile IPs als „unantastbar“ zu betrachten: Nutzer hinter CGNAT stoßen dreimal häufiger auf Geschwindigkeitsbegrenzungen als Nutzer außerhalb von CGNAT.

Hier gibt es keinen Widerspruch – es gibt eine Trennung der Maßnahmen nach Kosten. Eine harte Sperre der Adresse ist teuer, weil sie lebende Abonnenten trifft. Ein Rate-Limit, ein Challenge und ein Captcha sind hingegen günstig und umkehrbar. Daher schaltet der Schutz eine solche Adresse nicht aus, sondern drosselt sie. Zudem wird der Mechanismus aus mathematischen Gründen häufiger aktiviert: Der Verkehr auf einer gemeinsamen Adresse summiert sich aus dem Datenverkehr vieler unabhängiger Personen, und die Schwellenwerte werden schneller erreicht.

Ein zweites Zahlenpaar erklärt, warum Websites überhaupt bereit sind, solche Adressen zu tolerieren. Der Anteil von Bots auf CGNAT-Adressen: Median 4,8% gegenüber 4,7% bei anderen – das heißt, im Median gibt es praktisch keinen Unterschied. Bei den Durchschnittswerten jedoch kehrt sich das Bild um: 7% bei CGNAT gegenüber 13,1% bei nicht-CGNAT. Dies liest sich so: Unter den gewöhnlichen Adressen gibt es einen langen Schwanz nahezu vollständig automatisierter – ein typischer Rechenzentrumsbereich, in dem es keine lebenden Menschen gibt, und dieser zieht den Durchschnitt nach oben. Hinter der Anbieter-Translierung kann es einen solchen Schwanz nicht geben: Dort gibt es immer lebende Abonnenten, die jede Automatisierung verdünnen.

Für Praktiker lautet die direkte Schlussfolgerung: Mobile Proxys werden nicht wegen der Geschwindigkeit gekauft, sondern wegen der Widerstandsfähigkeit. Die Bandbreite pro Adresse wird dort wahrscheinlich schlechter sein als bei einem Rechenzentrum – aber die Adresse verbrennt nicht für immer nach dem ersten Fehler.

Schlechte Nachrichten: CGNAT und Proxys haben gelernt zu unterscheiden

Die verführerische Schlussfolgerung „Da hinter der gemeinsamen Adresse viele Menschen stehen, gebe ich mich als gemeinsame Adresse aus“ scheitert an der Aufgabenstellung in der Studie selbst. Beachten Sie die Zusammensetzung der Stichprobe: CGNAT-Adressen und VPN/Proxy-Adressen sind zwei verschiedene Klassen, und das Modell wurde trainiert, sie zu unterscheiden, und nicht sie in einen Topf zu werfen mit „vielen Nutzern hinter einer IP“.

Sie unterscheiden sich durch Merkmale, die der Mieter der Adresse nicht kontrolliert:

• Topologie. Die Anbieter-Translierung ist auf dem Weg und in den Protokolldateien sichtbar – durch den Bereich 100.64.0.0/10, durch PTR und WHOIS.
• Vielfalt der Richtungen. Ein echtes Stadtviertel geht zu Tausenden von verschiedenen Diensten; ein Knoten für Scraping zu Dutzenden, oft zu einem einzigen.
• Profil nach Subnetz. Die Aggregation nach /24 zeigt, ob sich der benachbarte Adressblock wie ein Abonnent oder wie ein gemieteter Pool verhält.
• Client-Signale. Die Geräte hinter der gemeinsamen Adresse sollten wie eine echte Population aussehen und nicht wie derselbe Stack, der hundertmal vervielfältigt wurde.

Und das ist nicht exklusiv für Cloudflare: Anbieter von IP-Intelligenz geben schon lange nicht mehr nur ein binäres Flag „Proxy oder nicht“ aus, sondern eine numerische Bewertung – und die Trennung zwischen „gemeiner Abonnentenadresse“ und „gemietetem Pool“ ist bereits darin enthalten.

Drei praktische Schlussfolgerungen

1. Reduzieren Sie die Belastung der Adresse, anstatt die Parallelität zu erhöhen. Da eine gemeinsame Adresse per Definition näher an der Schwelle des Rate-Limits ist, verliert die Strategie „maximale RPS von einer IP herauszuholen“ am schnellsten. Verteilen Sie die Aufgabe über die Zeit und auf Adressen, nicht auf Streams innerhalb einer einzigen.
2. Schützen Sie die Sitzung. Die Widerstandsfähigkeit der Adresse ist eine Ressource, die Sie bei aggressivem IP-Wechsel verlieren: Jede neue Adresse muss erneut das Vertrauen durchlaufen. Für Aufgaben mit Autorisierung und Warenkorb ist eine sticky Sitzung fast immer vorteilhafter als Rotation – wo die Grenze verläuft, wurde im Leitfaden zu sticky-Sitzungen behandelt.
3. Zählen Sie nicht die Adressen, sondern die erfolgreichen Antworten. Der Pool von Rechenzentren ist günstiger pro Adresse und fast immer teurer pro erfolgreicher Anfrage, wo ernsthafter Schutz vorhanden ist. Es macht Sinn, die Typen nur nach dem Preis des Ergebnisses zu vergleichen: residential und mobile Adressen amortisieren sich genau dort, wo Rechenzentrumsadressen nicht bis zur Antwort gelangen.

Wo der „Crowd-Effekt“ überhaupt nicht hilft

Es ist wichtig, die Logik nicht weiter zu übertragen, als sie funktioniert. Der Schutz vor kollektiver Bestrafung wirkt nur auf der Ebene der Netzwerkadresse. Sobald die Plattform zu anderen Identifikatoren übergeht, verschwindet der Vorteil:

• Account-Sperre. Wenn die Aktion an ein Konto gebunden ist, hat die Qualität der IP keinen Einfluss auf die Entscheidung.
• Fingerprint des Geräts und Browsers. Die Konsistenz des Stacks wird unabhängig von der Adresse überprüft – und zerfällt normalerweise früher, als der IP-Filter aktiviert wird.
• Verknüpfung von Konten. Plattformen suchen nach Überschneidungen in Subnetzen und nach Verhaltensübereinstimmungen, nicht nur nach der genauen Adresse.

Ein separater Faktor im Jahr 2026 – das Angebot. Im Laufe eines Monats erlebte der Markt zwei Schläge gegen die Quellen von residential Adressen: Im Juli kündigte LG ein Verbot von Proxy-SDK an, nachdem festgestellt wurde, dass etwa 42% der Anwendungen in ihrem Store den Fernseher in ein Proxy-Netzwerk zogen, und am 3. August 2026 führte Samsung ein plattformweites Verbot von residential Proxy-SDK ein und schränkte bereits die Registrierung neuer Anwendungen mit dieser Funktionalität ein. Der Fund wurde von Harrison Sand aus dem norwegischen Unternehmen Mnemonic beschrieben; einzelne Anwendungen berichteten von Installationen auf Hunderten Millionen Fernsehern. Eine detaillierte Analyse der ersten Welle finden Sie im Artikel über das Verbot von Proxy-SDK auf LG-Fernsehern. Weniger Quellen für residential IPs – höhere Preise, und desto deutlicher wird die Kluft zwischen einer günstigen Adresse und einer Adresse, die tatsächlich bis zur Antwort gelangt.

Fazit

CGNAT hat die grundlegendste Annahme des Webschutzes gebrochen – „eine Adresse entspricht einem Antwortgeber“ – und der Schutz hat dies anerkannt und digitalisiert. Aber die Anerkennung führte nicht zu einer Amnestie, sondern zu einer Umstrukturierung der Maßnahmen: Adressen hinter der Anbieter-Translierung werden seltener dauerhaft abgeschaltet und dreimal häufiger durch Limits gedrosselt, und ihr Unterschied zu Proxy-Pools wurde in eine separate Klassifizierungsaufgabe überführt.

Der praktische Sinn für diejenigen, die über Proxys arbeiten, ist einfach: Der Typ der Adresse bestimmt nicht „werden Sie durchkommen oder nicht“, sondern zu welchem Preis die Website Sie stoppen kann. Gestalten Sie die Arbeit unter milden Maßnahmen – moderates Tempo, lange Sitzungen, ehrliche Berechnung der Kosten erfolgreicher Anfragen – und wählen Sie den Typ der IP nach dem Preis des Fehlers, nicht nach dem Preis des Gigabytes.