How to Measure the Real Speed of a 5G Proxy
A speed test run on your own connection tells you nothing about the proxy. A single test run through the proxy at two in the afternoon tells you about two in the afternoon. Measuring a 5G line properly is not hard, but it needs the right tool, a few repeats and a clear idea of what you are measuring. This guide gives you the commands and the method we use ourselves, and it is deliberately careful about numbers: the only speed figures we publish are that our 4G lines usually run 20 to 45 Mbps and our 5G lines run 50 Mbps and up, because the rest depends on the signal at the modem on the day.
Start with curl or wget through the proxy
The cleanest throughput test is a large file pulled through the line from a command line, because it removes the browser from the picture. With curl: curl -x http://user:pass@host:port -o /dev/null -w 'speed: %{speed_download} B/s time: %{time_total}s' https://some-large-file. The -w format prints the average download rate in bytes per second and the total time. Divide by 125000 to get megabits per second. For SOCKS5, swap -x for --socks5-hostname user:pass@host:port so DNS resolves on the far side as well.
wget works the same way: wget -e use_proxy=yes -e https_proxy=http://user:pass@host:port -O /dev/null https://some-large-file, and it prints the rate at the end. Pick a file hosted on a fast, nearby CDN, because a slow origin will measure the origin and not the line. A test file in the range of a few hundred megabytes gives the radio time to ramp up and settle, which a tiny file never does.
Browser speed tests via the proxy
If you prefer a visual number, set the proxy in a browser profile and open a speed test site through it. The test server you pick matters: choose one in or near the carrier gateway city shown by an IP lookup, not one near you, otherwise you add a long leg that has nothing to do with the mobile link. Run the test three times and keep the middle result. The first run often lands low because the modem was idle and the radio steps up as traffic appears.
Be aware that browser-based tests open many parallel streams, which flatters any connection with headroom. That is fine if your workload also runs many streams. If it runs one connection at a time, the curl number is the honest one.
Measure latency separately
Throughput and latency are different questions and both matter. For latency, time a small request rather than a large one: curl -x http://user:pass@host:port -o /dev/null -s -w 'connect: %{time_connect}s ttfb: %{time_starttransfer}s' https://a-fast-site. time_connect is the proxy handshake; time_starttransfer is how long until the first byte of the response. Repeat it ten times and look at the spread, not just the lowest value, because the spread is what your scraper or profile will actually feel.
A 5G line should show a visibly tighter and lower spread than a 4G line on the same carrier. If it does not, the modem may be camped on a low-band cell, and that is worth a note to support.
Repeat at busy hours
Mobile cells are shared with everyone within reach of the tower, and the evening is when they fill up. A measurement made at ten in the morning in the modem's time zone is a best case. Rerun the same curl at six, eight and ten in the evening local time and write the results down. The low point in that set is the number to plan around, not the high point.
Our lines are placed where mid-band coverage is dense, which keeps the busy-hour dip smaller than it would be on a low-band cell, but no mobile line is immune to a full tower. If you need a number you can count on at a specific hour, test at that hour.
Test from your own tool, not just from a terminal
The final measurement is the one that matters: run the real job. A scraper that opens fifty connections, a browser profile playing a video, an upload of a media file, each stresses the line differently. Point your actual tool at the proxy, run a small slice of the real workload, and look at the throughput and error rate it reports. This catches things a synthetic test misses, such as a tool that ignores the system proxy for some requests or a client that cannot keep enough connections open to use the bandwidth.
What to expect, without inventing numbers
A 4G LTE line from us usually measures between 20 and 45 Mbps on a clean download. A 5G line measures 50 Mbps and up, and the upper end depends on the band the modem holds and how loaded the cell is when you test. We do not print a bigger figure because the honest answer is a range that moves. If your tests land below those ranges consistently, send us the output; we can check the modem's band and signal, move the line to a better site, or move you to a different carrier in the same city at no charge.
Frequently asked
Why is my first test much slower than the second?
The modem had been idle and the carrier steps the radio link up as traffic arrives. Discard the first run and keep the median of the next three.
Should I test with HTTP or SOCKS5?
Use whichever your tool will use. Both go through the same modem and the same carrier link, so the result is close; SOCKS5 avoids a layer of HTTP parsing and is slightly leaner for raw transfer.
Does rotating the IP change the speed?
Not by itself. Rotation reconnects the modem to the carrier and the cell assigns a fresh address; the band and signal stay the same unless the modem happens to reattach to a different cell.
Can I test before paying for a month?
Yes. Buy an hourly or one-day plan on the tier you are considering, run this method, and if you keep the line the hours already paid count toward the day price.
