Residential-Proxy-Geschwindigkeit, Erfolgsrate und Standortgenauigkeit testen

“Wie schnell ist er?” ist die falsche erste Frage zu einem Residential Proxy. Ein Proxy, der in 200ms antwortet, aber die Hälfte der Zeit blockiert wird, ist nutzlos; ein etwas langsamerer, der jedes Mal die echte Seite zurückgibt, ist genau das, was Sie wollen. Bevor Sie einem Anbieter trauen oder debuggen, warum Ihr Scraper unterdurchschnittlich läuft, müssen Sie drei Dinge objektiv messen: Erfolgsrate, Latenzverteilung und Standortgenauigkeit. Dieser Leitfaden gibt Ihnen Copy-Paste-Tests für jedes und, ebenso wichtig, wie Sie die Zahlen lesen, ohne sich selbst zu täuschen.

Alles unten läuft gegen das Shifter Residential-Gateway (ein Endpunkt, p.shifter.io:443, Targeting im Benutzernamen kodiert), aber die Tests sind anbieterunabhängig, tauschen Sie Host und Zugangsdaten, und sie funktionieren überall. Die Beispiele sind Python; das Client-Setup spiegelt Residential Proxies mit Python.

Die drei Metriken, die wirklich zählen

Rohe Geschwindigkeit ist die Metrik, auf die sich Leute fixieren, und die am wenigsten nützliche in Isolation. Residential-IPs routen über echte Verbrauchergeräte, sind also inhärent etwas langsamer als Datacenter, das ist zu erwarten, und kein Defekt. Was tatsächlich bestimmt, ob ein Proxy für Ihren Job gut ist:

• Erfolgsrate — von den Anfragen, die Sie senden, wie viele die echte Seite zurückgeben (kein Block, CAPTCHA oder Fehler). Das ist die Zahl, die entscheidet, ob Ihre Datenpipeline vollständig ist.
• Latenzverteilung — nicht der Durchschnitt, die Streuung. Das p95 und der Tail sagen Ihnen, wie schlimm Ihre langsamen Anfragen werden, was im großen Maßstab wehtut.
• Standortgenauigkeit — wenn Sie ein Land oder eine Stadt anvisieren, löst die Exit-IP tatsächlich dorthin auf? Für jeden geo-getargeteten Anwendungsfall sind Daten vom falschen Standort still falsche Daten.

Messen Sie alle drei. Eine einzelne Zahl, besonders die Durchschnittsgeschwindigkeit, verbirgt die Probleme, die zählen.

Setup

Bewahren Sie Zugangsdaten in Umgebungsvariablen auf und definieren Sie einen Helper, der eine getargetete Proxy-URL baut:

import os, time, statistics, requests

USER = os.environ["SHIFTER_USER"]
PASS = os.environ["SHIFTER_PASS"]
GATEWAY = "p.shifter.io:443"

def proxy(country="us", city=None, sid=None, ttl=600):
    parts = [USER, "country", country]
    if city: parts += ["city", city]
    if sid:  parts += ["sid", sid, "ttl", str(ttl)]
    url = f"http://{'-'.join(parts)}:{PASS}@{GATEWAY}"
    return {"http": url, "https": url}

Prüfen Sie zuerst, dass Sie tatsächlich über den Proxy gehen, eine überraschende Zahl von “der Proxy ist langsam”-Meldungen ist Traffic, der nie die lokale Maschine verlassen hat:

r = requests.get("https://api.ipify.org?format=json", proxies=proxy("us"), timeout=30)
print(r.json())   # sollte eine Residential-IP sein, nicht Ihre eigene

Test 1: Standortgenauigkeit

Visieren Sie ein Land (und optional eine Stadt) an, fragen Sie einen Geo-IP-Endpunkt, wo die Exit-IP ist, und messen Sie die Trefferrate über viele Samples. Rotieren Sie jede Anfrage (kein sid), damit Sie den Pool sampeln, nicht eine IP:

def test_geo(country="us", n=50):
    hits = 0
    for _ in range(n):
        try:
            r = requests.get("http://ip-api.com/json", proxies=proxy(country), timeout=30)
            data = r.json()
            if data.get("countryCode", "").lower() == country.lower():
                hits += 1
        except requests.RequestException:
            pass
    print(f"{country}: {hits}/{n} = {hits/n:.0%} country-accurate")

test_geo("us")
test_geo("de")

Wie man es liest. Die Ländergenauigkeit sollte sehr hoch sein (denken Sie an die hohen 90er %). Die Stadtgenauigkeit ist inhärent unschärfer, Geo-IP-Datenbanken sind sich uneinig, zu welcher Stadt eine IP gehört, also kann ein “Miss” eine Datenbank-Uneinigkeit sein, kein Proxy, der Sie an den falschen Ort schickt. Zwei Vorbehalte, die Sie vor falschen Schlüssen bewahren: testen Sie die Stadtgenauigkeit nach Möglichkeit gegen dieselbe Geo-IP-Quelle, die Ihre Zielseite nutzt, und trauen Sie nie einem einzelnen Lookup-Anbieter als Ground Truth.

Test 2: Latenz, als Verteilung gemessen

Messen Sie die Gesamt-Anfragezeit über viele Samples und berichten Sie Perzentile, nicht den Mittelwert. Ein Durchschnitt glättet genau den langsamen Tail, der Ihnen im großen Maßstab wehtut:

def test_latency(country="us", n=50, url="https://api.ipify.org"):
    times = []
    for _ in range(n):
        start = time.perf_counter()
        try:
            requests.get(url, proxies=proxy(country), timeout=30).raise_for_status()
            times.append((time.perf_counter() - start) * 1000)  # ms
        except requests.RequestException:
            pass
    times.sort()
    p = lambda q: times[min(len(times)-1, int(q*len(times)))]
    print(f"n={len(times)}  p50={p(0.5):.0f}ms  p95={p(0.95):.0f}ms  max={times[-1]:.0f}ms")

test_latency("us")

Wie man es liest. Sehen Sie sich p50 gegen p95 an: eine enge Streuung (p95 nahe p50) bedeutet vorhersehbare Leistung; ein p95 vielfach über dem p50 bedeutet einen schweren Tail, der nebenläufige Worker ausbremst. Um den Proxy-Overhead von der Ziel-Langsamkeit zu trennen, führen Sie denselben Test gegen einen schnellen, neutralen Endpunkt (wie ein IP-Echo) und gegen Ihr echtes Ziel aus, die Differenz ist grob die Eigenlatenz des Ziels. Und vergleichen Sie das Residential-p50 nicht mit dem Datacenter-p50, als wären sie dasselbe Produkt; Residential fügt per Design einen Echtgeräte-Hop hinzu (siehe Residential vs Datacenter Proxies).

Test 3: Erfolgsrate, die wichtigste

Führen Sie Anfragen gegen Ihr echtes Ziel aus (Erfolg ist zielspezifisch) und klassifizieren Sie jedes Ergebnis. Die Falle hier ist, dem HTTP-Status zu trauen: ein 200 OK kann immer noch ein Soft Block sein, eine CAPTCHA- oder “Bitte verifizieren”-Seite, mit einem 200 ausgeliefert. Validieren Sie also den Inhalt, nicht nur den Code:

def looks_like_real_page(html):
    # Auf Ihr Ziel abstimmen: Vorhandensein des erwarteten Markups, Fehlen von Block-Markern.
    block_markers = ("captcha", "are you a robot", "access denied", "unusual traffic")
    low = html.lower()
    return len(html) > 1000 and not any(m in low for m in block_markers)

def test_success(url, country="us", n=100):
    ok, soft_block, errors = 0, 0, 0
    for _ in range(n):
        try:
            r = requests.get(url, proxies=proxy(country), timeout=30)
            if r.status_code == 200 and looks_like_real_page(r.text):
                ok += 1
            else:
                soft_block += 1        # 200-aber-Block, 403/429/503, usw.
        except requests.RequestException:
            errors += 1                # Timeouts, Verbindungsfehler
    print(f"success={ok/n:.0%}  blocked={soft_block/n:.0%}  errors={errors/n:.0%}")

test_success("https://your-target.example/page", country="us")

Wie man es liest. Die Erfolgsrate ist die Schlagzeilen-Metrik fürs Scrapen, es ist der Anteil der Anfragen, die nutzbare Daten zurückgaben. Teilen Sie Fehler in blockiert (das Ziel wies Sie ab) versus Fehler (Netzwerk/Timeout), denn sie haben unterschiedliche Lösungen: konsistente Blocks deuten auf IP-Qualität oder Anfrageverhalten hin (warum Scraper blockiert werden), während Fehler auf Timeouts oder zu enge Geo-Filter deuten. Beachten Sie, dass Rotation pro Anfrage und eine Retry-Schleife Ihre effektive Erfolgsrate erhöhen, messen Sie also sowohl die rohe (Single-Shot) als auch die mit-Retry, wenn Sie so in der Produktion laufen.

Alles zusammenfügen

Ein minimales Harness führt alle drei aus und druckt einen Report:

if __name__ == "__main__":
    for cc in ("us", "de", "gb"):
        print(f"\n== {cc.upper()} ==")
        test_geo(cc, n=50)
        test_latency(cc, n=50)
        test_success("https://your-target.example/page", country=cc, n=100)

Lesen Sie es in dieser Reihenfolge: Erfolgsrate zuerst (kommen die Daten überhaupt zurück?), dann der Latenz-Tail (hält er unter Nebenläufigkeit mit?), dann die Geo-Genauigkeit (sind es die richtigen Daten?). Ein Anbieter, der beim p50 gewinnt, aber bei der Erfolgsrate verliert, ist die falsche Wahl fürs Scrapen.

Häufige Fallstricke, die irreführende Zahlen erzeugen

• Die mittlere Latenz berichten. Nutzen Sie Perzentile, der Tail ist es, der nebenläufige Jobs bricht.
• Dem Status 200 trauen. Soft Blocks liefern 200 mit einer CAPTCHA-Seite. Validieren Sie den Inhalt.
• Zu kleine Samples. 5 Anfragen sagen Ihnen nichts; nutzen Sie genug (50 bis 100+), um die Verteilung und den Tail zu sehen.
• Falsche Geo-Ground-Truth. Verschiedene Geo-IP-Datenbanken sind sich uneinig, besonders auf Stadtebene. Testen Sie gegen die Quelle, die Ihr Ziel nutzt, und behandeln Sie die Stadtgenauigkeit als inhärent unschärfer als die des Landes.
• Residential mit Datacenter bei roher Geschwindigkeit vergleichen. Verschiedene Produkte; Residential tauscht etwas Latenz gegen Echtnutzer-Vertrauen und eine höhere Erfolgsrate bei verteidigten Zielen (welche Proxies besser fürs Scrapen sind).
• Nicht bestätigen, dass Sie auf dem Proxy sind. Verifizieren Sie, dass die Exit-IP sich änderte, bevor Sie irgendetwas benchmarken.

Ein Hinweis zum verantwortungsvollen Vorgehen

Benchmarken Sie gegen Endpunkte, die Sie treffen dürfen, öffentliche IP-Echo-Dienste für Geschwindigkeit und Geo, und Ihre eigenen autorisierten Ziele für die Erfolgsrate. Halten Sie die Sample-Größen vernünftig, bombardieren Sie keine Seite, um sie zu messen, und respektieren Sie Rate-Limits. Unsere Richtlinie zur akzeptablen Nutzung ist die maßgebliche Quelle dafür, was auf Shifter erlaubt ist.

FAQ

Was ist eine gute Erfolgsrate für Residential Proxies? Es hängt vollständig vom Ziel ab, eine gut verteidigte Seite blockiert mehr als eine offene. Was zählt, ist, sie gegen Ihr Ziel zu messen und Anbieter am selben Ziel zu vergleichen. Teilen Sie Fehler in Blocks versus Errors, um zu wissen, was zu beheben ist.

Warum ist mein Residential Proxy langsamer als ein Datacenter-Proxy? Weil er über ein echtes Verbrauchergerät routet, dieser Hop fügt per Design Latenz hinzu. Das ist der Tradeoff für Echtnutzer-Vertrauen und höhere Erfolgsraten auf Seiten, die Datacenter-IPs blockieren. Beurteilen Sie Residential nach Erfolgsrate und Latenzverteilung, nicht nach dem rohen p50 gegen Datacenter.

Wie teste ich die Standortgenauigkeit auf Stadtebene? Visieren Sie die Stadt an und prüfen Sie die Exit-IP gegen eine Geo-IP-Quelle, idealerweise dieselbe, die Ihr Ziel nutzt. Erwarten Sie, dass die Ländergenauigkeit sehr hoch ist und die Stadtgenauigkeit unschärfer, da Geo-IP-Datenbanken sich über Stadtgrenzen uneinig sind. Siehe wann Targeting auf Stadtebene zählt.

Warum zählt eine 200-Antwort trotzdem als Fehler? Weil Seiten Soft Blocks ausliefern, CAPTCHA- oder “verifizieren Sie, dass Sie ein Mensch sind”-Seiten, mit einem 200-Status. Wenn Sie nur den Statuscode prüfen, zeichnen Sie Blocks als Erfolge auf. Validieren Sie, dass der Inhalt dem einer echten Seite entspricht.

Sollte ich mit rotierenden oder Sticky Sessions testen? Beide, je nach Workload. Rotierend (kein sid) sampelt den Pool und eignet sich fürs breite Scrapen; Sticky (Sticky vs Rotierend) testet mehrstufige Flows. Messen Sie den Modus, in dem Sie tatsächlich in der Produktion laufen.

Fazit

Einen Residential Proxy gut zu testen, bedeutet, sich zu weigern, ihn auf eine einzige Geschwindigkeitszahl zu reduzieren. Messen Sie die Erfolgsrate gegen Ihr echtes Ziel mit Inhaltsvalidierung, die Latenz als Verteilung mit einem Blick auf den p95-Tail, und die Standortgenauigkeit mit einer vernünftigen Geo-IP-Ground-Truth, und Sie wissen, ob ein Anbieter tatsächlich zu Ihrem Job passt, statt aus einer Marketingzahl zu raten. Die Poolqualität ist es, die alle drei bewegt, also hilft das Verständnis der IP-Reputation, die Ergebnisse zu interpretieren.

Wenn Sie Anbieter benchmarken oder Ihre eigene Erfolgsrate debuggen, führen Sie diese Tests gegen das Residential-Gateway und Ihr Ziel Ihrer Wahl aus. Die Preisseite hat Pro-GB-Tarife, um es gegen die Märkte und Seiten zu testen, die Ihnen wichtig sind.