Wie viele Proxys braucht man eigentlich?

Wir verkaufen Proxys unter Geonode, weshalb dieser Artikel dafür plädiert, dass Sie weniger kaufen sollten, als Sie ursprünglich vorhatten. Das ist tatsächlich unsere Position: Ein überdimensionierter Pool macht Sie nicht sicherer, und bei einer verkehrsabhängigen Preisgestaltung kostet er nicht einmal mehr – was bedeutet, dass die Leute ein falsches Denkmodell haben, ohne jemals die Rechnung zu sehen, die dies korrigieren würde. Die entscheidende Zahl ist die gleichzeitige Nutzung eines einzelnen Ziels, und diese lässt sich an einem Nachmittag messen. Wenn Sie eine Erkenntnis aus diesem Artikel mitnehmen, dann sollte es die Messung im nächsten Abschnitt sein und nicht irgendeine Zahl, die wir Ihnen nennen könnten.

Die einzige Methode, die funktioniert

Drei Schritte, alle empirisch fundiert.

Schritt eins: Ermitteln Sie die Obergrenze pro Adresse. Führen Sie Ihre tatsächliche Arbeitslast von einer einzigen Adresse aus aus, erhöhen Sie dabei schrittweise die Anfragerate und ermitteln Sie, ab wann das Ziel System Anzeichen von Überlastung zeigt – 429-Fehler, Herausforderungen, langsamere Antworten oder beeinträchtigte Inhalte. Dieser Schwellenwert ist Ihre Kapazität pro Adresse für dieses Ziel, und es ist die einzige Zahl in dieser Berechnung, die keine Schätzung ist.

Schritt zwei: Legen Sie Ihren erforderlichen Durchsatz fest. Wie viele Anfragen über welchen Zeitraum. Seien Sie ehrlich, was den Zeitraum betrifft, denn dieser hat in dieser Gleichung den größten Einfluss.

Schritt drei: Teilen. Der erforderliche Durchsatz geteilt durch die Kapazität pro Adresse ergibt die benötigte Anzahl gleichzeitiger Adressen. Rechnen Sie eine Marge für Wiederholungsversuche und Schwankungen hinzu – 50 % sind großzügig bemessen, und wenn Sie mehr benötigen, war Ihre Messung in Schritt eins wahrscheinlich zu optimistisch.

Das ist die gesamte Methode. Der Grund, warum dies nicht der Standardratschlag ist, liegt darin, dass hierfür vor dem Kauf ein Test durchgeführt werden muss und Anbieter keinen Anreiz haben, dies vorzuschlagen.

Ein Hinweis zu Schritt eins: Messen Sie die Anzahl der abgeschlossenen, nützlichen Antworten pro Sekunde, nicht die Anzahl der versuchten Anfragen. Ein Pool, der 200er-Antworten mit gestrichenem Inhalt zurückgibt, funktioniert nicht, und eine aggregierte Erfolgsraten-Metrik würde ihn als fehlerfrei ausweisen. Suchen Sie in der Antwort nach einem bekanntermaßen stabilen Marker und zählen Sie nur die Antworten, die diesen enthalten.

Die Messung korrekt durchführen

Die gesamte Methode beruht auf Schritt eins, daher lohnt es sich, genau zu beschreiben, wie man ihn durchführt, ohne sich selbst in die Irre zu führen.

Testen Sie anhand Ihres tatsächlichen Ziels, nicht anhand eines Testendpunkts. Ein Testlauf bei einem Dienst, der Ihre IP-Adresse zurückgibt, zeigt Ihnen lediglich, dass Ihr Proxy funktioniert, sagt aber nichts darüber aus, wie die für Sie relevante Website auf Sie reagieren wird. Jedes Ziel hat seine eigene Toleranzgrenze, und der erforderliche Wert ist zielspezifisch.

Steigern Sie die Last schrittweise und protokollieren Sie alles. Beginnen Sie deutlich unterhalb des erwarteten Grenzwerts und steigern Sie die Last schrittweise, wobei Sie jede Rate lange genug beibehalten, um ein Muster zu erkennen – mindestens einige Minuten. Protokollieren Sie für jeden Schritt die Rate, die Statuscodes, die Antwortgrößen und die tatsächliche Zeit:

for rate in 0.2 0.5 1 2 5 10; do
  echo "=== $rate req/s"
  for i in $(seq 1 60); do
    code=$(curl -s -x "$PROXY" -o /tmp/body -w '%{response_code}' "$URL")
    size=$(stat -c%s /tmp/body 2>/dev/null || stat -f%z /tmp/body)
    echo "$rate $code $size"
    sleep "$(echo "1/$rate" | bc -l)"
  done
done | tee ramp.log

Beobachten Sie die Antwortgröße genauso genau wie den Statuscode. Die häufigste Form der Ablehnung ist kein 429, sondern ein 200 mit einer kleineren Seite. Ein Rückgang der durchschnittlichen Antwortgröße bei einer bestimmten Rate bedeutet, dass das Zielsystem beginnt, Ihnen reduzierte Inhalte zu liefern, und dies bleibt unsichtbar, wenn Sie nur die Statuscodes zählen.

Führen Sie den Test zu verschiedenen Tageszeiten durch. Die Toleranz ist während der Spitzenzeiten einer Website häufig geringer, und ein um 3 Uhr morgens gemessener Grenzwert gilt mittags nicht mehr. Nehmen Sie den pessimistischsten Wert.

Wiederholen Sie den Test mit einer zweiten Adresse. Wenn eine Adresse bei zwei Anfragen pro Sekunde an ihre Grenzen stößt und eine zweite Adresse zur gleichen Zeit an dieselbe Grenze stößt, liegt der Grenzwert nicht pro Adresse – er liegt in Ihrem Subnetz, Ihrer Anfragestruktur oder einem anderen Faktor, den mehr Adressen nicht beheben können. Das ist ein wichtiges negatives Ergebnis, dessen Ermittlung einen zusätzlichen Testlauf erfordert.

Hören Sie dann vor der Obergrenze auf, nicht genau an ihr. Wenn Sie mit der maximalen Rate arbeiten, die ein Ziel verträgt, führt jede normale Schwankung dazu, dass Sie diese überschreiten. Eine Dimensionierung bei 60–70 % der gemessenen Obergrenze sorgt dafür, dass der Auftrag zuverlässig abgeschlossen wird, anstatt nur dann, wenn die Bedingungen gut sind.

Beispiel: Tägliche Preisüberwachung

Die häufigste Arbeitslast – und die, bei der die Antwort die Leute am meisten überrascht.

Anforderung: 50.000 Produktseiten, die einmal täglich überprüft werden.

Gemessene Obergrenze: Das Zielsystem toleriert etwa eine Anfrage alle zwei Sekunden von einer einzelnen Adresse, bevor eine Ratenbegrenzung greift – das sind etwa 1.800 Anfragen pro Stunde.

Verteilt auf 24 Stunden: 50.000 ÷ 24 ≈ 2.100 Anfragen pro Stunde.

Benötigte Adressen: 2.100 ÷ 1.800 ≈ 1,2. Aufrunden und Spielraum hinzufügen: zwei bis vier Adressen.

Zwei Adressen. Für fünfzigtausend Seiten pro Tag, bei einem Pool, der mit Millionen angegeben wird.

Ändern wir nun eine Annahme. Nehmen wir an, der Auftrag muss innerhalb eines Zeitfensters von zwei Stunden abgeschlossen werden, anstatt sich über den Tag zu verteilen:

Anforderung: 50.000 Seiten in 2 Stunden = 25.000 pro Stunde. Benötigte Adressen: 25.000 ÷ 1.800 ≈ 14, plus Sicherheitspuffer: etwa 20.

Gleiches Volumen, gleiches Ziel, zehnmal so viele Adressen – aufgrund einer terminlichen Entscheidung, nicht aufgrund einer Anforderung an die Scraping-Geschwindigkeit.

Das ist die wichtigste Erkenntnis in diesem Artikel. Das Zeitfenster, das Sie sich einräumen, ist die entscheidende Variable. Bevor Sie weitere Adressen kaufen, fragen Sie sich, ob der Auftrag tatsächlich schnell erledigt werden muss und wie viel diese Geschwindigkeit wert ist. Oft ist sie überhaupt nichts wert, da die Daten bereits am nächsten Morgen verbraucht sind.

Beispiel: Geografische Abfragen

Eine völlig andere Struktur, und die Berechnung läuft umgekehrt ab.

Anforderung: Viermal täglich sollen die regionalen Preise und die Verfügbarkeit in 30 Märkten auf jeweils 50 Seiten pro Markt überprüft werden.

Umfang: 30 × 4 × 50 = 6.000 Anfragen pro Tag. Ein Kinderspiel.

Für den Durchsatz benötigte Adressen: im Grunde eine. Sechstausend Anfragen, verteilt über einen Tag, entsprechen einer Anfrage alle vierzehn Sekunden.

Für die Abdeckung benötigte Adressen: mindestens ein funktionierender Ausgang in jedem der 30 Länder, genau dann, wenn man ihn braucht.

Die Einschränkung liegt hier keineswegs im Volumen, sondern in der Präsenz. Sie sollten prüfen, ob der Anbieter tatsächlich eine zuverlässige Abdeckung in den spezifischen Märkten bietet, die Sie benötigen, und zwar zu den Zeiten, zu denen Sie den Dienst nutzen – nicht, wie viele Adressen der Pool enthält. Ein Pool von zehn Millionen mit geringer Abdeckung in drei Ihrer Märkte ist schlechter als ein Pool von zehntausend, der alle dreißig abdeckt.

Deshalb ist „Wie viele brauche ich?“ die falsche Frage für geografische Anwendungen, und „Wo können Sie zuverlässig erreichen, und kann ich das testen?“ ist die richtige.

Beispiel: Sitzungsbasierte Arbeit

Der Fall, in dem Parallelität und Identität dasselbe sind.

Anforderung: 10 authentifizierte Sitzungen parallel betreiben, wobei jede Sitzungen aus mehreren Schritten durchführt.

Benötigte Adressen: 10, und diese müssen „sticky“ sein – d. h., eine Adresse wird für die Dauer jeder Sitzung beibehalten.

Das Volumen spielt hier keine Rolle. Wichtig ist, dass jede Sitzung eine einheitliche Identität aufweist: durchgehend dieselbe Adresse mit übereinstimmender Ländereinstellung und Zeitzone. Eine Sitzung, deren Anfragen aus vier verschiedenen Ländern eingehen, ist keine Sitzung, sondern ein Muster.

Der zu vermeidende Fehler ist die Verwendung eines pro Anfrage rotierenden Endpunkts, was bei den meisten Gateways die Standardeinstellung ist. Die Anfragen sind erfolgreich, der Sitzungsstatus geht verloren, und das Symptom sieht so lange wie ein Anwendungsfehler aus, bis jemand die Ausgangsadressen überprüft.

Beachten Sie außerdem, dass zehn gleichzeitige Sitzungen nicht bedeuten, dass es für immer zehn Adressen gibt – es bedeutet zehn gleichzeitig. Eine Arbeitslast, bei der im Laufe des Tages 200 Sitzungen nacheinander ablaufen, benötigt dennoch nur zehn wiederverwendete „sticky“ Adressen.

Warum mehr nicht sicherer ist

Die Annahme, die den meisten überdimensionierten Käufen zugrunde liegt, ist in dreierlei Hinsicht falsch.

Die Sperrung erfolgt nach Subnetz, nicht nach Adresse. Websites sperren in der Regel auf der Ebene von /24. Fünfzig Adressen in einem Block verhalten sich wie eine einzige Adresse, wenn dieser Block gesperrt ist. Daher ist ein großer Adresspool mit schlechter Verteilung kein großer Pool in dem Sinne, auf den es ankommt. Die Verteilung ist wichtiger als die Anzahl, und wir haben die Mechanismen unter Was ist eine Subnetz-ID? erläutert.

Die Rate ist das Signal, nicht die Identität. Wenn Ihre Anfragen aufgrund des Zeitablaufs, der Header oder des TLS-Fingerabdrucks automatisiert wirken, verteilt sich das Signal durch die Verteilung auf mehr Adressen, ohne dass es beseitigt wird. Am Ende werden mehr Adressen als weniger markiert.

Ungenutzte Adressen veralten. In einem rotierenden Pool hat eine Adresse, die Sie nicht genutzt haben, keinerlei Beziehung zum Ziel – weder positiv noch negativ. Das Vorhalten von „Reservekapazität“ ist keine Art von Vorrat.

Es gibt einen einzigen triftigen Grund, mehr Adressen zu halten, als der Durchsatz erfordert: Fluktuation. Wenn ein Ziel im Laufe der Zeit Adressen markiert, benötigen Sie Ersatzadressen, die rotieren können. Das ist eine echte Anforderung, deren Umfang sich nach der beobachteten Markierungsrate richtet und nicht nach Intuition – messen Sie, wie viele Adressen pro Tag unbrauchbar werden, und halten Sie einen Vorrat für einige Tage bereit.

Was Sie tatsächlich kaufen

Das sollte klar gesagt werden, denn die Antwort hängt vom Preismodell ab und verändert sogar die Bedeutung der Frage.

Bei der Abrechnung pro Gigabyte – so wird der Datenverkehr für Privatkunden und oft auch für Rechenzentren verkauft – kaufen Sie überhaupt keine Adressen. Sie kaufen Daten, und die Anzahl der Adressen ist eine Eigenschaft des Pools und nicht Ihres Tarifs. Die Frage „Wie viele Proxys brauche ich?“ ist in diesem Zusammenhang ein Kategorienfehler – die eigentlichen Fragen lauten, wie viel Datenverkehr Sie übertragen werden und ob der Pool dort Abdeckung bietet, wo Sie sie benötigen. Unser Privatverkehr beginnt bei 0,79 $/GB und der für Rechenzentren bei 0,14 $/GB, Stand September 2026 gemäß unserer Preisseite.

Bei der Preisgestaltung pro IP, wie sie bei Internetdienstanbietern und vielen Rechenzentrumsprodukten üblich ist, zahlen Sie buchstäblich für die Anzahl der IP-Adressen, und diese gesamte Berechnung ist eine Budgetposition. Bei uns kostet eine IP 1,25 $/IP. Hier geht es bei der obigen Rechnung um Geld, und es lohnt sich, die zwanzig Minuten zu investieren, um das richtig zu machen.

Welches Modell für Sie geeignet ist, hängt eher von der Art Ihrer Arbeitslast als vom Nennpreis ab, und beide sind nicht miteinander vergleichbar. Bei einer Arbeitslast, die viele Adressen benötigt, ist die Abrechnung nach Datenverkehr kurzzeitig vorteilhaft; bei einer, die nur wenige Adressen benötigt, ist die Abrechnung pro IP deutlich vorteilhafter. Wir haben die Berechnungen im Leitfaden zur Proxy-Preisgestaltung ausführlich erläutert.

Faustregeln und ihre Grenzen

Wenn Sie vor der Messung einen Ausgangspunkt benötigen, sind diese Regeln vertretbar. Betrachten Sie sie als ersten Anhaltspunkt, der noch angepasst werden muss, und nicht als endgültige Antwort.

Zwei Zahlen, die man sich verinnerlichen sollte. Kaum eine Arbeitslast benötigt mehr als ein paar Dutzend gleichzeitige Adressen, und diejenigen, bei denen dies tatsächlich der Fall ist, sind entweder geografischer Natur (viele Standorte, jeweils geringes Volumen) oder unterliegen einer selbst auferlegten Frist. Und die Zahl, die am häufigsten angepasst werden muss, ist nicht die Anzahl der Adressen, sondern der Zeitplan.

Anzeichen dafür, dass Sie die Zahl falsch eingeschätzt haben

Zu wenig sieht so aus: steigende 429-Fehler, auftretende Probleme, sinkende Erfolgsquote im Verlauf des Durchlaufs, Aufträge, die später als geplant fertiggestellt werden. Die Lösung ist mehr Parallelität oder ein längeres Zeitfenster.

Zu viel sieht so aus: gar nichts. Deshalb bleibt der Fehler bestehen. Ein überdimensionierter Pool verursacht bei der Traffic-Abrechnung keine Symptome, sodass niemand ihn entdeckt. Bei der Abrechnung pro IP führt er zu einer Rechnung, was zumindest die Frage aufwirft.

Zwei Dinge, die wie „zu wenige“ aussehen, es aber nicht sind:

Ein blockierter Pool. Wenn die Erfolgsquote über alle Adressen hinweg gleichzeitig einbricht, hilft das Hinzufügen weiterer Adressen nicht – entweder hat sich am Ziel etwas geändert, oder das Muster Ihrer Anfragen wird anhand eines Signals erkannt, das nichts mit der Adresse zu tun hat.

Ein langsames Ziel. Wenn die Antworten langsam, aber erfolgreich sind, hilft eine höhere Parallelität bis zu einem gewissen Punkt beim Durchsatz, danach jedoch nicht mehr. Messen Sie die Anzahl der abgeschlossenen Anfragen pro Sekunde und hören Sie auf, die Parallelität zu erhöhen, sobald diese Zahl ein Plateau erreicht – was früher eintreten wird, als erwartet.

Die allgemeine Diagnose: Erhöhen Sie die Parallelität schrittweise und beobachten Sie die Anzahl der abgeschlossenen, nützlichen Antworten pro Sekunde. Diese steigt an, erreicht ein Plateau und fällt dann ab. Das Optimum liegt auf dem Plateau, und es handelt sich dabei in der Regel um eine geringere Zahl, als man vermuten würde.

Häufig gestellte Fragen

Wie viele Proxys benötige ich für das Web-Scraping?

Lieber messen als raten: Ermitteln Sie die Anfragerate, ab der eine einzelne Adresse bei Ihrem tatsächlichen Ziel begrenzt wird, dividieren Sie Ihren benötigten Durchsatz durch diesen Wert und rechnen Sie eine Sicherheitsmarge hinzu. Die meisten Workloads liegen im einstelligen oder niedrigen zweistelligen Bereich bei den gleichzeitig aktiven Adressen, nicht bei Tausenden.

Verringert sich die Wahrscheinlichkeit, blockiert zu werden, wenn ich mehr Proxys verwende?

Nur, wenn die Sperre adressspezifisch ist. Wenn Ihre Anfragen aufgrund des Zeitabstands, der Header-Zusammensetzung oder des TLS-Fingerabdrucks als automatisiert identifiziert werden, verteilt die Verwendung weiterer Adressen das gleiche Signal auf einen größeren Teil Ihres Pools, anstatt es zu vermeiden. Die Rate und die Form der Anfragen sind wichtiger als die Anzahl.

Wie viele Proxys für 1 Million Anfragen pro Tag?

Das hängt ganz vom Zeitfenster ab. Verteilt auf 24 Stunden sind das etwa 12 Anfragen pro Sekunde, was bei einer Anfrage alle zwei Sekunden pro Adresse etwa 25 gleichzeitige Adressen bedeutet. Auf zwei Stunden komprimiert ist es das Zwölffache davon. Der Zeitplan ist die Variable, nicht das Volumen.

Benötige ich einen Proxy pro Konto?

Bei allen sitzungsbasierten Vorgängen gilt: eine feste Adresse pro gleichzeitiger Sitzung – nicht pro Konto. Zehn Konten, die im Laufe des Tages nacheinander genutzt werden, benötigen nur dann zehn Adressen, wenn alle zehn gleichzeitig aktiv sind. Beachten Sie, dass viele Plattformen den Betrieb mit mehreren Konten ausdrücklich verbieten; prüfen Sie daher die Nutzungsbedingungen, bevor Sie entsprechende Lösungen entwickeln.

Ist es besser, mehr IP-Adressen oder bessere IP-Adressen zu haben?

Besser bedeutet: gut über Subnetze verteilt und für das Ziel geeignet. Blockierungen erfolgen häufig auf der Ebene von „/24“, sodass sich fünfzig Adressen in einem Block wie eine einzige verhalten. Ein kleinerer, gut verteilter Pool schneidet besser ab als ein größerer, konzentrierter.

Woran erkenne ich, ob ich zu wenige Proxys habe?

Zunehmende 429-Fehler, das Erscheinen von Challenge-Seiten und eine im Verlauf des Durchlaufs sinkende Erfolgsquote. Wenn die Erfolgsquote über alle Adressen hinweg gleichzeitig einbricht, handelt es sich um ein anderes Problem – entweder hat sich am Ziel etwas geändert oder Ihre Anfragen werden anhand eines nicht adressbezogenen Signals identifiziert, und mehr Adressen helfen in diesem Fall nicht weiter.

Hat die Anzahl der Proxys Einfluss auf den Preis?

Bei einer Abrechnung pro IP direkt – Sie kaufen die Anzahl. Bei einer Abrechnung pro Gigabyte überhaupt nicht, da Sie für Daten bezahlen und die Anzahl der Adressen eine Eigenschaft des Pools ist. Aus diesem Grund lassen sich die beiden Modelle nicht anhand der Listenpreise vergleichen.

Wie viele Proxys für Geo-Targeting?

Ein zuverlässiger Exit-Server pro Standort, den Sie benötigen; das Volumen spielt dabei in der Regel keine Rolle. Die Frage, die Sie einem Anbieter stellen sollten, lautet nicht, wie viele Adressen er hat, sondern ob er eine zuverlässige Abdeckung in Ihren spezifischen Märkten bietet und ob Sie dies vor einer festen Verpflichtung testen können.

Fazit

Die benötigte Zahl ergibt sich aus einer Messung und einer Division: Finden Sie heraus, ab wann eine einzelne Adresse bei Ihrem tatsächlichen Ziel einer Ratenbegrenzung unterliegt, und dividieren Sie Ihren Durchsatzbedarf durch diesen Wert. Alles andere ist Feineinstellung.

Die Variable, die das Ergebnis maßgeblich bestimmt, ist nicht das Volumen, sondern das von Ihnen zugelassene Zeitfenster. Für 50.000 Seiten pro Tag benötigt man ein paar Adressen, verteilt auf 24 Stunden, und für 20.000 Seiten auf zwei Stunden. Bevor Sie Kapazität kaufen, um schneller voranzukommen, prüfen Sie, ob es tatsächlich darauf ankommt, dass der Auftrag früher fertig wird – oft ist das nicht der Fall, und die kostengünstigste Optimierung ist Geduld.

Und bei geografisch ausgerichteten Aufgaben stellt sich die Frage ganz anders dar. Das Volumen ist nebensächlich, Präsenz ist alles, und die aussagekräftige Bewertung besteht darin, ob ein Anbieter Ihre spezifischen Märkte zuverlässig abdeckt, und nicht darin, wie groß der Pool ist. Das lässt sich in einem Test überprüfen, dauert einen Nachmittag und sagt Ihnen mehr als jede Zahl, die ein Anbieter auf einer Landingpage angibt – einschließlich unserer.