Wir haben 5964 Messungen in Mobilfunknetzen ausgewertet und uns angeschaut, wie sich der Kanal über den Tag verhält. Das Ergebnis: Genau die Kennzahl, nach der alle Proxys auswählen, steigt in dem Moment, in dem die Arbeit am schlechtesten läuft.

Warum Megabits eigentlich nichts über die Kanalqualität aussagen, haben wir im Artikel „Mbit/s sagen nichts über die Qualität mobiler Proxys“ erklärt. Hier geht es um dieselbe Idee, aber mit Daten: Wie sich Latenz, Jitter und Paketverluste über den Tag verhalten.

Ein bekanntes Bild

Du nimmst dir einen schnellen Proxy, aber der Antidetect-Browser wirft trotzdem Sessions raus, der Parser läuft in Timeouts, Downloads brechen mittendrin ab. Du öffnest den Speedtest – und siehst 40 Megabit, alles in Ordnung. Der Anbieter zuckt mit den Schultern: Der Kanal ist normal, schau selbst.

Der Kanal ist tatsächlich normal – nach der Messgröße, die du gemessen hast. Das Problem ist: Du hast das Falsche gemessen.

Was die Arbeit wirklich stört

Die Bandbreite löst genau eine Aufgabe: Wie schnell lädt eine große Datei herunter. Alles andere – Seitenaufrufe, Session-Stabilität, Captcha-Antworten, lange Parser-Anfragen – hängt an anderen Größen.

GrößeWofür sie zuständig ist
Latenz (Ping)Reaktionsfähigkeit der Oberfläche, Timeout-Verhalten
JitterSchwankung der Latenz. Reißt lange Verbindungen und WebSockets ab
PaketverlusteAbgebrochene Anfragen, kaputte Downloads, Wiederholungen
RouteZusätzliche Hops, Landung in fremden autonomen Systemen

Ein Mobilfunknetz unterscheidet sich von einer Festnetzleitung nicht dadurch, dass es langsamer ist. Es ist unbeständig: Die Zelle wird abends überlastet, der Betreiber schaltet zwischen Frequenzbändern um, zeitgesteuertes Throttling greift. Eine einzelne Messung im Browser beschreibt eine Sekunde aus dem ganzen Tag – und meistens genau die, in der du zufällig nachgesehen hast.

So sieht das in den Daten aus

Wir haben Messungen gesammelt, die über MTS-Netze liefen, und sie nach Stunden gemittelt. Drei Größen auf drei Achsen – bewusst getrennt: Alles auf einer Achse zu vereinen, hieße, das Bild zu verzerren.

Wir haben 5964 Messungen in Mobilfunknetzen ausgewertet und uns angeschaut, wie sich der Kanal über den Tag verhält. Das Ergebnis: Genau die Kennzahl, nach der ...

Von oben nach unten: Download-Geschwindigkeit (Mbit/s), Jitter (ms), Paketverluste (%). 5964 Messungen in MTS-Netzen, September 2025 – August 2026. Jeder Punkt ist ein Stundenmittelwert, zwischen 72 und 388 Messungen pro Stunde. Orange markiert ist der Abendzeitraum 18:00–23:00 Uhr; ×3,4 und ×6,8 zeigen, um wie viel die Größe zur Nacht hin ansteigt. Punkte markieren das Tagesminimum und -maximum.

Das Wichtigste aus dieser Grafik

Die Geschwindigkeit bleibt fast gleich. Von sieben Uhr morgens bis Mitternacht pendelt sie zwischen 54 und 68 Mbit/s. Wer zu irgendeiner Tageszeit einen Speedtest macht, sieht etwa dieselbe Zahl und schließt daraus: Mit dem Kanal ist alles in Ordnung.

Der Jitter steigt im selben Zeitraum um das 3,4-fache – von 25 ms um acht Uhr morgens auf 86 ms um elf Uhr abends. Die Paketverluste steigen um das 6,8-fache: von 0,79 % tagsüber auf 5,37 % Richtung Morgen.

Und der unangenehmste Zufall: um 20:00 Uhr erreicht die Geschwindigkeit ihr Tagesmaximum – 68 Mbit/s –, während der Jitter zur selben Stunde bei 64 ms liegt, zweieinhalb Mal so hoch wie am Morgen. Ein Speedtest zeigt in diesem Moment den besten Wert des Tages. Arbeiten kann man in diesem Moment am schlechtesten.

Genau deshalb sind Beschwerden wie „abends läuft alles langsam, aber der Test zeigt normale Geschwindigkeit“ keine Einbildung und kein Placebo-Effekt. Der Test misst die Größe, die sich abends nicht verschlechtert.

So misst du richtig

Du brauchst keine einzelne Messung, sondern eine Reihe. CLI installieren, per Cron starten und in eine Datei sammeln:

speedmeter --json | jq -c '{t:.timestamp, d:.download, p:.ping, j:.jitter}' >> proxy.jsonl

In die Crontab, alle fünfzehn Minuten:

*/15 * * * * /usr/local/bin/speedmeter --json >> /var/log/proxy-speed.jsonl

Über den Tag kommen so 96 Messpunkte zusammen, und man sieht sofort, ob dein Kanal ein Abendloch hat. Die Binärdatei ist autark, etwa 400 KB groß, ohne Abhängigkeiten – installierbar auf jedem Server, auf dem deine Automatisierung läuft.

Welche Werte als akzeptabel gelten

AufgabeJitterPaketverluste
Parsing, Scrapingbis 30 msbis 1%
Multi-Accounting, Antidetectbis 50 msbis 2%
SMM-Automatisierungbis 60 msbis 2%
Video, Anrufebis 30 msbis 1%

Beachte, was in dieser Tabelle fehlt: eine Spalte für Megabits. Für die genannten Aufgaben hört die Bandbreite ab etwa zehn Megabit auf, ein Limit zu sein.

Daten nach Stunden

Dieselben Zahlen wie in der Grafik – damit du sie nachprüfen oder mit deinen eigenen Messungen vergleichen kannst.

StundeGeschwindigkeit, Mbit/sPing, msJitter, msPaketverluste, %Messungen
00:006613452.14.12140
01:006113556.84.99125
02:004216757.95.37113
03:003413560.82.6786
04:004313242.81.9472
05:004513140.82.5092
06:004211534.32.49131
07:005411139.82.48140
08:005711325.02.44210
09:005410844.21.57302
10:00648437.70.79309
11:00668934.61.06363
12:006010138.91.00388
13:006010029.11.80348
14:00619535.21.45340
15:006110040.11.83322
16:00669747.51.33356
17:00639547.11.06330
18:005910060.60.97348
19:00619848.91.02328
20:006811264.11.74368
21:005910457.62.53322
22:006211261.52.56266
23:005414986.13.86165

Ein Wort zu den Daten

Das ist ein Durchschnitt über viele Nutzer und viele Zellen, keine einzelne SIM-Karte unter kontrollierten Bedingungen. So ein Schnitt zeigt die Form der Tageskurve, ersetzt aber nicht die Messung deines eigenen Kanals – die musst du selbst machen, mit dem Skript oben.

Das Tool, mit dem diese Zahlen gesammelt wurden, ist offen und kostenlos: speedmeter.dev. Es misst Jitter und Paketverluste serverseitig, statt dem Browser-Bericht zu vertrauen, und liefert die Ergebnisse als JSON für Skripte.