So messen Sie Proxy-Geschwindigkeit und -Uptime selbst: Eine wiederholbare Methode

Die Geschwindigkeit eines Proxys ist keine einzelne Zahl: Sie setzt sich zusammen aus Latenz (wie lange bis zum ersten Byte), Durchsatz (wie schnell die Bytes ankommen) und Erfolgsrate (wie oft Sie überhaupt eine brauchbare Antwort erhalten) — und jede dieser Größen variiert je nach Stunde, Ziel und Exit-IP. Ein einzelner Test zu einem Zeitpunkt sagt fast nichts aus, weshalb Marketingzahlen von Anbietern und einmalige Bewertungen so leicht zu erstellen und so schwer zu nutzen sind. Dies ist die Methode, die wir für unsere eigenen Rankings verwenden: was gemessen wird, wie, wie oft und wie man es zusammenfasst, damit das Ergebnis aussagekräftig ist.

Die vier Kennzahlen

Metrik	Was sie beantwortet	Wie man sie erhält	Typischer guter Wert
Latenz (TTFB)	Wie lange jede Anfrage wartet, bis Daten übertragen werden	`curl -w %{time_starttransfer}` auf eine kleine Ressource	Datacenter: +10–50 ms gegenüber direkt; Residential/Mobile: +80–300 ms
Durchsatz	Wie schnell Massendaten übertragen werden	Zeitmessung eines Downloads fester Größe (1–10 MB)	Datacenter: nahe der Leitungsgeschwindigkeit; Residential: 5–50 Mbit/s; Mobile: 5–30 Mbit/s
Erfolgsrate	Wie oft eine Anfrage mit einem echten 2xx abgeschlossen wird	Zählen der Ergebnisse über viele Anfragen	>98% bei neutralen Zielen; niedriger bei geschützten Zielen ist das Werk des Ziels
Uptime	Wie oft der Proxy überhaupt erreichbar ist	Periodischer Konnektivitätstest über Tage	>99,5% für Datacenter/ISP; rotierende Pools maskieren einzelne Ausfälle

Berichte, die eine einzige „Geschwindigkeits“-Zahl angeben, berichten meist den Durchsatz bei einem großen Download von einem Datacenter-Proxy zu einer ruhigen Stunde — die schmeichelhafteste Kombination überhaupt.

Prinzipien vor Befehlen

Messen Sie die Differenz, nicht den Absolutwert. Führen Sie immer dieselbe Anfrage direkt und durch den Proxy unmittelbar hintereinander aus und berichten Sie die Differenz. Andernfalls wird die Variabilität Ihrer eigenen Verbindung mit der des Proxys vermischt.
Immer dasselbe Ziel. Verwenden Sie einen kleinen, schnellen, stabilen Endpunkt, der nicht rate-limitiert — eine statische Datei auf einem großen CDN oder Ihrem eigenen Server. Messen Sie niemals gegen die Website, die Sie scrapen wollen; deren Anti-Bot-Antwort ist eine andere Messung.
Viele Stichproben, über die Zeit verteilt. Mindestens 20 Anfragen pro Durchlauf; Durchläufe zu mehreren Tageszeiten und über eine Woche. Proxies sind geteilte Infrastruktur, und die Last folgt den Geschäftszeiten in den Regionen des Anbieters und der Exit-IPs.
Berichten Sie Perzentile, nicht Durchschnittswerte. Ein einziger 30-Sekunden-Timeout zerstört den Mittelwert. Der Median (p50) sagt Ihnen die typische Erfahrung; p95 die Erfahrung an schlechten Tagen; beide sind wichtiger als der Durchschnitt.
Aufwärmen. Verwerfen Sie die erste Anfrage jedes Durchlaufs — DNS- und TLS-Session-Setup machen sie langsamer als die restlichen.
Ändern Sie immer nur eine Sache. Den Datacenter-Proxy von Anbieter A mit dem Residential-Proxy von Anbieter B zu vergleichen, vergleicht Typen, nicht Anbieter.

Latenz mit curl

# direkt
curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

# über Proxy
curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s \
     -w "connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

Durch einen Proxy ist time_connect die Zeit, um den Proxy zu erreichen; der Connect und TLS des Ziels finden im Tunnel statt und landen in time_appconnect/time_starttransfer. Die Zahl, die Sie vergleichen sollten, ist ttfb: proxied minus direkt ist die zusätzliche Latenz des Proxys. Schleifen Sie es:

for i in $(seq 1 20); do
  curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{time_starttransfer}\n" https://cdn.example.com/1kb.txt
done | sort -n | awk '{a[NR]=$1} END{print "p50", a[int(NR*0.5)], "p95", a[int(NR*0.95)]}'

Durchsatz

curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{speed_download} bytes/s  %{size_download} bytes  %{time_total}s\n" \
     https://cdn.example.com/5mb.bin

Verwenden Sie eine Datei, die groß genug ist, dass der Verbindungsaufbau einen kleinen Bruchteil ausmacht (5–10 MB), aber klein genug, um bei Residential-Tarifen mit Abrechnung pro GB nicht zu viel zu verbrauchen. Bei rotierenden Pools variiert der Durchsatz mit der Verbindung des Exit-Hosts; führen Sie genügend Stichproben durch, um die Verteilung zu sehen, und denken Sie daran, dass bei Tarifen pro GB der Durchsatz auch bestimmt, wie schnell Sie Geld ausgeben.

Erfolgsrate

Jede Anfrage endet in einem von: einem 2xx mit einem Body der erwarteten Größe; einem 4xx/5xx vom Ziel; einem Proxy-Fehler (407, Verbindung abgelehnt, Timeout); oder einer Challenge-Seite (CAPTCHA/Interstitial) mit einem 200-Status — letzteres übersehen naive Zähler, also prüfen Sie den Body, nicht nur den Code. In Python:

import requests, time, statistics as st

PROXY = {"https": "http://user:pass@proxy.example.com:8080"}
URL, N = "https://cdn.example.com/1kb.txt", 50
lat, outcomes = [], {"ok": 0, "http_err": 0, "proxy_err": 0, "timeout": 0, "challenge": 0}

for i in range(N):
    t = time.perf_counter()
    try:
        r = requests.get(URL, proxies=PROXY, timeout=15)
        dt = time.perf_counter() - t
        if r.status_code == 200 and len(r.content) > 500 and b"captcha" not in r.content.lower():
            outcomes["ok"] += 1; lat.append(dt)
        elif r.status_code == 200:
            outcomes["challenge"] += 1
        else:
            outcomes["http_err"] += 1
    except requests.exceptions.ProxyError:
        outcomes["proxy_err"] += 1
    except requests.exceptions.Timeout:
        outcomes["timeout"] += 1
    time.sleep(0.5)

lat.sort()
print(outcomes, "success %.1f%%" % (100 * outcomes["ok"] / N))
if lat: print("p50 %.3fs  p95 %.3fs" % (lat[len(lat)//2], lat[int(len(lat)*0.95)]))

Trennen Sie Proxy-Fehler (407, Verbindungsfehler, Timeouts zum Proxy) von Ziel-Fehlern (403, 429, Challenges). Ersteres ist das Problem des Anbieters; letzteres betrifft den Ruf der IP bei diesem Ziel und gehört zu einem anderen Test — siehe wie Anti-Bot-Systeme Anfragen bewerten.

Uptime

Uptime ist die Erfolgsrate über die Kalenderzeit. Planen Sie einen leichten Test — den obigen Latenzbefehl oder ein bloßes CONNECT — alle 5–15 Minuten für mindestens eine Woche, protokollieren Sie das Ergebnis mit Zeitstempel und berechnen Sie den Anteil erfolgreicher Tests. Zwei Feinheiten:

Rotierende Pools verbergen Ausfälle. Wenn ein Exit stirbt, erhalten Sie einen anderen; das Gateway selbst hat die Uptime. Testen Sie das Gateway und verfolgen Sie separat, wie oft sich die zugewiesene IP ändert, wenn Sie eine Sticky-Session angefordert haben — eine unerwartete Änderung ist ein weicher Ausfall.
Statische IPs (Datacenter, ISP) sind das, wofür „99,9%“ normalerweise behauptet wird. 99,9% sind 43 Minuten Ausfall pro Monat; 99,5% sind 3,6 Stunden. Beides ist leicht von einer Woche mit 15-Minuten-Tests zu unterscheiden.

Planung der Durchläufe

Ein minimaler, aber aussagekräftiger Zeitplan: Latenz + Erfolg (20–50 Anfragen) um 03:00, 09:00, 14:00 und 20:00 Uhr in der lokalen Zeit der Exit-IPs, jeden Tag für sieben Tage; Durchsatz einmal pro Durchlauf; ein Konnektivitätstest alle 15 Minuten durchgehend. Das sind ein paar hundert Kilobyte pro Tag und Proxy für Latenz und einige zehn Megabyte für Durchsatz — auch bei Tarifen pro GB erschwinglich, wenn Sie eine kleine Datei verwenden. Führen Sie es von einer Maschine aus, die läuft (ein kleiner VPS ist ideal), mit cron, und schreiben Sie eine CSV-Zeile pro Anfrage. Unsere veröffentlichten Rankings — zum Beispiel das Geschwindigkeits-Ranking und das Zuverlässigkeits-Ranking — basieren genau auf solchen einwöchigen Serien, nicht auf einem einzelnen Nachmittag.

Interpretation der Ergebnisse

p50-Latenz nahe der Norm des Typs und p95 innerhalb des ~3-fachen von p50: gesund. Ein p95, der ein Vielfaches des p50 beträgt, bedeutet intermittierende Überlastung — der Anbieter ist zu Spitzenzeiten überbucht.
Erfolgsrate unter ~97% bei einem neutralen Ziel aufgrund von Proxy-Fehlern: Infrastrukturproblem, nicht Ihres.
Tagsüber viel schlechter als nachts: geteilte Kapazität; fragen Sie nach dedizierten Optionen oder akzeptieren Sie es in der Planung.
Großartige Zahlen bei Datacenter, schlechte bei Residential vom selben Anbieter: normal — verschiedene Produkte; vergleichen Sie Residential mit Residential.
Uptime unter der Behauptung: Sie haben jetzt ein Protokoll, das Sie dem Support zeigen können, das mehr wert ist als eine Beschwerde.

Denken Sie schließlich an den Typ. Residential- und Mobile-Proxies sind konstruktionsbedingt langsamer — der Datenverkehr durchläuft tatsächlich eine Heimleitung oder einen Mobilfunkmast — und sie für Geschwindigkeit zu kaufen, ist ein Kategorienfehler; siehe den Vergleich der Proxy-Typen. Messen Sie sie gegen ihre eigene Klasse und gegen das, was Ihre Aufgabe tatsächlich benötigt. Beachten Sie auch, dass eine proxierte Verbindung HTTP/2 statt HTTP/3 verwendet, also vergleichen Sie Gleiches mit Gleichem, wenn die direkte Basislinie auf einer QUIC-fähigen Website liegt (Details).

Häufig gestellte Fragen

Wie teste ich die Proxy-Geschwindigkeit?

Fordern Sie dieselbe kleine Ressource direkt und über den Proxy an, viele Male, zu verschiedenen Tageszeiten; vergleichen Sie die Time-to-First-Byte (Latenz) und messen Sie separat die Zeit für einen Download fester Größe (Durchsatz). Berichten Sie Mediane und 95. Perzentile, nicht Durchschnittswerte.

Was ist eine gute Proxy-Latenz?

Relativ zu einer direkten Verbindung: Datacenter-Proxies fügen zig Millisekunden hinzu; Residential- und Mobile-Proxies etwa 80–300 ms, da der Datenverkehr über eine Verbraucherverbindung läuft. Bewerten Sie jeden Typ anhand seiner eigenen Norm.

Wie überprüfe ich die Proxy-Uptime?

Testen Sie sie nach einem Zeitplan (alle 5–15 Minuten) für mindestens eine Woche, protokollieren Sie jedes Ergebnis und berechnen Sie den Anteil erfolgreicher Tests. Bei rotierenden Pools testen Sie das Gateway; bei statischen IPs testen Sie die IP selbst.

Warum weichen meine Ergebnisse von den Angaben des Anbieters ab?

Angaben sind meist Best-Case: Datacenter-Produkt, ruhige Stunde, großer Download, einzelne Stichprobe. Ihre Messung umfasst Spitzenzeiten, die spezifischen Exit-IPs, die Sie erhalten, und Perzentile. Ihre Zahl ist die, die Ihre Erfahrung vorhersagt.

Sollte ich gegen die Website messen, die ich scrapen möchte?

Nicht für Geschwindigkeit. Deren Anti-Bot-Schicht fügt Challenges und Blocks hinzu, die den IP-Ruf messen, nicht die Proxy-Leistung. Verwenden Sie eine neutrale statische Ressource für Geschwindigkeit und führen Sie Ruf-Tests separat durch.

Wie viele Stichproben benötige ich?

Mindestens 20 pro Durchlauf für einen stabilen Median, mehrere Durchläufe pro Tag über eine Woche, um Tages- und Wochentagseffekte zu sehen. Für Uptime benötigen Sie die Woche unabhängig davon.