Residential-Proxys

Residential Proxy IP-Pools: Wie Anbieter sie aufbauen und aktualisieren

Ein Pool ist kein Bestand, sondern eine Population, die sich ständig verändert. Hier wird erklärt, wie er zusammengestellt wird, warum er sich verändert und was das für Ihre Aufgaben bedeutet.

Chris Collins

Chris Collins

30. August 2026 · 7 Min. Lesezeit

Die meisten Beschreibungen eines Pools an Residential Proxys lassen ihn wie ein Lager klingen: eine große Zahl von Adressen, die auf einem Regal liegen und darauf warten, vergeben zu werden. Dieses Modell ist auf eine Weise falsch, die zu echten operativen Überraschungen führt, denn ein Pool ist kein Bestand. Er ist eine Population echter Haushaltsverbindungen, die fortlaufend hinzukommen und wieder verschwinden, und fast alles, was fortgeschrittene Teams am Verhalten von Pools verwirrt, folgt aus genau dieser einen Tatsache.

Hier ist, wie ein Pool tatsächlich zusammengestellt wird, was Refresh mechanisch bedeutet, und die Konsequenzen, auf die Sie Ihr Design ausrichten sollten.

Wie ein Pool aufgebaut wird

Die Adressen in einem Residential-Pool gehören zu den Heiminternetverbindungen echter Menschen, was bedeutet, dass ein Anbieter sie nicht einfach kaufen kann, so wie Datacenter-Bereiche gekauft werden. Sie müssen beigesteuert werden.

Der übliche Mechanismus ist die Teilnahme über Software. Eine Person installiert eine Anwendung, oder ein SDK, das in eine solche eingebettet ist, die im Gegenzug etwas bietet für das Teilen eines Teils ihrer Verbindung: eine werbefreie Stufe, eine kostenpflichtige Funktion, eine kleine Zahlung, Zugang zu einem Dienst. Wenn dieses Gerät online und ausreichend im Leerlauf ist, kann es eine Anfrage im Auftrag des Netzwerks übertragen. Der Anbieter pflegt Beziehungen zu den Entwicklern, die dieses SDK einbetten, und diese Beziehungen bestimmen die geografische und netzwerktechnische Form des Pools, weshalb zwei Anbieter mit ähnlichen Gesamtzahlen in einem bestimmten Land erheblich voneinander abweichen können. Die Ethik dieser Vereinbarung, und wie man sie überprüft, ist Thema von wie Anbieter ihre IPs ethisch beziehen.

Die Konsequenz, die es zu verinnerlichen gilt: Die Zusammensetzung des Pools hängt davon ab, welche Apps wo beliebt sind. Sie ist nicht gleichmäßig verteilt, nicht zentral geplant, und sie ändert sich, während diese Apps Nutzer gewinnen und verlieren.

Was „Refresh” tatsächlich bedeutet

Pools erneuern sich fortlaufend, aus Gründen, die nichts mit dem Anbieter zu tun haben.

Geräte gehen offline, wenn Menschen eine App schließen, ein Telefon in die Tasche stecken, das Haus verlassen oder schlafen gehen. Heimverbindungen erhalten neue Adressen, wenn Router neu starten oder die Lease eines ISPs abläuft, sodass derselbe Haushalt morgen als andere Adresse erscheinen kann. Teilnehmer scheiden aus. Neue kommen hinzu. Zusätzlich entfernen Anbieter selbst Adressen, die sich verschlechtert haben, sei es durch schlechte Reputation oder unzuverlässiges Verhalten.

Nichts davon ist ein Wartungsfenster. Es ist der stationäre Zustand, der fortlaufend im Hintergrund stattfindet, weshalb ein Residential-Pool besser als Strom denn als Bestand modelliert wird.

Poolgröße ist nicht Verfügbarkeit

Das ist der praktische Kern der Sache, und hier führen Schlagzeilenzahlen in die Irre.

Eine veröffentlichte Poolzahl ist üblicherweise kumulativ: Adressen, die das Netzwerk über einen bestimmten Zeitraum gesehen hat. Was Ihre Erfahrung bestimmt, ist die gleichzeitige Verfügbarkeit, also wie viele unterschiedliche Adressen Sie in diesem Moment bedienen können, im angeforderten Land, mit den von Ihnen angewendeten Filtern. Diese beiden Zahlen unterscheiden sich um Größenordnungen, und nur die zweite begrenzt Ihre Aufgabe.

Drei Dinge grenzen sie weiter ein. Geografie: Eine globale Zahl sagt nichts über Ihren Markt aus, was das Argument in Verfügbarkeit nach Ländern ist. Filter: Das Hinzufügen einer Stadt oder eines ASN verringert die zulässige Menge stark, da nur Adressen, die jedes Kriterium erfüllen, infrage kommen. Und Zeit: Weil der Pool der menschlichen Aktivität folgt, ist dasselbe Land am lokalen Abend tiefer als um vier Uhr morgens.

Das Ergebnis ist, dass „wie groß ist der Pool” auf sinnvolle Weise kaum zu beantworten ist, während „wie viele unterschiedliche Adressen bekomme ich tatsächlich für meinen Filter, bei meiner Nebenläufigkeit, zu der Stunde, zu der ich arbeite” in zwanzig Minuten messbar ist und die Zahl ist, die zählt.

Die fünf Verhaltensweisen, die Churn erklärt

Sobald man den Pool als Population statt als Bestand modelliert, wird eine Reihe von andernfalls rätselhaften Verhaltensweisen offensichtlich.

Sticky Sessions enden manchmal vorzeitig. Sie haben eine zehnminütige Sitzung angefordert, und sie dauerte vier, weil das zugrunde liegende Gerät offline gegangen ist. Eine Sticky Session ist ein bestmöglicher Versuch, eine Adresse für eine Dauer zu halten, kein Mietvertrag über Infrastruktur, und Code, der etwas anderes annimmt, bricht zeitweise. Behandeln Sie es als normales Ereignis: erkennen Sie die Änderung und starten Sie die Sequenz neu, statt es als Fehler zu behandeln, gemäß Sticky versus Rotating.

Dieselbe Adresse kommt wieder vor. Rotation wählt jedes Mal unabhängig aus, statt eine Liste ohne Wiederholung durchzugehen, sodass Wiederholungen zu erwarten sind, und sie werden häufig, wenn ein enger Filter die zulässige Menge verkleinert. Das ist Arithmetik und kein Fehler, und es ist eine der Ursachen, die in IP rotiert nicht behandelt werden.

Die Leistung variiert zwischen Adressen. Dies sind Endverbraucherverbindungen mit eigener Bandbreite, eigenen Staus und eigener Haushaltsnutzung, sodass die Latenz eine viel breitere Verteilung hat als Datacenter-Infrastruktur. Perzentile sind die ehrliche Art, dies zu beschreiben; Durchschnittswerte verbergen den Tail, der tatsächlich Ihren Zeitplan beeinflusst.

Die Verfügbarkeit bewegt sich im Tagesverlauf. Ein Job, der um 20:00 Uhr erfolgreich ist und um 04:00 Uhr im selben Markt Schwierigkeiten hat, sieht meist die tageszeitliche Pooltiefe und keine Zieländerung.

Ergebnisse unterscheiden sich zwischen zwei Durchläufen desselben Jobs. Andere Adressen, andere Netzwerke, andere Reputationen. Ein gewisses Maß an Varianz ist inhärent, und jede Schwankung als Regression zu behandeln, verschwendet viel Untersuchungsaufwand.

Design für eine Population

Praktische Konsequenzen für alle, die darauf aufbauen.

Behandeln Sie Adressen als verbrauchbar und Routen als die Einheit, die Sie verwalten. Sie haben nie eine Adresse gewählt und können sie nicht behalten, daher gehört die Zustandsüberwachung auf Routen- und Sitzungsebene, was das Modell in Überwachung der Proxy-Gesundheit im großen Maßstab und Aufbau eines Proxy-Managers ist.

Machen Sie Jobs fortsetzbar und idempotent. Wenn eine Sitzung mitten in einer Sequenz verschwinden kann, muss die Sequenz neu gestartet werden können, ohne Arbeit zu duplizieren oder einen Datensatz zu beschädigen.

Wählen Sie TTLs bewusst. Eine lange TTL ist eine Anfrage, keine Garantie, und um eine Stunde bei einer Endverbraucherverbindung zu bitten, setzt Sie Abbrüchen mitten im Ablauf aus. Fordern Sie das an, was der Ablauf tatsächlich braucht.

Messen Sie Ihren effektiven Pool, statt eine Marketingzahl zu lesen: nehmen Sie einige hundert Exits unter Ihrem tatsächlichen Filter als Stichprobe, zählen Sie unterschiedliche Adressen und Organisationen, und wiederholen Sie dies zu den Stunden, zu denen Sie arbeiten. Diese Zahl, nicht die Schlagzeile, sollte Entscheidungen zu Nebenläufigkeit und Verteilung beeinflussen, zusammen mit der Argumentation in wie viele Proxy-IPs Sie tatsächlich brauchen.

Und planen Sie mit Blick auf die Population, denn einen schweren Job für einen kleinen Markt während dessen Nachtstunden laufen zu lassen, bedeutet, ohne Grund gegen den Pool anzukämpfen.

Wie gutes Poolmanagement von außen aussieht

Sie können die internen Abläufe eines Anbieters nicht überprüfen, aber die Auswirkungen sind beobachtbar. Konsistente Erfolgsraten über die Stunden, zu denen Sie arbeiten, deuten darauf hin, dass der Pool in Ihren Märkten tief genug ist, statt nur in der Summe groß zu sein. Eine breite Streuung von ISP-Organisationen für Endverbraucher in Ihrer Exit-Stichprobe deutet auf echtes Residential-Angebot hin statt auf ein verwässertes, was die Prüfung in Erkennen von als Residential verkauften Datacenter-IPs ist. Eine Geolokalisierung, die dem entspricht, was Zielsysteme tatsächlich glauben, statt nur dem, was ein Lookup-Dienst meldet, deutet darauf hin, dass die geografische Kennzeichnung gepflegt wird. Und ein Anbieter, der seine Beschaffung ohne Unbehagen beschreiben kann, sagt Ihnen etwas darüber, wie der Pool generell verwaltet wird.

Das Fazit

Ein Residential-Pool ist eine Population, kein Bestand. Er wird durch Teilnahme zusammengestellt statt gekauft, seine Form folgt der Software, die Menschen tatsächlich nutzen, und er erneuert sich fortlaufend, während Geräte offline gehen, Adressen neu zugewiesen werden und Teilnehmer kommen und gehen. Diese eine Eigenschaft erklärt vorzeitig endende Sticky Sessions, wiederkehrende Adressen, stark variierende Latenz, im Tagesverlauf schwankende Verfügbarkeit und zwei identische Durchläufe mit unterschiedlichen Ergebnissen. Gestalten Sie dafür: Behandeln Sie Adressen als verbrauchbar, verfolgen Sie die Gesundheit pro Route, machen Sie Sequenzen fortsetzbar, wählen Sie TTLs, die zum Ablauf passen, und messen Sie Ihren effektiven Pool unter Ihren eigenen Filtern zu Ihren eigenen Stunden, statt einer Schlagzeilenzahl zu vertrauen, die etwas anderes beschreibt als das, was Sie tatsächlich begrenzt.

Dieser Pool ist die Grundlage für Residential Proxys, die 195 Länder abdecken mit Filtern nach Land, Region, Stadt und ASN, sowie Preisgestaltung pro GB, sodass das Messen Ihrer eigenen effektiven Verfügbarkeit nur die Bandbreite kostet, die der Test verbraucht.

Bereit, loszulegen?

Testen Sie Shifters Residential-Proxys, 205M+ IPs, 195+ Länder, ab $0.75/GB.

Jetzt starten