Die meisten Menschen, die zum ersten Mal Proxys kaufen, gehen die Sache als eine einzige Frage an, welcher Plan, und entscheiden sich am Ende allein nach dem Preis. Das führt meist zu einem von zwei Ergebnissen: einem Plan, der für die Arbeit zu klein ist, was man erst mitten im Monat merkt, oder einem Plan, der für eine Kapazität gekauft wurde, die nie genutzt wird. Keines von beidem ist eigentlich ein Preisfehler. Sie entstehen dadurch, dass man die zwei Entscheidungen überspringt, die vor jedem Preisvergleich stehen sollten.
Eine gute Wahl besteht aus drei Entscheidungen in dieser Reihenfolge: welche Art von Proxy das Projekt braucht, wie viel Bandbreite dieses Projekt tatsächlich verbraucht, und welche Funktionen wirklich erforderlich sind statt nur aufgelistet zu sein. Trifft man diese richtig, wählt sich der Plan von selbst.
Entscheidung eins: welches Produkt das Projekt braucht
Die Produkttypen sind keine Stufen ein und derselben Sache. Sie verhalten sich unterschiedlich, und die falsche Wahl lässt sich nicht dadurch beheben, dass man mehr davon kauft.
Rotierende Residential-Proxys sind der Standard für die Datenerfassung. Man greift auf einen großen Pool echter Heimadressen zu, und standardmäßig läuft jede Anfrage über eine andere Adresse, wodurch sich das Volumen so verteilt, dass keine einzelne Adresse auffällt. Diese Wahl passt bei Scraping, Preis- oder Verfügbarkeitsüberwachung, SERP- und Ranking-Erfassung, Anzeigenverifizierung oder jeder Aufgabe, deren Charakter viele Anfragen über viele Ziele oder Märkte hinweg ist.
Statisches Residential, oder ISP-Proxys, sind gehostete Adressen, die bei einem Consumer-Internetanbieter registriert sind, sodass sie residential-typisches Vertrauen genießen, dabei aber über die Zeit gleich bleiben. Diese Wahl passt, wenn Beständigkeit die Anforderung ist statt Volumen: die Verwaltung von Konten, die stets von derselben Adresse aus gesehen werden sollen, langlebige Sitzungen, oder alles, bei dem eine sich ändernde Adresse das Problem ist statt die Lösung. Der Kompromiss wird in ISP versus Residential und was statische Residential-Proxys sind behandelt.
Datacenter ist am günstigsten und schnellsten, und es ist die richtige Antwort, wenn die Ziele es nicht bemerken. Trifft man auf eine offene API, die eigene Infrastruktur oder Seiten ohne nennenswerte Abwehrmaßnahmen, ist die Bezahlung von Residential-Preisen Verschwendung. Der ehrliche Vergleich findet sich in Residential versus Datacenter.
Die praktische Regel lautet, den günstigsten Typ zu verwenden, der die tatsächlichen Ziele zuverlässig passiert, und das durch Testen festzustellen statt anzunehmen. Viele Projekte enden gemischt: Datacenter für die einfachen Quellen, Residential für die geschützten.
Entscheidung zwei: wie viel Bandbreite
Residential-Proxys werden nach übertragenen Daten abgerechnet statt nach der Anzahl der berührten Adressen, daher ist die Bandbreite die Zahl, die den Plan bestimmt. Die Überlegung hinter diesem Modell steht in warum die Ära pro Port vorbei ist, und die Methode zur Dimensionierung ist unkompliziert.
Man schätzt die durchschnittliche Größe einer Antwort der Zielseiten, multipliziert mit der erwarteten Anzahl an Anfragen pro Monat, und rechnet einen Puffer für Wiederholungen und Fehlschläge hinzu. Eine einfache HTML-Seite oder eine JSON-API-Antwort umfasst meist Dutzende Kilobyte; eine vollständig im Browser gerenderte Seite mit Bildern, Schriftarten und Skripten kann mehrere Megabyte umfassen, was die mit Abstand größte Variable in der gesamten Berechnung ist. Zehntausend JSON-Aufrufe am Tag ergeben einen ganz anderen Plan als zehntausend vollständig gerenderte Seiten am Tag, und der Unterschied beträgt etwa zwei Größenordnungen. Die durchgerechnete Methode steht in monatliche Bandbreite schätzen.
Zwei Dinge senken die Zahl, bevor man kauft. Den zugrunde liegenden Daten-Endpunkt abzurufen statt die ganze Seite zu rendern, ist der größte Hebel, und das Blockieren von Bildern, Medien und Schriftarten, wenn tatsächlich gerendert werden muss, ist der zweite, beide behandelt in Proxy-Bandbreitenkosten senken. Diese Optimierung lohnt sich, bevor man einen Plan dimensioniert, da sie einen in eine niedrigere Stufe bringen kann.
Man beachte, was nicht auf dieser Liste steht: wie viele IPs man erhält. In einem gepoolten Netzwerk ist das nicht die Menge, die man kauft, und die Begründung steht in wie viele Proxy-IPs man tatsächlich braucht. Die einzige Ausnahme sind gleichzeitige Sticky-Sessions, was eine reale Anforderung ist, die man benennen sollte, wenn die Arbeit gehaltene Identitäten braucht.
Entscheidung drei: welche Funktionen tatsächlich erforderlich sind
Funktionslisten sind der Punkt, an dem Pläne kompliziert wirken. Das meiste lässt sich auf fünf Fragen reduzieren.
Geografische Granularität. Länder-Targeting deckt die meisten Projekte ab. Hängt die Arbeit von lokalen Ergebnissen, lokalen Preisen oder filialgenauen Daten ab, braucht man City-Level-Targeting, und bei providerspezifischem Verhalten braucht man ASN-Targeting. Prüfen Sie, ob die relevanten Länder gut abgedeckt sind, nicht nur, ob eine große globale Zahl beworben wird.
Sitzungskontrolle. Bestätigen Sie, dass Sie sowohl pro Anfrage rotieren als auch eine Sticky Session halten können, wenn ein mehrstufiger Ablauf das erfordert. Die meisten realen Projekte brauchen beides zu unterschiedlichen Zeitpunkten.
Nebenläufigkeit. Fragen Sie, welches Limit für gleichzeitige Verbindungen gilt, denn ein Plan, der Nebenläufigkeit separat misst, drosselt eine Aufgabe, die ein reiner Bandbreitenplan problemlos ausführen würde. Siehe unbegrenzte gleichzeitige Verbindungen.
Protokolle und Integration. HTTP und SOCKS5 decken fast alles ab; wichtiger ist, dass sich das Targeting so ausdrücken lässt, dass der eigene Stack es pro Anfrage steuern kann, was bei einem Gateway bedeutet: Zugangsdaten im Benutzernamen statt eines Dashboard-Schalters.
Alles Übrige ist meist zweitrangig, bis man im großen Maßstab arbeitet, ab dem Punkt zählen Support-Reaktionszeit und Abrechnungsflexibilität mehr als jedes Feature-Kästchen.
Übliche Projektformen zu Plänen zuordnen
Ein paar Muster decken die meisten ersten Käufe ab.
Ein kleines Recherche- oder Überwachungsprojekt, das täglich einige hundert Seiten verfolgt, liegt typischerweise bei wenigen Gigabyte im Monat auf rotierendem Residential mit Länder-Targeting. Beginnen Sie mit der kleinsten Stufe, die Ihre Schätzung mit Puffer abdeckt, denn ein späteres Hochstufen ist einfach, während der Kauf einer großen Stufe für ein noch nicht validiertes Projekt es nicht ist.
Eine produktive Scraping-Pipeline über viele Ziele hinweg ist der Punkt, an dem sich die Bandbreitenschätzung auszahlt und an dem sich die Optimierungsarbeit direkt lohnt. Dimensionieren Sie anhand gemessener Nutzung aus einem Test statt einer Vermutung, und rechnen Sie damit, dass die tatsächliche Zahl in beide Richtungen von Ihrer Schätzung abweichen kann.
Konto- oder sitzungsbasierte Arbeit verweist auf statische ISP-Adressen und eine festgelegte Anzahl gleichzeitiger Sitzungen statt auf einen großen rotierenden Pool.
Gemischte Arbeitslasten sind üblich und in Ordnung: Datacenter für ungeschützte Quellen, Residential für den Rest. Jedes einzeln zu dimensionieren ist günstiger, als alles über den teuren Weg laufen zu lassen.
Vor der Festlegung validieren
Was auch immer Sie folgern, behandeln Sie es als Hypothese und testen Sie es in einem Test oder einem kleinen ersten Kauf, bevor Sie skalieren. Nutzen Sie Ihre tatsächlichen Ziele, nicht eine generische Test-URL, und messen Sie die Erfolgsquote mit Antwortvalidierung statt allein mit Statuscodes, da eine Challenge-Seite mit Status 200 sonst wie ein Erfolg aussieht. Bestätigen Sie, dass die bezahlte Geografie auch der gelieferten entspricht. Messen Sie die tatsächlichen Bytes pro Anfrage, damit aus Ihrer Bandbreitenschätzung eine Messung wird. Die Methode steht in Geschwindigkeit, Erfolgsquote und Standortgenauigkeit testen, und die Kriterien auf Anbieterebene stehen in wie man ein Proxy-Netzwerk auswählt.
Eine Woche echter Nutzung sagt mehr aus als jedes Datenblatt, und sie macht aus allen drei oben genannten Entscheidungen Fakten statt Schätzungen.
Fazit
Wählen Sie den Produkttyp danach, was Ihre Ziele erfordern, nicht nach dem Preis: rotierendes Residential für Volumen und Geografie, statisches ISP für Beständigkeit, Datacenter dort, wo die Ziele es nicht bemerken. Dimensionieren Sie den Plan nach Bandbreite, das heißt: Antwortgröße mal Anfragenvolumen schätzen und optimieren, was Sie abrufen, bevor Sie kaufen, da dies allein Sie eine Stufe herabsetzen kann. Verlangen Sie nur die Funktionen, die Ihr Projekt tatsächlich nutzt, wobei geografische Granularität und Sitzungskontrolle die beiden sind, die am häufigsten wichtig sind. Validieren Sie dann an echten Zielen, bevor Sie skalieren, denn gemessene Nutzung schlägt jede Schätzung.
Falls das auf rotierendes Residential hinausläuft: Residential-Proxys bieten Länder- und City-Targeting, standardmäßige Rotation und Sticky Sessions, wenn ein Ablauf das erfordert, mit Preisgestaltung pro GB, sodass der Plan die tatsächlich bewegte Datenmenge widerspiegelt statt einer Sitzanzahl oder einer Port-Zuteilung.