Residential-Proxy-IP rotiert nicht? Ursachen und Lösungen

Meist rotiert der Proxy einwandfrei, und Ihr HTTP-Client verwendet lediglich eine Verbindung wieder. So erkennen Sie den Unterschied, und das sind die sechs Ursachen, die es zu prüfen gilt.

Sie haben einen rotierenden Proxy konfiguriert, senden zehn Anfragen, und jede einzelne meldet dieselbe Exit-Adresse. Die naheliegende Schlussfolgerung ist, dass die Rotation defekt ist. Das ist sie in der Regel nicht. In den meisten Fällen vergibt das Gateway genau wie gewünscht neue Adressen, und irgendetwas zwischen Ihrem Code und dem Gateway verhindert, dass das ankommt. Der häufigste Übeltäter ist dabei eine Funktion Ihres HTTP-Clients, die eigentlich existiert, um Dinge schneller zu machen.

Hier sind die Ursachen in der Reihenfolge, in der es sich lohnt, sie zu prüfen, jeweils mit der passenden Lösung.

Zuerst: richtig prüfen

Stellen Sie vor der Diagnose sicher, dass der Test selbst korrekt ist. Eine einzelne Kommandozeilen-Anfrage pro Aufruf ist die sauberste Prüfung, da jeder Durchlauf ein eigener Prozess ohne gemeinsamen Zustand ist:

for i in 1 2 3 4 5; do
  curl -s -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json \
    | python3 -c "import sys,json; print(json.load(sys.stdin)['ip'])"
done

Fünf verschiedene Adressen bedeuten, dass die Rotation funktioniert und Ihre Anwendung das Problem ist. Fünf identische bedeuten, dass die Konfiguration das Problem ist. Diese eine Unterscheidung spart den größten Teil der Debugging-Zeit, führen Sie den Test also zuerst aus.

Ursache eins: eine Session-Kennung im Benutzernamen

Die einfachste Erklärung. Wenn Ihr Benutzername ein sid-Flag enthält, haben Sie explizit eine feste Session angefordert, und das Halten der Adresse ist dann korrektes Verhalten, kein Fehler.

customer-USERNAME-country-us-sid-abc123    # sticky: gleiche IP, so gewollt
customer-USERNAME-country-us               # rotating: neue IP pro Anfrage

Das erwischt Leute, die ein Beispiel aus der Dokumentation kopiert haben, oder die den Benutzernamen mit einem Helfer erzeugt haben, der standardmäßig eine Session hinzufügt. Entfernen Sie das sid-Flag, und mit ihm das ttl, da TTL nur zusammen mit einer Session sinnvoll ist. Die Semantik dazu steht unter sticky versus rotating und in den Sessions-Docs.

Eine subtilere Variante: Ihre Session-Kennung ist konstant, obwohl sie variieren sollte. Wenn Sie eine pro Job generieren, der Job aber viele Anfragen ausführt, teilen sich alle Anfragen dieses Jobs eine Adresse, was korrekt ist, aber möglicherweise nicht Ihrer Absicht entspricht.

Ursache zwei: Verbindungswiederverwendung, die alle erwischt

Das ist meistens die Antwort, wenn die curl-Schleife oben rotiert, Ihr Code aber nicht.

Moderne HTTP-Clients halten Verbindungen offen und verwenden sie wieder, weil das Öffnen einer neuen TCP- und TLS-Verbindung für jede Anfrage langsam ist. Wenn Ihr Client einen bestehenden Tunnel zum Proxy wiederverwendet, läuft die Anfrage durch die bereits bestehende Verbindung, und diese Verbindung hat bereits eine Exit-Adresse zugeordnet. Rotation erfolgt pro Verbindung, nicht pro Anfrage, die über eine bestehende Verbindung geschickt wird. Ein Session-Objekt, das einen Connection-Pool vorhält, schickt daher zuverlässig jede Anfrage durch denselben Exit.

Die Lösung hängt davon ab, wie viel Kontrolle Sie wollen. Entweder deaktivieren Sie Keep-Alive, erzwingen eine neue Verbindung pro Anfrage, oder lassen jede logische Anfrage einen frischen Client verwenden.

import requests

PROXY = "http://customer-USERNAME:PASSWORD@p.shifter.io:443"
PROXIES = {"http": PROXY, "https": PROXY}

# Verwendet eine Verbindung wieder: gleiche Exit-Adresse bei jeder Anfrage
s = requests.Session()
for _ in range(5):
    print(s.get("https://ipinfo.io/json", proxies=PROXIES).json()["ip"])

# Neue Verbindung pro Anfrage: rotiert wie erwartet
for _ in range(5):
    r = requests.get("https://ipinfo.io/json", proxies=PROXIES,
                     headers={"Connection": "close"}, timeout=20)
    print(r.json()["ip"])

Dasselbe gilt anderswo: ein http.Agent mit Keep-Alive in Node, ein gemeinsam genutzter HttpClient in .NET oder Java, ein Connection-Pool in Go. Wenn Ihre Sprache einen Standard-Client mit Connection-Pooling hat, und das haben sie alle, ist das im Anwendungscode die erste Stelle, die Sie prüfen sollten.

Es lohnt sich, das klar zu sagen: Das ist eher ein Kompromiss als ein Fehler. Verbindungswiederverwendung ist schneller und günstiger. Wenn Ihre Arbeit tatsächlich eine neue Adresse pro Anfrage will, zahlen Sie dafür mit einer neuen Verbindung jedes Mal; wenn nicht, ist Wiederverwendung in Ordnung und oft sogar vorzuziehen.

Ursache drei: Sie prüfen zu schnell, oder der Pool ist kleiner als gedacht für diesen Filter

Zwei zusammenhängende Effekte.

Wenn Sie den Filter eng gefasst haben, auf eine kleine Stadt oder ein bestimmtes ASN, ist die Menge der Adressen, die Sie bedienen können, viel kleiner als der Pool insgesamt, sodass dieselbe Adresse legitim häufiger wieder auftaucht. Das ist kein Fehler, das ist Arithmetik. Erweitern Sie den Filter, und die Wiederholung verschwindet.

Denken Sie auch daran, dass ein Residential-Pool aus echten Verbindungen besteht, die kommen und gehen, sodass eine Adresse zweimal über viele Anfragen hinweg zu sehen erwartet ist, nicht verdächtig. Rotation bedeutet, dass die nächste Anfrage unabhängig ausgewählt wird, nicht dass eine Adresse niemals wieder auftreten kann. Wenn Sie für eine Aufgabe garantierte Verschiedenheit brauchen, ist das ein Design-Constraint, das Sie in Ihrem eigenen Code handhaben müssen.

Ursache vier: etwas weiter oben im Stack cached

Wenn Sie über einen Browser, eine Erweiterung, eine systemweite Proxy-Einstellung oder ein Firmennetzwerk testen, geht die Anfrage möglicherweise nicht dorthin, wo Sie es erwarten. Browser insbesondere halten Verbindungen aggressiv offen und verwenden sie über Tabs hinweg wieder, sodass ein Browser die schlechteste Umgebung ist, um Rotation zu verifizieren. Testen Sie zuerst von der Kommandozeile, dann in Ihrer Anwendung, und erst danach in einem Browser.

Ebenso: Wenn Ihr Code sowohl Proxy-Umgebungsvariablen setzt als auch die Konfiguration explizit übergibt, überschreibt möglicherweise eine die andere und schickt den Traffic durch etwas anderes als das von Ihnen konfigurierte Gateway.

Ursache fünf: die Adresse ist gleich, aber die Anfrage hat den Proxy nie verlassen

Eine banale, die es wert ist, ausgeschlossen zu werden: Wenn der Proxy tatsächlich nicht verwendet wird, meldet jede Anfrage dieselbe Adresse, nämlich Ihre eigene. Bestätigen Sie, dass die Adresse, die Sie sehen, nicht die Adresse Ihres eigenen Servers ist. Wenn doch, wird die Proxy-Konfiguration überhaupt nicht angewendet, was ein anderes Problem ist, meist ein fehlender https-Eintrag neben dem http-Eintrag, oder ein Client, der die Proxy-Einstellung für das verwendete Schema ignoriert.

Ursache sechs: eine feste Session, die noch nicht abgelaufen ist

Wenn Sie absichtlich feste Sessions verwenden und erwarten, dass diese nach einer Weile rotieren: Die Adresse hält, bis die TTL abläuft. Die Standardlebensdauer beträgt 120 Sekunden, sofern Sie ttl nicht explizit setzen. Wenn Sie eher eine neue Adresse wollen, ändern Sie die Session-Kennung, statt zu warten, da eine neue Kennung eine neue Session bedeutet.

Beachten Sie auch, dass eine feste Adresse früher als ihre TTL wegfallen kann, wenn die zugrunde liegende Verbindung verschwindet, da es sich um echte Heimverbindungen handelt und nicht um dedizierte Infrastruktur. Sticky bedeutet bestmögliche Bemühung für die angeforderte Dauer, keine Garantie.

Ein schneller Entscheidungspfad

Führen Sie die curl-Schleife aus. Wenn sie rotiert, Ihr Code aber nicht, haben Sie ein Problem mit Verbindungswiederverwendung, das ist Ursache zwei. Wenn keines von beidem rotiert, prüfen Sie den Benutzernamen auf ein sid-Flag, bestätigen Sie dann, dass Sie nicht Ihre eigene Adresse sehen, und erweitern Sie anschließend jeden zu engen Geo-Filter. Wenn die Rotation seltener erfolgt, als Sie möchten, aber trotzdem rotiert, betrachten Sie die Poolgröße für diesen Filter statt eines Fehlers.

Für alles Weitere ist das umgebende Verhalten dokumentiert unter wie Rotation funktioniert, und wenn Anfragen fehlschlagen statt sich zu wiederholen, decken warum Anfragen einen Timeout haben und 407-Fehler beheben die beiden häufigsten Fehlerbilder ab.

Das Fazit

Rotationsprobleme sind meist keine Rotationsprobleme. Testen Sie zuerst mit getrennten Prozessen, um festzustellen, ob das Gateway überhaupt rotiert, und wenn ja, schauen Sie sich Ihren HTTP-Client an, denn Verbindungswiederverwendung ist der mit Abstand häufigste Grund: Anfragen, die durch einen bereits offenen Tunnel geschickt werden, behalten die Exit-Adresse, die dieser Tunnel bereits hat. Danach prüfen Sie auf ein verirrtes sid-Flag, bestätigen, dass Sie nicht Ihre eigene Adresse sehen, und denken daran, dass ein sehr enger Geo-Filter aus einer viel kleineren Menge schöpft, sodass Wiederholungen normal sind. Feste Sessions, die ihre Adresse halten, arbeiten wie vorgesehen, und das Ändern der Kennung gibt Ihnen sofort eine neue.

Das Rotationsmodell selbst und die Flags, die es steuern, finden sich im Residential-Proxy-Netzwerk, wo das Session-Verhalten ein Parameter pro Anfrage ist statt einer Tarif-Einstellung, abgerechnet pro GB, unabhängig davon, wie oft Sie rotieren.