Als Residential Proxies um 2012 erstmals als kommerzielles Produkt auf den Markt kamen, war das vorherrschende Preismodell ein “Port” oder “Channel”. Man kaufte einen Plan, der einem beispielsweise 100 Ports gab. Jeder Port war eine einzelne gleichzeitige Verbindung. Wer mehr Parallelität benötigte, kaufte einen größeren Plan.
Dieses Modell passte eine Weile zum Markt. Es entsprach der Art und Weise, wie Kunden damals über Skalierung nachdachten. Es machte Rechnungen planbar. Es funktionierte gut genug, dass ein Großteil der Branche es bis Mitte der 2010er Jahre beibehielt.
Und dann verlor es, zunächst allmählich, dann plötzlich, seinen Sinn.
Warum Ports anfangs sinnvoll waren
Die frühen Anwendungsfälle für Residential Proxies waren eng begrenzt. Sneaker-Bots, Ticketing-Bots, Nischen-Scraper. Workloads, bei denen man eine bekannte Anzahl paralleler Sessions betrieb und jede Session eigenständig aussehen musste. Ein Port-basierter Plan war eine direkte Entsprechung dieses mentalen Modells: ein Port, eine Session, vorhersehbares Verhalten.
Die Proxy-Netzwerke selbst waren klein. Pools von einigen hunderttausend IPs, hauptsächlich in einer Handvoll Länder konzentriert. Betreiber konnten unbegrenzte Parallelität realistisch nicht unterstützen, also exponierten sie Parallelität als abrechenbare Größe.
Und Ports waren wirtschaftlich vertretbar. Ein Kunde mit 100 Ports war eine deutlich andere Größenordnung als ein Kunde mit 10. Das Pricing spiegelte die offensichtliche Skalierung des Kunden wider.
Warum Ports scheiterten
Drei Dinge geschahen, ungefähr gleichzeitig, die Port-basierte Pläne zur falschen Grundeinheit machten:
Pools wuchsen um eine Größenordnung. Der Residential-Proxy-Markt konsolidierte und skalierte sich. Die führenden Anbieter wechselten von einigen hunderttausend IPs auf über 100 Millionen. Parallelität hörte auf, eine bedeutungsvolle Einschränkung auf Netzwerkebene zu sein. Ein Kunde, der 1.000 gleichzeitige Verbindungen anforderte, verlangte nichts, was das Netzwerk nicht problemlos liefern konnte.
Workloads wichen vom Port-Modell ab. Moderne Datenerfassung besteht nicht aus 100 parallel laufenden Scrapern, die einen Monat lang gleichmäßig arbeiten. Es ist bursty Fan-out: tausend Anfragen um 9 Uhr morgens am Montag für eine Preisaktualisierung, dann nahezu null Traffic bis zum nächsten Montag. Oder es ist ein ereignisgesteuerter Scrape: ein Webhook feuert, man benötigt 50 gleichzeitige Anfragen für 90 Sekunden, dann zurück auf null. Statische Port-Zuteilungen passten schlecht zu beiden Mustern. Man provisionierte entweder zu viel (zahlte für ungenutzte Kapazität) oder wurde gedrosselt.
Kunden wollten nicht mehr darüber nachdenken. Die eigentliche Frage, die Käufer interessiert, lautet: “Wie viele Daten kann ich darüber bewegen?” Bandbreite ist die natürliche Einheit. Sie skaliert mit dem Workload. Sie entspricht Rechnungen, die wie AWS aussehen: vorhersehbare Kosten pro Einheit, Gesamtkosten bestimmt durch tatsächliche Nutzung.
Der Übergang
Der Wechsel zu Bandbreiten-Pricing dauerte für den größten Teil des Residential-Proxy-Markts etwa fünf Jahre (2019-2024). Nicht weil irgendjemand es verborgen hätte. Reine Trägheit: Großkunden hatten mehrjährige Verträge auf Port-Plänen, Migrationspläne waren aufwendig zu erstellen, und die meisten Anbieter wollten beide Modelle lange genug am Leben erhalten, um Legacy-Käufern einen Ausstieg zu ermöglichen.
Bis 2024 bot jedes seriöse Residential-Netzwerk in der Branche Bandbreiten-basiertes Pricing als Standard an. Shifter eingeschlossen. Wir haben die Legacy-Port-Pläne für Kunden verfügbar gehalten, die ihren Stack darauf aufgebaut hatten - diese Legacy-Verpflichtung gilt weiterhin - aber alles Neue wurde bandbreitenbasiert bepreist.
Was Bandbreiten-Pricing tatsächlich verändert
Einige Dinge werden einfacher, eine Sache wird schwieriger.
Einfacher: der Kauf. “Ich muss etwa 200 GB Seiten pro Monat scrapen” ist ein Satz, den ein Kunde formulieren kann, bevor er überhaupt etwas gebaut hat. “Ich brauche 80 Ports” ist ein Satz, der erfordert, den Workload erst auszuführen, um das herauszufinden.
Einfacher: die Planung. Bandbreite skaliert linear mit den bewegten Daten. Die Scraping-Frequenz zu verdoppeln verdoppelt die Bandbreite. Verdreifachen, und man verdreifacht sie. Keine Schwellenwert-Klippen, keine Parallelitätsengpässe zu Spitzenzeiten.
Einfacher: die Abrechnung. Eine Zahl auf der Rechnung. Kein “Sie haben 110 % Ihrer Parallelität genutzt, aber nur 40 % Ihres Traffics, hier ist die Rechnung.” Kunden wissen, wofür sie zahlen.
Schwieriger: die Disziplin. Bandbreite ist ein offener Wasserhahn. Ein falsch konfigurierter Scraper, der vollständige Seiten-Assets herunterlädt, obwohl er nur den HTML-Body benötigte, kann die Bandbreite vervierfachen, ohne zusätzliche nützliche Daten zu produzieren. Mit Ports hätte dieser Scraper die Parallelitätsgrenze erreicht und der Betreiber hätte es bemerkt. Mit Bandbreite läuft er einfach die Rechnung hoch, bis jemand den Egress prüft.
Die Gegenmaßnahme besteht darin, bei Request-Formen bewusst vorzugehen. Keine Bilder abrufen, wenn man nur Produktdaten möchte. Accept-Encoding: gzip verwenden (die meisten Clients tun dies standardmäßig, aber es lohnt sich zu prüfen). Query-Parameter entfernen, die Asset-Bundles auslösen. HEAD vor GET abrufen, wenn man nur Response-Codes benötigt.
Wohin die Branche sich entwickelt
Bandbreiten-Pricing hat den Residential-Markt gewonnen. Die nächste Differenzierungsachse ist nicht mehr das Preismodell, sondern was im Paket enthalten ist, welche Features kostenlos sind und was auf das Bandbreitenkontingent angerechnet wird.
Einige Beispiele, wo Anbieter sich 2026 differenzieren:
Sticky-Session-Pricing. Manche Anbieter berechnen Sticky-Session-Bandbreite zu einem Aufpreis. Wir nicht - Sticky Sessions werden zum gleichen Tarif wie per-Request-Rotation abgerechnet.
Geo-Targeting als Feature. Manche Anbieter bepreisen Targeting auf Stadt- oder ASN-Ebene als Upgrade. Wir nicht - alle Geo-Präzision ist in jedem Plan enthalten.
Parallelitätsbeschränkungen. Manche Anbieter verhängen weiterhin Parallelitätslimits zusätzlich zu Bandbreitenkontingenten. Wir nicht - unbegrenzte gleichzeitige Verbindungen in jedem Plan.
API und Dashboard. Da Bandbreite nun die Messgröße ist, wollen Kunden Transparenz. Wie viele GB pro Endpunkt, pro Geo, pro Session, in stündlicher Granularität. Das ist heute eine Grundvoraussetzung, kein Premium-Feature.
Für Käufer lautet die Lektion dieselbe wie in jeder Infrastrukturkategorie: das Kleingedruckte lesen, was abgerechnet wird und was im Paket enthalten ist. Der Listenpreis pro GB ist bedeutungslos, wenn die Hälfte der Features, die man tatsächlich nutzen wird, Aufpreise auslösen.
Ausblick
Bandbreiten-Pricing ist nicht die endgültige Form. Da sich Workloads weiter in Richtung KI-Agenten verlagern, die eine kleine Anzahl hochwertiger Anfragen stellen, anstatt Scraper, die sich über Millionen von geringwertigen verteilen, werden request-basierte oder erfolgsratenbasierte Preismodelle für bestimmte Vertikale wahrscheinlich wieder auftauchen.
Für den Moment hat sich Bandbreite jedoch als die richtige Einheit etabliert. Die Port-Ära hat ihren Zweck erfüllt, und sie ist vorbei.