Ein kostenloses Testkontingent ist eine kleine, feste Menge an Bandbreite, und wie man sie einsetzt, entscheidet darüber, ob man dabei etwas lernt. Der übliche Ansatz besteht darin, es auf einen Test-Endpunkt zu richten, der eine IP-Adresse zurückgibt, zu bestätigen, dass sich die Adresse ändert, und daraus zu schließen, dass die Proxys funktionieren. Das sagt einem fast nichts von dem, was man wissen musste, und ist der Grund, warum Leute am Ende einen Plan kaufen, der sie bei den Seiten enttäuscht, auf die es ihnen tatsächlich ankommt.
Ein Testkontingent existiert, um eine Frage zu beantworten: Wird das bei meinen Zielen, in meinem Volumen, in meinen Märkten funktionieren? Alles Folgende ist so geordnet, dass die wertvollsten Antworten zuerst kommen, falls einem die Bandbreite ausgeht, bevor die Neugier endet.
Bevor Sie beginnen: Bereiten Sie sich vor, damit Sie es nicht verschwenden
Zwei Minuten Vorbereitung verändern den Wert eines Testkontingents.
Notieren Sie sich Ihre echten Ziele, die tatsächlichen Seiten oder Endpunkte, von denen Ihr Projekt abhängt, und beziehen Sie das schwierigste ein statt nur die einfachen. Notieren Sie sich Ihre echten Märkte, die konkreten Länder und, falls relevant, Städte, die Sie brauchen. Und legen Sie im Voraus fest, wie ein Bestehen aussieht, zum Beispiel neunzig Prozent gültige Antworten auf Ihrem primären Ziel aus zwei Ländern, denn eine im Vorfeld festgelegte Schwelle verhindert, dass Sie ein mittelmäßiges Ergebnis im Nachhinein schönreden.
Richten Sie dann die Antwortvalidierung ein, bevor Sie die erste Anfrage stellen. Dies ist der wichtigste Vorbereitungsschritt überhaupt, denn eine Challenge-Seite, ein leeres Ergebnis, eine abgeschnittene Auflistung oder eine Weiterleitung auf eine generische Seite kommt oft mit einem 200-Status an, und ein Test, der Statuscodes zählt, meldet Erfolg, während er nichts sammelt. Prüfen Sie auf einen Marker, der nur auf einer wirklich guten Seite erscheint: ein erwartetes Element, eine plausible Inhaltslänge, ein bekanntes Feld im JSON. Die Fehlermodi sind katalogisiert in detecting blocked or fake content.
import requests
PROXY = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
PROXIES = {"http": PROXY, "https": PROXY}
def is_valid(html):
return "product-price" in html and len(html) > 20_000 # your own marker
ok = 0
for i in range(100): # a small, honest sample
r = requests.get("https://your-real-target.example/item/123",
proxies=PROXIES, timeout=20)
if r.status_code == 200 and is_valid(r.text):
ok += 1
print(f"validated success rate: {ok}%") # not "did it return 200"Test eins: Erfolgsrate bei Ihren eigenen Zielen
Dies ist der Test, der mehr zählt als alle anderen zusammen, und er sollte den Großteil Ihres Testkontingents verbrauchen.
Führen Sie eine aussagekräftige Stichprobe durch, etwa hundert Anfragen, gegen jedes echte Ziel, und messen Sie die validierte Erfolgsrate statt der HTTP-Erfolgsrate. Beziehen Sie Ihr am stärksten geschütztes Ziel ein, denn ein Pool, der die einfachen Seiten bewältigt und bei der schwierigen versagt, ist kein Pool, der Ihr Problem löst. Wenn Sie ein bestehendes Setup haben, führen Sie dieselbe Stichprobe zur Kontrolle damit durch, damit Sie vergleichen statt raten.
Achten Sie auf das Muster, bei dem der Erfolg hoch beginnt und im Verlauf abnimmt, denn das bedeutet üblicherweise, dass Ihr Tempo für das Ziel zu aggressiv ist, statt dass der Pool schlecht ist, und das ist eine Lektion über Tempo, die man besser während eines Testkontingents lernt als in der Produktion.
Test zwei: Geografische Genauigkeit
Wenn Ihr Projekt vom Standort abhängt, und das tun die meisten, prüfen Sie, ob das angeforderte Land auch das erhaltene Land ist, und kontrollieren Sie jeden Markt, den Sie tatsächlich brauchen, statt nur ein bequemes Beispiel. Ein Pool kann in einer Region hervorragend und in einer anderen dünn sein, und die globale Zahl auf einer Marketing-Seite sagt nichts über den konkreten Ort aus, von dem aus Sie sammeln.
Zwei Ebenen lohnt es sich zu prüfen. Erstens, ob sich die Exit-Adresse dem angeforderten Land zuordnen lässt, geprüft über genügend Anfragen, um Unstimmigkeiten zu erkennen. Zweitens, und bedeutsamer, ob sich die Zielseite so verhält, als wären Sie dort: korrekte Währung, lokale Preise, regionaler Katalog, lokale Suchergebnisse. Der zweite Test ist der eigentliche, denn IP-Geolokalisierungsdatenbanken und die Meinung des Ziels stimmen nicht immer überein, und es ist die Meinung des Ziels, für die Sie bezahlen. Wenn Sie city-level targeting benötigen, prüfen Sie es auf Stadtebene, statt anzunehmen, dass Ländergenauigkeit dies impliziert.
Test drei: Ist der Pool das, was er verspricht
Verwenden Sie etwas Bandbreite darauf, Exit-Adressen zu erfassen und sie nach der Organisation zu gruppieren, zu der sie gehören. Anbieter für Verbraucherinternet sind das, was Sie sehen möchten; ein bedeutender Anteil an Hosting- oder Cloud-Organisationen zeigt, dass der Pool mit Rechenzentrums-Adressen verdünnt ist, was von Bedeutung ist, weil diese Adressen genau diejenigen sind, die Ihre Ziele als maschinellen Traffic behandeln werden. Die vollständige Methode findet sich in spotting datacenter IPs sold as residential, und die zugrunde liegende Unterscheidung in the anatomy of a residential IP.
Beachten Sie dabei, dass Adressqualität eine eigene Achse gegenüber dem Adresstyp ist: ein wirklich residentieller Pool, der bis zu einem schlechten Ruf missbraucht wurde, wird trotzdem Challenges auslösen, was genau das ist, was Test eins von außen misst.
Test vier: Sitzungsverhalten
Wenn irgendein Teil Ihres Projekts einen mehrstufigen Ablauf beinhaltet, eine Suche mit Seitenwechsel, einen Login, einen Standortkontext, den Sie setzen und dann auslesen, bestätigen Sie während des Testkontingents zwei Dinge.
Bestätigen Sie, dass die Rotation tatsächlich rotiert, wenn Sie keine Sitzung angeben, und bestätigen Sie, dass eine sticky session tatsächlich eine Adresse für die benötigte Dauer hält. Führen Sie dann eine Ihrer echten mehrstufigen Abfolgen end-to-end auf einer gehaltenen Sitzung aus, denn ein Pool kann bei Einzelanfragen gut aussehen und trotzdem einen Ablauf brechen, wenn sich die Adresse darunter ändert. Wenn Ihre Arbeit viele gleichzeitig gehaltene Identitäten erfordert, prüfen Sie, ob gleichzeitige Sitzungen unabhängig voneinander funktionieren.
Test fünf: Leistung und Verbrauch
Zwei Zahlen sollten Sie festhalten, beide beeinflussen den Plan, den Sie am Ende kaufen.
Latenz und Durchsatz sind wichtig, wenn Ihre Arbeit zeitkritisch ist, also messen Sie Antwortzeiten über den Proxy an Ihren echten Zielen statt an einem Speedtest-Endpunkt, und erwarten Sie, dass residentielle Verbindungen langsamer sind als eine direkte Verbindung, da der Traffic einen längeren Weg nimmt. Entscheidend ist, ob es für Ihre Aufgabe schnell genug ist, nicht ob es einem Rechenzentrums-Benchmark entspricht. Der Messansatz findet sich in testing speed, success rate, and location accuracy.
Messen Sie dann Bytes pro Anfrage, die Zahl, die aus einer Planschätzung eine Planentscheidung macht. Multiplizieren Sie Ihren gemessenen Durchschnitt mit Ihrem erwarteten monatlichen Anfragevolumen, und Sie haben eine reale Bandbreitenzahl statt einer Schätzung, die die Eingabe für estimating monthly bandwidth ist. Wenn das Ergebnis unangenehm ist, ist dies auch der Moment, um zu entdecken, dass das Abrufen eines Daten-Endpunkts statt des Renderns vollständiger Seiten Sie in eine niedrigere Stufe versetzt, wie in cutting proxy bandwidth costs beschrieben.
Wofür Sie kein Testkontingent verwenden sollten
Ein paar Dinge verbrauchen Bandbreite, ohne Ihnen etwas beizubringen.
Das Testen gegen einen IP-Echo-Endpunkt beweist, dass der Proxy verbunden ist, was ein Sanity-Check von dreißig Sekunden ist, keine Bewertung. Das Testen nur einfacher Ziele schmeichelt dem Pool und verbirgt die Antwort, die Sie brauchten. Das Durchführen enormer Volumina über ein einziges Ziel misst keine Qualität und kann dazu führen, dass diese Adresse gesperrt wird, was den Pool dann schlechter aussehen lässt, als er ist. Und ein Urteil auf Basis einer Handvoll Anfragen liefert Rauschen, denn eine Stichprobe von fünf Anfragen kann einen Pool mit fünfundneunzig Prozent nicht von einem mit siebzig Prozent unterscheiden.
Noch etwas: Bewerten Sie einen Anbieter nicht anhand von Behauptungen zur Poolgröße. Eine Schlagzeilenzahl ist nichts, was ein Testkontingent verifizieren kann, und sie bestimmt nicht Ihre Ergebnisse. Dichte in Ihren Ländern und Erfolg bei Ihren Zielen tun das.
Eine Checkliste für das Testkontingent
- Vorbereiten: echte Ziele einschließlich des schwierigsten, echte Märkte, eine Bestehensschwelle und Antwortvalidierung, die vor der ersten Anfrage festgelegt wurde.
- Validierte Erfolgsrate messen, ungefähr hundert Anfragen pro Ziel, mit Kontrolle, falls vorhanden.
- Geografie für jeden benötigten Markt prüfen, sowohl Exit-Standort als auch Zielverhalten.
- Exit-Organisationen stichprobenartig prüfen, um zu bestätigen, dass der Pool wirklich residentiell ist.
- Einen echten mehrstufigen Ablauf auf einer sticky session durchspielen und Rotation ohne eine solche bestätigen.
- Latenz und Bytes pro Anfrage festhalten, dann Ihren Plan anhand gemessener Zahlen dimensionieren.
Wenn ein Testkontingent alle sechs Punkte bei Ihren eigenen Zielen besteht, wird die Planentscheidung zur Rechenaufgabe statt zum Vertrauensvorschuss. Die vollständige Sammlung von Entscheidungen auf Planebene findet sich in choosing the right residential proxy plan.
Fazit
Ein Testkontingent ist Bandbreite, und Bandbreite, die für einen IP-Echo-Endpunkt aufgewendet wird, beantwortet eine Frage, die Sie nicht hatten. Verwenden Sie sie für Ihre echten Ziele mit echter Antwortvalidierung, prüfen Sie die Märkte, die Sie tatsächlich brauchen, kontrollieren Sie, ob der Pool wirklich residentiell ist, spielen Sie einen Sitzungsablauf durch, wenn Ihre Arbeit einen solchen hat, und halten Sie Bytes pro Anfrage fest, damit Ihr Plan anhand von Messungen dimensioniert wird. Legen Sie die Bestehensschwelle fest, bevor Sie beginnen. Tun Sie das, und Sie beenden das Testkontingent mit dem Wissen, ob das Produkt Ihr Problem löst, was das Einzige ist, wofür ein Testkontingent gedacht ist.
Wenn Sie diese Checkliste durchführen möchten, können Sie das mit einem free trial of Shifter residential proxies tun, mit Länder- und Städte-Targeting, standardmäßiger Rotation und sticky sessions für die Abläufe, die sie benötigen. Wenn die Zahlen vorliegen, sorgt per-GB pricing dafür, dass der von Ihnen gewählte Plan der gemessenen Bandbreite folgt statt einer Schätzung.