Why Mobile Proxies Slow Down in the Evening While Speedtests Show Maximum Performance
We took 5,964 measurements from mobile networks and looked at how the channel behaves by hour of day. Turns out the metric everyone uses to pick a proxy actually peaks exactly when things get hardest to work with.
Why megabits don't describe channel quality at all, we covered in the article "Mbps Say Nothing About Mobile Proxy Quality". Here's the same idea, but backed by data: how latency, jitter, and packet loss behave by hour of day.
A familiar picture
You grab a faster proxy, but the antidetect browser still logs your sessions out, the parser keeps hitting timeouts, downloads die halfway through. You open a speedtest — there's forty megabits, everything's fine. The seller shrugs: the channel is fine, see for yourself.
The channel really is fine — by the metric you measured. The problem is you measured the wrong thing.
What actually breaks your workflow
Bandwidth solves exactly one problem: how fast a big file downloads. Everything else — loading pages, keeping sessions alive, answering CAPTCHAs, long parser requests — depends on other metrics.
| Metric | What it controls |
|---|---|
| Latency (ping) | Interface responsiveness, timeout triggers |
| Jitter | Latency variance. Breaks long-lived connections and websockets |
| Packet loss | Dropped requests, corrupted downloads, retries |
| Route | Extra hops, landing in a foreign autonomous system |
A mobile network isn't different from a wired one because it's slower. It's inconsistent: the cell tower gets congested by evening, the carrier switches bands, shaping kicks in on a schedule. A single browser-based measurement describes one second out of a whole day — usually the one you happened to check.
What the data looks like
We collected measurements passing through MTS networks over ten months and averaged them by hour of day. Three metrics on three separate charts — deliberately separate: putting them on the same axis would mean forcing the picture.
Top to bottom: download speed (Mbps), jitter (ms), packet loss (%). 5,964 measurements on MTS networks, September 2025 — August 2026. Each point is the hourly average, from 72 to 388 measurements per hour. Orange highlights the evening window 18:00–23:00; ×3.4 and ×6.8 show how many times the metric grows by night. Dots mark the daily minimum and maximum.
The key takeaways from this chart
Speed barely changes. From 7 AM to midnight it stays in the 54–68 Mbps range. Someone running a speedtest at any time of day will see roughly the same number and conclude the channel is fine.
Jitter grows 3.4x over the same period — from 25 ms at 8 AM to 86 ms at 11 PM. Packet loss grows 6.8x: from 0.79% during the day to 5.37% toward the early morning.
And here's the nastiest coincidence: at 8 PM speed hits its daily peak — 68 Mbps — while jitter at that same hour sits at 64 ms, two and a half times higher than in the morning. A speedtest at that moment shows the best result of the day. Working at that moment is at its worst.
That's exactly why complaints like "everything slows down in the evening, but the test shows normal speed" aren't made up and aren't a placebo effect. The test measures the one metric that doesn't degrade in the evening.
How to measure properly
You don't need a single measurement — you need a series. Install the CLI, schedule it, and accumulate results into a file:
speedmeter --json | jq -c '{t:.timestamp, d:.download, p:.ping, j:.jitter}' >> proxy.jsonlAdd to cron — every fifteen minutes:
*/15 * * * * /usr/local/bin/speedmeter --json >> /var/log/proxy-speed.jsonlOver a day that gives you 96 points, and you can immediately see whether your channel has an evening dip. The binary is standalone, about 400 KB, no dependencies — installs on any server where your automation runs.
What values are acceptable
| Task | Jitter | Packet loss |
|---|---|---|
| Parsing, scraping | up to 30 ms | up to 1% |
| Multi-accounting, antidetect | up to 50 ms | up to 2% |
| SMM automation | up to 60 ms | up to 2% |
| Video, calls | up to 30 ms | up to 1% |
Notice what's missing from this table: a column for megabits. For the tasks listed, bandwidth stops being a bottleneck somewhere around ten megabits.
Hourly data
The same numbers as on the chart — so you can double-check them or compare against your own measurements.
| Hour | Speed, Mbps | Ping, ms | Jitter, ms | Packet loss, % | Measurements |
|---|---|---|---|---|---|
| 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 |
A note on the data
This is an average across many users and many cell towers, not a single SIM card under control. This slice shows the shape of the daily curve, but it doesn't replace measuring your own specific channel — you need to set that up yourself with the script above.
The tool used to collect these numbers is open and free: speedmeter.dev. It measures jitter and packet loss on the server side rather than trusting a browser report, and outputs JSON for scripts.