Warum mobile Proxys abends schlechter laufen – und Speedtests trotzdem Bestwerte zeigen
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öße | Wofür sie zuständig ist |
|---|---|
| Latenz (Ping) | Reaktionsfähigkeit der Oberfläche, Timeout-Verhalten |
| Jitter | Schwankung der Latenz. Reißt lange Verbindungen und WebSockets ab |
| Paketverluste | Abgebrochene Anfragen, kaputte Downloads, Wiederholungen |
| Route | Zusä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.

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
| Aufgabe | Jitter | Paketverluste |
|---|---|---|
| Parsing, Scraping | bis 30 ms | bis 1% |
| Multi-Accounting, Antidetect | bis 50 ms | bis 2% |
| SMM-Automatisierung | bis 60 ms | bis 2% |
| Video, Anrufe | bis 30 ms | bis 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.
| Stunde | Geschwindigkeit, Mbit/s | Ping, ms | Jitter, ms | Paketverluste, % | Messungen |
|---|---|---|---|---|---|
| 00:00 | 66 | 134 | 52.1 | 4.12 | 140 |
| 01:00 | 61 | 135 | 56.8 | 4.99 | 125 |
| 02:00 | 42 | 167 | 57.9 | 5.37 | 113 |
| 03:00 | 34 | 135 | 60.8 | 2.67 | 86 |
| 04:00 | 43 | 132 | 42.8 | 1.94 | 72 |
| 05:00 | 45 | 131 | 40.8 | 2.50 | 92 |
| 06:00 | 42 | 115 | 34.3 | 2.49 | 131 |
| 07:00 | 54 | 111 | 39.8 | 2.48 | 140 |
| 08:00 | 57 | 113 | 25.0 | 2.44 | 210 |
| 09:00 | 54 | 108 | 44.2 | 1.57 | 302 |
| 10:00 | 64 | 84 | 37.7 | 0.79 | 309 |
| 11:00 | 66 | 89 | 34.6 | 1.06 | 363 |
| 12:00 | 60 | 101 | 38.9 | 1.00 | 388 |
| 13:00 | 60 | 100 | 29.1 | 1.80 | 348 |
| 14:00 | 61 | 95 | 35.2 | 1.45 | 340 |
| 15:00 | 61 | 100 | 40.1 | 1.83 | 322 |
| 16:00 | 66 | 97 | 47.5 | 1.33 | 356 |
| 17:00 | 63 | 95 | 47.1 | 1.06 | 330 |
| 18:00 | 59 | 100 | 60.6 | 0.97 | 348 |
| 19:00 | 61 | 98 | 48.9 | 1.02 | 328 |
| 20:00 | 68 | 112 | 64.1 | 1.74 | 368 |
| 21:00 | 59 | 104 | 57.6 | 2.53 | 322 |
| 22:00 | 62 | 112 | 61.5 | 2.56 | 266 |
| 23:00 | 54 | 149 | 86.1 | 3.86 | 165 |
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.