What 4G and 5G Proxy Speeds Really Mean

Speed is the number every proxy buyer looks at first and the one most often misread. A megabit figure describes how much data a link can move, which is only part of what makes a job feel fast or slow. Understanding the difference will save you from buying the wrong connection and from blaming the proxy for problems that live elsewhere.

Throughput and latency solve different problems

Throughput is volume over time: how many megabits per second the link can sustain. It governs how long a large download takes, how smoothly video streams, and how quickly a bulk transfer finishes. Latency is delay: how long a single round trip takes from request to first byte. It governs how responsive a page feels and how many small requests you can complete in a minute.

A crawler fetching thousands of modest HTML pages is almost entirely latency-bound. Each request spends most of its life waiting rather than transferring, so doubling throughput barely changes the finish time while halving round-trip delay changes it dramatically. Conversely, a job that pulls large media files is throughput-bound and hardly notices latency at all.

Mobile links have a characteristic profile: respectable throughput and higher, more variable latency than a wired connection, because the radio layer schedules airtime and retransmits lost frames. That variance is normal. It is the price of the carrier-level trust a mobile IP carries, and it is why your test methodology matters more than a single headline number.

What actually moves the number

Signal quality comes first. A modem with a strong, clean signal negotiates a higher-order modulation and moves more data per unit of airtime. A weaker or noisier signal forces the radio down to a more robust but slower encoding, and no amount of provisioning changes that. This is why device placement, antenna choice and the specific cell a modem attaches to have such a visible effect.

Cell load comes second and is usually the bigger swing. A cell tower divides its capacity among everyone connected to it, so a modem in a busy district at seven in the evening shares far more than the same modem at four in the morning. Your throughput can halve without anything at all changing on your side or the provider's.

Then there is the band and technology in use. A modem attached to 5G has substantially more headroom than one on 4G LTE, which is why 5G connections typically start above fifty megabits per second while 4G typically sits in the twenty to forty-five range. Some locations are LTE only, so if raw throughput matters to your job, choose the city with that in mind.

• Radio signal quality sets the ceiling for a given moment
• Cell congestion moves the actual result hour by hour
• The band and technology in use determines the envelope
• The distance between the modem and your target adds fixed latency

How to measure honestly

Test more than once and at more than one time of day. A single reading is weather, not climate. Take samples across a working day and across an evening peak, then describe the result as a range with a typical value, which is how the connection will actually behave.

Choose a test target that is geographically sensible. Measuring throughput from a New York modem to a server on another continent tells you about the internet backbone, not about the proxy. Pick a well-connected endpoint in the same country, and use the same endpoint every time so your readings are comparable.

Measure the thing you care about. If your work is many small requests, time a batch of realistic fetches and record the median and the slow tail, not the peak. If your work is bulk transfer, download a large file and record sustained rate rather than the burst at the start. Percentiles beat averages, because one very slow request in fifty is what breaks a pipeline, and an average hides it.

Concurrency changes the arithmetic

One connection rarely uses all available capacity, because each request spends time idle while it waits. Running several requests in parallel over the same port usually raises total useful throughput considerably, up to the point where the radio link becomes the constraint. Finding that point experimentally is more useful than any advertised figure.

Past that point, adding concurrency makes things worse rather than better. Queues build, latency climbs, timeouts start firing, and your retry logic generates yet more traffic on a link that is already saturated. If your throughput stops rising while your error rate starts rising, you have found the ceiling and should back off rather than push.

This is also the honest answer to how many jobs one port can support. It is not a fixed number. It depends on the size of your responses, how long each target takes to reply, and how much of your daily data allowance you want to spend. Measure with your own traffic and set the concurrency where errors stay flat.

When the proxy is not the problem

Plenty of apparent proxy slowness originates elsewhere. A target site that responds in several seconds will make any connection look sluggish. A headless browser rendering a heavy page spends most of its time in JavaScript execution, not on the network. DNS resolution, TLS handshakes and redirect chains all add time that has nothing to do with the radio link.

Isolate before you conclude. Fetch a small static file through the proxy to get a clean picture of the link itself, then fetch your real target directly without the proxy to see the site's own response time. Comparing the two usually points straight at the cause.

If the link itself genuinely looks poor, a rotation is the cheapest first remedy, since it may attach the modem to a different cell or a better band. Persistent poor performance in one city and good performance in another is worth raising with your provider, because it usually indicates something specific about that site or that device rather than a general condition.

Frequently asked