Measure mobile proxy speed and latency
Run a repeatable mobile proxy speed test. Separate connection setup, first-byte time, throughput and destination bottlenecks.
Measure a direct baseline and a proxied request to the same controlled destination. Record timing phases and payload size across several runs. One speed result cannot establish a carrier's typical performance or your application's capacity.
Choose the metric your task needs
A small API call and a large file download stress different parts of a connection. An interactive application may care most about the time to the first useful response. A batch transfer may care more about sustained throughput. A short IP-echo request is useful for routing verification, but too small for a meaningful bandwidth measurement.
| Metric | What to record |
|---|---|
| Connection setup | DNS, TCP and TLS timings, with the client and proxy protocol noted. |
| First response | Time to first byte, including destination processing. |
| Total request time | Elapsed time for a known payload and status. |
| Throughput | Transferred bytes divided by the relevant transfer interval. |
| Reliability | Successful completions and failure classes across repeated runs. |
Collect timings with curl
Use a small file on a server you control and keep its response size fixed. A destination that caches one run and recomputes the next can make the proxy appear faster or slower for unrelated reasons. Start with one request at a time and set a timeout.
curl's timing fields are cumulative milestones. For example, time_starttransfer includes earlier connection work. Do not add all reported milestones together. With a proxy, some phases describe the client-to-proxy path; interpret the fields for the protocol you are testing.
# MP_TEST_URL points to a controlled, fixed-size test resource.
curl --silent --show-error --output /dev/null \
--connect-timeout 10 --max-time 30 \
--proxy "$MP_PROXY_URL" \
--write-out 'status=%{http_code} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total} bytes=%{size_download} bytes_per_second=%{speed_download}\n' \
"$MP_TEST_URL"speed_download is reported in bytes per second. Convert units explicitly when comparing it with a network speed stated in bits per second.
Repeat a controlled test
- Run a direct request and record its timing and status.
- Repeat through the proxy with the same destination, payload and client.
- Collect several sequential observations rather than choosing the best result.
- Record country, carrier, time, payload size and any intentional rotation.
- Compare the median and slower observations; retain failed requests in the report.
- Only then try a modest concurrency increase against a destination you control.
Locate the bottleneck before changing plans
If the direct and proxied requests slow down together, investigate the destination or the local connection. If only one destination is slow, compare a second authorized endpoint. If performance drops when concurrency rises, the bottleneck may be the proxy, the carrier, client resources or the destination's limits.
An unlimited-bandwidth plan describes billing or usage terms. It does not mean unlimited speed, simultaneous connections or destination acceptance. Mobile performance can vary with signal, congestion and the network path.
Publish measurements with their date, method and limits if you share the result. This guide provides a method and worksheet; it does not present an unmeasured speed guarantee.
Sources and further reading
The guidance above distinguishes documented client behavior from product-specific details. Confirm current plan availability at checkout.