Why Tor feels slower than a VPN: clicks versus downloads

Pages that feel sticky while downloads run at a normal rate are describing round trips, not bandwidth. A VPN adds one encrypted hop and a Tor circuit adds several, and each extra hop costs a handshake before any useful bytes move. That cost shows up on a page that opens many short connections and largely vanishes on a single large transfer. Once the pattern is visible, the argument stops being about which tool is faster.

The symptom points at setup cost, not capacity

A page load is a chain of dependent exchanges: a name lookup, a transport handshake, a TLS handshake, then the first request. Every hop in the path inserts its own round trip into that chain before anything renders. A large download pays the same setup cost once and then streams, which is exactly why the two workloads disagree.

Read the network panel for the time spent waiting before the first byte, not the total. Long waiting with a short content download points at round trips, while a long content download with a short wait points at throughput. Repeat against a second destination, because one host behind a busy relay proves nothing. When the transfer is fine and the click is slow, suspect setup cost long before you suspect bandwidth.

Delay and capacity fail in different ways

Take two readings and most of the confusion resolves itself. Latency is a fixed cost per exchange and capacity is a rate over time, so one path can be good at the first and bad at the second. A distant endpoint with an idle processor answers a small request quickly and still caps a sustained transfer at whatever its uplink allows. Users experience that split as a snappy click followed by a progress bar that barely moves.

Test capacity with a sustained transfer and watch whether the rate holds steady or sawtooths. Test latency with a small request repeated many times and read the spread rather than the best sample, because a wide spread feels worse than its average suggests. Record both numbers before and after every change, or you will credit the wrong variable later.

Treating the two as a single number produces fixes that never move the measurement you care about. That is the most common way a latency complaint gets answered with a bandwidth upgrade.

Onion routing adds hops you did not pick

A Tor circuit normally uses three relays, a guard, a middle node and an exit, and the client selects them from a consensus rather than from a map. The path can therefore be far longer than the direct line to the destination. Each relay also carries other people's traffic, so your stream shares whatever capacity that relay has left.

Circuit reuse softens the cost, because a new stream can ride an existing circuit instead of paying for another build. A client that builds a fresh circuit per request pays setup repeatedly and feels far worse than one that reuses. Exit choice matters too, since some exits carry heavier load and nothing in the interface tells you which one you landed on. That sharing is the point of the design and the reason latency cannot be tuned to a fixed value, so one slow exit is a poor reason to abandon the arrangement.

Changing the order of the chain changes the experiment

VPN first and Tor second is a different experiment from Tor first and VPN second. In the first arrangement the VPN endpoint carries the whole circuit, so your access network learns only the VPN address. In the second the VPN connection is itself carried inside the onion path, and the exit sees VPN traffic. Both are legitimate designs, and comparing either against a bare VPN measures something else, which is why the Tor Project's page on combining the two frames it as a question about what you are trying to hide before it is a question about timing.

Keep the device, access network and destination fixed, and change exactly one element between runs. Moving servers, circuits and test hosts together produces a difference nobody can attribute. Write down what each arrangement hides from which party before optimising it, because a fast chain that exposes what you wanted hidden is not an improvement.

A comparison that survives a second run

Pick two or three destinations you actually use and time the same interaction on each, including one page that pulls many small resources and one large transfer. Repeat the whole set at a different hour of the day.

Report median and worst case instead of the fastest sample, because interactive work is judged by its bad moments. Note the client, the endpoint or exit, and whether the circuit or tunnel was reused for that run. If a change improves the median while worsening the tail, that is a trade rather than a win, and deciding whether users will notice it is the actual decision.