Der Proxy-Markt wird üblicherweise als Zweiproduktwelt dargestellt. Datacenter für rohe Geschwindigkeit und niedrige Kosten. Residential für Unblockierbarkeit und echte Nutzerauthentizität. Man wählt eine Option basierend auf dem eigenen Workload.
Diese Sichtweise lässt eine dritte Kategorie außer Acht, die nach meiner Erfahrung aus etwa tausend Deployments häufiger die richtige Antwort ist als die beiden anderen. ISP-Proxys liegen zwischen Datacenter und rotierenden Residential-Proxys und lösen eine Klasse von Problemen, mit der keiner der anderen beiden gut umgehen kann.
Dieser Beitrag ist ein Plädoyer dafür, ISP-Proxys häufiger einzusetzen, und gleichzeitig ein Argument dafür, sie an weniger Stellen zu verwenden, als manche Teams manchmal versuchen.
Was ISP-Proxys eigentlich sind
Die technische Definition: Ein ISP-Proxy ist eine IP-Adresse, die von einem echten Residential-ISP (Comcast, AT&T, BT, Deutsche Telekom usw.) vergeben wurde, aber in einem Rechenzentrum gehostet und vom Proxy-Betreiber statisch gehalten wird. Der vorgelagerte IP-Block gehört einem Haushalts-ISP. Die eigentliche Maschine, über die der Traffic ausgeht, steht in einem Rack irgendwo.
Das klingt nach einem seltsamen Hybrid, und das ist es auch. Der Grund für seine Existenz liegt darin, dass die Anti-Bot-Abwehr von Zielseiten Entscheidungen teilweise anhand des vorgelagerten ASN trifft, also des Netzwerks, dem der IP-Block zugewiesen wurde. Ein IP-Block, der Comcast zugewiesen ist, sieht für den Geolocation- und Reputationsanbieter einer Seite wie “Haushalte” aus. Ein IP-Block, der einem Hosting-Unternehmen zugewiesen ist, sieht aus wie “Datacenter, verdächtig.”
Die Hosting-Realität taucht in der Abfrage nicht auf. Der ASN schon.
Was das konkret bringt
Drei Eigenschaften, die reines Datacenter nicht bietet:
Netzwerkreputation. Die IP befindet sich in einem Residential-Bereich, sodass die Reputationsdatenbanken sie neutral bewerten. Man löst nicht den automatischen “Datacenter, drosseln”-Reflex am Edge aus.
Geografische Spezifität. ISP-Zuweisungen sind an echte Regionen gebunden. Eine IP im Comcast-Cleveland-Block wird auf Cleveland geolokalisiert. Man erhält Genauigkeit auf Stadtebene, die reines Datacenter oft verfehlt (die meisten Datacenter-IPs werden auf den Standort des Colos geolokalisiert, nicht auf den gewünschten Standort des Kunden).
Stabilität. Im Gegensatz zu rotierenden Residential-Proxys gehört die IP für die Dauer des Plans einem selbst. Die Zielseite sieht jedes Mal dieselbe IP. Cookies bleiben erhalten. Session-Binding funktioniert.
Was man im Vergleich zu rotierenden Residential-Proxys aufgibt, ist die vorgelagerte Diversität. Man ist nicht 200 Millionen IPs tief; es sind einige Dutzend oder Hunderte. Wenn die Zielseite die IP sperrt, bekommt man nicht automatisch eine neue.
Wann ISP-Proxys die richtige Antwort sind
Drei Workload-Formen, bei denen ISP-Proxys beide Alternativen deutlich übertreffen:
Account-Management im großen Maßstab. Man betreibt Dutzende bis Hunderte von Accounts auf einer Plattform (z. B. Social-Media-Management für Kundenmarken, E-Commerce-Verkäuferkonten bei verschiedenen Anbietern, Ad-Accounts in verschiedenen Netzwerken). Jeder Account benötigt eine konsistente IP über Logins hinweg. Rotierende Residential-Proxys brechen die Account-IP-Bindung und lösen erneute Authentifizierung aus. Reines Datacenter löst Anti-Bot aus. Feste ISP-IPs passen genau zu diesem Muster.
Langlebige Session-Arbeit. Alles, was eine Session stundenlang offen hält, wie kontinuierliches Monitoring von Auktionen, Streaming mit Residential-Identität oder umfangreiche Recherche-Crawls, benötigt eine IP, die nicht mitten in der Session abläuft. Rotierende Residential-Sessions sind durch ihre TTL begrenzt; feste ISP-IPs nicht.
Durchsatzintensive Workloads gegen tolerante Seiten. Wenn man eine Seite anspricht, die nicht aggressiv blockiert, aber bandbreitenintensiv ist (etwa kontinuierliches Monitoring der öffentlichen Katalog-API eines Anbieters), bietet Datacenter-Latenz mit echter Netzwerkreputation sowohl den Durchsatz als auch die Unblockierbarkeit. Rotierende Residential-Proxys fügen 50-200 ms pro Anfrage für Routing-Overhead hinzu, den man bei einem toleranten Ziel gar nicht braucht.
Der dritte Punkt ist der, bei dem Kunden ISP-Proxys am häufigsten nicht in Betracht gezogen haben. Sie greifen standardmäßig auf Residential zurück, weil “wir echt aussehen müssen”, und zahlen die Latenzsteuer, obwohl die Zielseite Datacenter-Traffic gar nicht blockiert hätte.
Wann ISP-Proxys die falsche Antwort sind
Zwei Workload-Formen, bei denen ISP-Proxys enttäuschen werden:
Hochvolumige Fan-out-Scrapes. Man ruft täglich 100.000 Produktseiten bei 50 Anbietern ab. Jede Anfrage muss wie ein anderer Besucher aussehen. ISP-Proxys haben einen kleinen Pool, sodass man dieselbe IP für Tausende von Anfragen gegen dasselbe Ziel wiederverwendet, genau das, worauf die meisten Anti-Bot-Systeme achten. Rotierende Residential-Proxys sind hier das richtige Werkzeug.
Harte Ziele mit aktiver Abwehr. Seiten, die IPs aggressiv basierend auf Echtzeit-Verhalten sperren, die aggressivsten Cloudflare-Einstellungen, bestimmte Finanzseiten, bestimmte Reiseaggregatoren mit feindlichem Anti-Bot, werden den ISP-Pool schnell aufbrauchen. Mit rotierenden Residential-Proxys hat man praktisch unbegrenzte Ersatz-IPs; mit ISP-Proxys hat man das Kontingent in wenigen Tagen verbraucht.
Das Signal, dass man das falsche Werkzeug verwendet, ist meist offensichtlich: Die Erfolgsrate bei einem bestimmten Ziel sinkt über einige Tage. Mit rotierenden Residential-Proxys bleibt die Erfolgsrate stabil, weil der Pool ständig aufgefrischt wird. Mit ISP-Proxys nimmt die Erfolgsrate ab, da immer mehr IPs vom Ziel gesperrt werden.
Die Preislogik
Beide Produkte haben rationale Preismodelle, die zeigen, wofür sie gebaut wurden.
Rotierende Residential-Proxys werden pro GB Bandbreite berechnet, weil der Kostentreiber die vorgelagerten Verträge mit den Residential-SDK-Partnern sind. Jedes GB, das man überträgt, ist ein GB, das das SDK liefern muss. Parallelität ist kostenlos, die IP-Anzahl ist praktisch unbegrenzt, man zahlt für den Datenfluss.
ISP-Proxys werden pro IP berechnet, weil der Kostentreiber die statische Zuweisung ist. Jede feste IP ist für einen reserviert, egal ob man sie nutzt oder nicht. Bandbreite ist unbegrenzt, weil es keine vorgelagerten Kosten pro GB gibt. Sobald man die IP hat, ist die marginale Anfrage kostenlos.
Das bedeutet, dass die Kostenrechnung völlig unterschiedlich ist. Bei rotierenden Residential-Proxys teilt man das monatliche Bandbreitenbudget durch den GB-Preis, und das ist der Plan. Bei ISP-Proxys zählt man, wie viele gleichzeitige Accounts, Sessions oder Identitäten man benötigt, und multipliziert mit den Kosten pro IP.
In der Praxis: Wenn man 10 langlebige Sessions betreibt, ist ISP deutlich günstiger als die Bandbreite, die diese Sessions bei Residential verbrauchen würden. Wenn man 10.000 kurzlebige Fan-out-Scrapes durchführt, ist Residential deutlich günstiger als die Kosten pro IP für das Festhalten von 10.000 ISP-IPs.
Das gemischte Deployment-Muster
Die erfahrensten Kunden wählen nicht nur eine Option. Sie leiten Traffic basierend auf der Workload-Form an das richtige Produkt weiter, oft innerhalb derselben Codebasis. Eine typische Produktionsarchitektur:
- Rotierende Residential-Proxys für die Bulk-Scrape-Schicht: Preis-Intelligence, SERP-Monitoring, Content-Aggregation. Hohes Volumen, kurzlebig, geografisch divers.
- ISP-Proxys für die Account-Schicht: Verwaltung von Verkäuferkonten, Monitoring von Konkurrenz-Ad-Accounts, langlebige authentifizierte Sessions.
- Datacenter für die interne API-Schicht: Aufrufe eigener APIs, Zugriff auf CDN-gecachte Inhalte, alles, was das Ziel nicht zu verteidigen versucht.
Drei verschiedene Proxy-Typen hinter einer Infrastrukturabstraktion, ausgewählt nach Workload-Form, nicht nach Bauchgefühl.
Warum Teams ISP-Proxys zu wenig nutzen
Die ehrliche Antwort: Die meisten Teams wählen ein Produkt, wenn sie neu im Proxy-Bereich sind, und überdenken es nie. Sie haben mit rotierenden Residential-Proxys angefangen, weil das jeder “Best Practices”-Beitrag empfiehlt, haben es in ihre Codebasis integriert und untersuchen nie die Workloads, bei denen es mathematisch das falsche Werkzeug ist.
Wenn man seit drei Jahren ein reines Residential-Deployment betreibt und die Account-Management- oder session-intensiven Workloads nie gegen ISP-Proxys verglichen hat, besteht eine gute Chance, dass man für Residential-Latenz und Bandbreite überzahlt, die man bei diesen Workflows gar nicht braucht.
Der Weg, das herauszufinden, ist der unspektakuläre: Man leitet 10 % eines bestimmten Workflows für zwei Wochen durch einen ISP-Plan, misst die Erfolgsrate, misst die Kosten und vergleicht. Entweder ist es ein klarer Gewinn und man migriert diesen Workflow, oder es ist keiner und man bleibt, wo man war. Beide Ergebnisse sind nützlich.
Der Mittelweg ist nicht glamouröser als die Extreme, was teilweise erklärt, warum er in diesem Markt weniger Aufmerksamkeit bekommt. Aber für eine bestimmte und bedeutende Klasse von Workloads ist er das richtige Werkzeug, und die Werkzeuge, die man verwendet, bestimmen maßgeblich die eigenen Stückkosten.