Wie viele Proxy-IPs brauchst du wirklich?

Die häufigste Frage vor dem Proxy-Kauf ist auch die falsche. Es zählt nicht, wie viele IPs du hast, sondern wie deine Anfragen sich über sie verteilen.

Es ist die Frage, die vor fast jedem Proxy-Kauf aufkommt: wie viele IPs brauche ich? Sie klingt nach der Art Sache, die eine Zahl als Antwort haben sollte, und sie fühlt sich wie die Zahl an, die darüber entscheidet, ob der Job funktioniert. In der Praxis ist sie meist die falsche Frage, und Teams, die mit ihr anfangen, kaufen oft das Falsche. Was tatsächlich entscheidet, ob dein Scraping sauber läuft, ist nicht, wie viele Adressen du besitzt, sondern wie deine Anfragen sich über die verteilen, die du nutzt, und ob irgendein einzelnes Ziel je genug Verkehr von einer Adresse sieht, um sich daran zu stören.

So denkt man richtig darüber nach, samt dem einen Fall, in dem IPs zu zählen wirklich der richtige Ansatz ist.

Warum die Frage falsch gestellt ist

Der Instinkt, IPs zu zählen, ist ein Überbleibsel aus einem älteren Preismodell. Als Proxys pro Port oder pro statischer Adresse verkauft wurden, kauftest du eine bestimmte Anzahl IPs, und diese Zahl war deine Kapazität, also ergab Zählen Sinn. Moderne Residential-Netzwerke funktionieren nicht so. Du schöpfst aus einem großen geteilten Pool, dir wird die bewegte Bandbreite berechnet statt der berührten Adressen, und die Anzahl verschiedener IPs, die du am Ende nutzt, ist ein Ergebnis davon, wie du die Rotation konfigurierst, keine Menge, die du im Voraus kaufst. Dieser Wandel, ausführlicher im Beitrag darüber, warum die Pro-Port-Ära vorbei ist, ist der Grund, warum “wie viele IPs” auf nichts mehr abbildet, was du tatsächlich kaufst.

Es gibt einen zweiten Grund, warum die Rahmung in die Irre führt. Eine Zielwebsite sieht deinen Pool nicht. Sie sieht die Anfragen, die an ihrer eigenen Tür ankommen, und bildet sich pro Adresse eine Meinung danach, wie diese Anfragen sich verhalten. Zehntausend IPs retten keinen Job, der sein ganzes Volumen durch eine Handvoll davon schickt, und eine bescheidene Anzahl gut verteilter Adressen betreibt bequem einen Job, den ein naives Setup nicht könnte. Verteilung ist die Variable, nicht Bestand.

Was deinen Bedarf tatsächlich bestimmt

Vier Dinge entscheiden, was ein Job braucht. Arbeite sie der Reihe nach durch, und die Antwort fällt heraus.

Das erste ist deine Anfragerate pro Ziel. Nicht dein Gesamtvolumen über alles hinweg, sondern wie viele Anfragen du in einem gegebenen Fenster an eine einzelne Website schickst, denn Ratenlimits werden pro IP und pro Ziel durchgesetzt. Das zweite ist Nebenläufigkeit, also wie viele Anfragen du gleichzeitig unterwegs hast, was festlegt, wie viele Adressen gleichzeitig in Gebrauch sind. Das dritte sind Session-Anforderungen: ob deine Arbeit eine gehaltene IP für einen mehrstufigen Ablauf braucht, was der einzige Fall ist, der zu einer echten Zählung wird. Das vierte ist die geografische Streuung, denn ein Job über viele Märkte braucht sein Volumen über jeden dieser Märkte verteilt statt einen großen Pool, der anderswo konzentriert ist, und wo Stadt-Targeting im Spiel ist, lautet die relevante Frage Verfügbarkeit in dieser Stadt, nicht Größe des Netzwerks insgesamt.

Die grobe Rechnung für rotierende Arbeit

Für gewöhnliche rotierende Sammlung ist die nützliche Rechnung nicht “wie viele IPs existieren”, sondern “über wie viele verschiedene Adressen muss mein Volumen verteilt sein, um an jedem Ziel höflich zu bleiben”.

Nimm deine Anfragerate an eine einzelne Website und teile sie durch die Rate, die du von einer einzelnen Adresse zu senden bereit bist. Wenn ein Job 60.000 Anfragen pro Stunde an ein Ziel schickt und du willst, dass keine Adresse mehr als etwa eine Anfrage alle 20 Sekunden an dieses Ziel sendet, also 180 pro Stunde, dann muss dieses Volumen zu jedem gegebenen Zeitpunkt über in der Größenordnung von 330 verschiedene Adressen verteilt sein. Ändere einen der Eingabewerte und die Antwort verschiebt sich: halbiere das Volumen und du brauchst halb so viele, verlangsame jede Adresse und du brauchst mehr. Die Zahlen hier sind illustrativ, da jedes Ziel eine andere Rate toleriert und du auf das abstimmen solltest, was eine konkrete Website tatsächlich akzeptiert, aber die Form der Rechnung ist der Punkt. Du löst nach Verteilung, und der Pool muss lediglich groß genug und in deinen Zielmärkten gut genug verteilt sein, um sie zu liefern.

Genau das erledigt Lastverteilung für dich, und deshalb zählen unbegrenzte gleichzeitige Verbindungen mehr als eine IP-Zahl in der Überschrift: die Beschränkung, die beißt, ist, wie viele Anfragen eine Adresse an eine Website schickt, nicht wie viele Adressen es insgesamt gibt. Wenn du viele verschiedene Ziele ansprichst, gilt die Rechnung pro Ziel, und Volumen über fünfzig Websites verteilt ist weit weniger anspruchsvoll als dasselbe Volumen auf eine gerichtet.

Der Fall, in dem du wirklich zählst: Sticky-Sessions

Es gibt eine Situation, in der eine Zahl tatsächlich die richtige Antwort ist, und es lohnt sich, darüber präzise zu sein. Wenn deine Arbeit eine gehaltene Identität braucht, eine mehrstufige Suche, einen Login-Ablauf, eine Checkout-artige Sequenz, oder irgendeinen Prozess, bei dem eine Website Zustand über Anfragen hinweg verfolgt, braucht jeder dieser gleichzeitigen Abläufe seine eigene Sticky-Session auf seiner eigenen IP, solange der Ablauf dauert. Hier ist die Zählung direkt: fünfzig gleichzeitige Sessions bedeuten fünfzig gehaltene Adressen in diesem Moment, und fünfhundert bedeuten fünfhundert.

Die ehrliche Version der Frage lautet also nicht “wie viele IPs brauche ich”, sondern “wie viele gleichzeitige Sticky-Sessions brauche ich”, was eine Frage nach der Form deiner Arbeitslast ist statt nach dem Netzwerk. Alles, was keine gehaltene Identität verlangt, sollte rotieren, denn Rotation verteilt die Last automatisch und ist die Art, wie das Rotationsmodell genutzt werden soll.

Warum die rohe Poolgröße eine schwache Vergleichsmetrik ist

Anbieter werben mit Poolgrößen, und die Zahlen sind groß genug, um schwer sinnvoll vergleichbar zu sein. Drei Dinge zählen mehr als die Zahl in der Überschrift.

Verteilung in deinen Märkten kommt zuerst. Ein sehr großer Pool, der in dem Land oder der Stadt dünn ist, die du tatsächlich brauchst, ist für deinen Job schlechter als ein kleineres Netzwerk, das dort dicht ist, also ist die einzige Poolgröße, die zählt, die dort verfügbare, wo du sammelst. Qualität kommt als zweites, denn markierte oder übernutzte Adressen ziehen Challenges und verzerrte Antworten an, egal wie viele es davon gibt, weshalb die IP-Reputation deine Erfolgsrate direkter beeinflusst als Volumen, und weshalb es hilft zu verstehen, was eine Residential-IP eigentlich ist. Gleichzeitige Verfügbarkeit kommt als drittes: was in dem Moment nutzbar ist, in dem du Verkehr sendest, zählt, nicht eine kumulierte Zählung jeder Adresse, die das Netzwerk je gesehen hat.

Die praktische Konsequenz ist, dass du einen Anbieter nicht nach Poolgröße wählen solltest. Lass deine eigene Arbeitslast gegen einen kleinen Kauf laufen und miss sie, wofür die Anleitung zum Testen von Geschwindigkeit, Erfolgsrate und Standortgenauigkeit da ist.

Was du stattdessen dimensionierst: Bandbreite

Da dir bewegte Daten statt genutzter Adressen berechnet werden, ist die Zahl, die zu prognostizieren sich lohnt, die Bandbreite. Schätze die Seiten- oder Antwortgröße deiner Ziele, multipliziere mit dem Volumen, das du sammeln willst, und du hast eine Zahl, die auf das abbildet, was du tatsächlich zahlst, was der Ansatz im Beitrag zum Schätzen der monatlichen Bandbreite ist. Das macht auch den größten Kostenhebel offensichtlich, und er ist nicht die Anzahl der IPs: nur das abzurufen, was du brauchst, statt ganzer gerenderter Seiten, ist, wo die Ersparnis liegt, wie im Beitrag zum Senken der Proxy-Bandbreitenkosten behandelt.

Die Konfiguration

Beide Modi kommen vom selben Gateway, und der Unterschied ist ein Feld im Benutzernamen. Lass eine Session-Kennung weg, und jede Anfrage rotiert, was die meiste Sammlung tun sollte:

import requests

# Rotating: every request exits through a different address
ROTATING = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
r = requests.get("https://example.com/page",
                 proxies={"http": ROTATING, "https": ROTATING}, timeout=15)

# Sticky: one held IP per concurrent flow, counted per session
def sticky(session_id):
    url = (f"http://customer-USERNAME-country-us-sid-{session_id}:"
           f"PASSWORD@p.shifter.io:443")
    return {"http": url, "https": url}

# 50 concurrent flows means 50 distinct session identifiers
for i in range(50):
    proxies = sticky(f"flow{i}")
    # run one multi-step sequence on this held address

Rotiere standardmäßig, halte eine Session nur dort, wo ein Ablauf wirklich eine braucht, und lass den Pool die Verteilung erledigen, statt selbst eine feste Adressliste verwalten zu wollen.

Die Antwort validieren

Welche Zahl du auch erreichst, sie ist eine Ausgangshypothese, und die einzig verlässliche Bestätigung ist Messung. Beobachte die Erfolgsrate pro Ziel und pro Region, denn ein Rückgang ist das Signal, dass deine Rate pro Adresse für diese Website zu aggressiv ist, lange bevor daraus eine Datenlücke wird, was dir das Überwachen der Pipeline liefert. Wenn eine Route sich verschlechtert, hält Failover den Job am Laufen, während du nachjustierst. Und wenn du Blockaden siehst, ist der Fix häufiger Tempo und Anfragehygiene als mehr Adressen, was der Kern des Beitrags zum Vermeiden von Blockaden ist.

Eine kurze Checkliste

Wie viele Anfragen pro Stunde an dein einzelnes verkehrsreichstes Ziel? Das, geteilt durch die Rate pro Adresse, die dieses Ziel toleriert, ist ungefähr die Verteilung, die du brauchst.
Wie viele gleichzeitige Abläufe brauchen eine gehaltene Identität? Das ist deine Sticky-Session-Zahl, und sie ist die eine Zahl, die zu nennen sich lohnt.
Welche Länder und Städte brauchst du, und ist der Pool an diesen Orten dicht statt bloß insgesamt groß?
Wie viele Daten wirst du bewegen? Das ist die Zahl, die die Kosten bestimmt.
Hast du die Erfolgsrate an deiner eigenen Arbeitslast gemessen, statt einer Zahl aus der Überschrift zu vertrauen?

Fazit

“Wie viele IPs brauche ich” ist eine Frage, geerbt aus einem Preismodell, das nicht mehr gilt. In einem modernen, bandbreitenbepreisten Residential-Netzwerk kaufst du keine Anzahl von Adressen, du kaufst Zugang zu einem Pool und zahlst für die Daten, die du hindurchbewegst, also ist das, wofür du entwirfst, Verteilung: genug Streuung, dass kein einzelnes Ziel je mehr als gewöhnlichen Verkehr von irgendeiner Adresse sieht. Rotiere für Volumen, zähle nur deine gleichzeitigen Sticky-Sessions, beurteile ein Netzwerk nach seiner Dichte in den Märkten, aus denen du tatsächlich sammelst, und nach der Erfolgsrate, die es bei deiner eigenen Arbeitslast liefert, und dimensioniere dein Budget in Bandbreite statt in Adressen. Bring die Verteilung in Ordnung, und die IP-Zahl hört auf, etwas zu sein, worüber du nachdenken musst.

Genau das sollen Residential-Proxys bereitstellen, ein großer Pool echter IPs auf Haushaltsebene mit Länder- und Stadt-Targeting, Rotation als Standard, und Sticky-Sessions für die Abläufe, die sie brauchen. Die Abrechnung pro GB ist die Zahl, um die herum zu planen sich lohnt, denn du zahlst für die Daten, die du tatsächlich ziehst, statt für eine Menge Adressen, von der du hoffst, dass sie reicht.