Proxy speed: latency and throughput
Proxy speed is not one number but three: latency, throughput and time to first byte. A proxy adds distance to your connection's path, which raises latency, and its throughput is capped by the slowest link in the chain. You can measure each phase separately with a single curl command.
Three different measures
- Latency. The time a message takes to go and come back, called the round-trip time (RTT). It is measured in milliseconds and set mostly by distance and the number of hops on the path.
- Throughput. How much data arrives per second once the transfer has started. It is measured in megabits per second and limited by the bandwidth of the narrowest part of the path.
- Time to first byte (TTFB). The time from the start of the request until the first byte of the response arrives. It adds up connection setup, handshake round trips and the server's processing time.
Web pages and small requests depend mostly on latency. Downloading a large file is governed by throughput.
What happens before the first byte
This is the sequence for an HTTPS request through an HTTP proxy on a fresh connection:
- Your device opens a TCP connection to the proxy: one round trip between you and the proxy.
- It sends a CONNECT with the site's name. The proxy resolves the name, opens a connection to the site, then replies with success. That is one round trip to the proxy plus one between the proxy and the site. The method is explained in HTTPS proxies and CONNECT.
- The TLS handshake between you and the site runs through the tunnel. TLS 1.3 needs one round trip over the whole path, as in RFC 8446; TLS 1.2 needs two.
- The request itself: another round trip over the whole path, plus the server's processing time.
A worked example: if the round trip between you and the proxy is 80 ms and between the proxy and the site 20 ms, the whole path is 100 ms. The first byte arrives after about 380 ms plus server time: 80 for the connection, 100 for CONNECT, 100 for TLS and 100 for the request.
With SOCKS5 only the second step changes. RFC 1928 defines an exchange to choose the authentication method, then authentication if there is any, then the request to connect to the site. On a connection that is already open, the first three steps disappear and only the request remains.
Why your own line speed is not enough
Throughput through a proxy cannot exceed the slowest link: your line, the path to the proxy, the proxy's own line, and the path on to the site. Latency matters here too, not just for the first byte.
RFC 6349 explains why: TCP will not send more than its window before an acknowledgement comes back. Maximum throughput is therefore the window size times 8, divided by the round-trip time. The amount of data that must be "in flight" to fill the line is the bandwidth times the round-trip time, the bandwidth-delay product (BDP).
For example, a 64 KB window with a 200 ms round trip caps a single connection at about 2.6 Mbit/s, however fast the line is. To fill a 12 Mbit/s line over the same round trip you need a window of at least 300 KB. That is why a distant proxy downloads more slowly than a nearby one, even on equal lines. Packet loss, common on wireless networks, lowers throughput further.
What is different about mobile exits
On a mobile network the path gains a wireless segment between the device and the cell. Its latency varies with signal strength and the number of users on the same cell. Measurements on a mobile exit therefore vary more than on a server in a data center.
When a large download fills the line, packets queue in buffers along the path and latency rises for every other connection. If a download is running in the background, expect pages to slow down with it. Upload speed on mobile networks is also usually lower than download speed.
Measuring with curl timings
curl's -w option prints the timing of each phase when the request finishes:
curl -s -o /dev/null -x http://HOST:PORT --proxy-user USER:PASS \
-w 'connect %{time_connect}\ntls %{time_appconnect}\nfirstbyte %{time_starttransfer}\ntotal %{time_total}\n' \
https://example.com/All values are in seconds, and all are counted from the start of the request, not from the end of the previous phase. This is what each one means according to the curl manual:
| Variable | What it measures | Note with a proxy |
|---|---|---|
| time_namelookup | Until name resolution completed | The proxy resolves the site's name, so this covers the proxy's name only |
| time_connect | Until the TCP connect to the remote host or proxy completed | Here it is the connection to the proxy, i.e. your distance to it |
| time_appconnect | Until the TLS handshake with the remote host completed | Includes opening the tunnel and the proxy's connection to the site |
| time_starttransfer | Until the first byte was received | This is your TTFB |
| time_total | The whole operation | Includes the full transfer |
| speed_download | Average download speed in bytes per second | Multiply by 8 for bits per second |
The gaps between the values show where the delay is:
- Large time_connect: the proxy is far from you or overloaded.
- Large gap between time_connect and time_appconnect: the delay is in setting up the tunnel and the path from the proxy to the site.
- Large gap between time_appconnect and time_starttransfer: the server is slow to respond, or the whole path is long.
To measure throughput, download a large file, say a hundred megabytes, and print %{speed_download}. Small files are not enough, because TCP starts slowly and grows its window gradually.
How to get measurements you can trust
- Repeat every measurement at least ten times and take the median, not the mean, since one outlier skews the mean.
- Run the same command without -x. The difference between the two results is the cost of the proxy.
- Separate fresh connections from reused ones; the first pays for every handshake.
- Test at different times of day, against the site you will actually use.
How to make it faster
- Reuse connections. An open connection, or HTTP/2 carrying many requests over one connection, saves every handshake.
- Pick an exit close to the site when the task allows it, and an entry point close to you if the provider offers one.
- Let the proxy resolve names with socks5h, so resolution happens near the site and does not leak to your provider.
- Do not chain proxies without a reason; each link adds a round trip to every handshake.
- Split large downloads across more than one connection when the window is the limit, within what the exit allows.
With syriaproxy your traffic exits from the Syriatel 4G network inside Syria, at speeds up to 12 Mbit/s. Latency includes the path from you to Syria and then on to the site. Syrian sites and services therefore respond faster than sites far from Syria.
FAQ
Why does a speed test look fast while pages feel slow?
Speed tests measure throughput with large files. Pages are made of many small requests, and every new connection among them pays for its round trips, so latency rules.
What is the difference between Mbit/s and MB/s?
A byte is eight bits. So 12 Mbit/s is about 1.5 MB/s, which is what download managers usually show.
Is an HTTP proxy faster than SOCKS5?
Usually the difference is small. SOCKS5 with authentication needs slightly more exchanges when opening a connection, but after that it moves data at the same speed. Distance to the proxy matters more than the protocol.
Why is the first measurement slower than the rest?
Because the first request pays for everything: name resolution, the connection and the handshakes. Later requests benefit from cached names, and may resume an earlier TLS session or reuse the same connection.
Measure your proxy's latency with the free proxy checker, no command line needed.