Why a Download Is Faster Over the VPN Than Directly

You start a large download, the first seconds look normal, and then the rate settles at roughly half of what the line should deliver. You connect the tunnel, repeat the same download, and it holds a higher rate for the whole file. That is a real measurement and a misleading conclusion at the same time, because the tunnel did not make the path faster. It moved your traffic off a port that something along the way was limiting.

The Shape of the Curve Gives It Away

Watch the transfer rather than the final number. A capped path usually begins near line rate, spends its burst allowance and then settles at the limit, so the average depends on how long you watched. A tunnel that genuinely improved the path would show a better rate from the first second and keep it. The plateau is the fingerprint, and it is easy to miss if you record only the peak.

Two runs of the same file, one direct and one through the tunnel, are enough to see whether a plateau exists.

Note when the plateau starts, how long it lasts and what rate it holds. Those three values separate a shaper from a congested path, because congestion lets the rate wander while a shaper pins it to one number. If the direct run degrades gradually and the tunnel run holds steady, you are looking at policy rather than physics.

Three Comparisons, One Variable Each

Change one thing per run or you learn nothing. Fetch the same file over the ordinary web path, then over a transfer tool that uses a different port, from a host with comparable capacity and at the same hour. Keep the client machine fixed, since a laptop moving between networks adds a variable you cannot control.

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

Use a file that is already compressed, such as a disk image, so transport compression cannot explain the difference. Then, if you control the server, move its listener to the port you suspect is shaped, update the client profile, and repeat. Should the tunnel now drop to the shaped rate, the limit follows the port rather than the tunnel and the question is settled. Run every comparison twice and keep the plateau figures, not the peaks.

Record the hour too, because a shaper can be time-based and an evening test may disagree with a morning one. Two runs at the same hour are worth more than ten spread across the day.

What This Measurement Cannot Support

It does not show that the tunnel is faster in general, that it compresses anything, or that other ports are unshaped. It describes one transfer on one line during one hour. Limits can be per session, per subscriber or time-based, and an operator can change them without announcing it.

It also does not show that the direct path is faulty. A shaped path works exactly as intended, it is simply limited by policy.

That distinction matters when you write it up. A fault invites a repair ticket, while a policy invites a question about the contract or a decision to work around it. Calling a cap a fault produces a support conversation that starts from the wrong premise. Calling it policy lets you ask a specific question that has a specific answer.

Turn the Finding Into a Support Request

Use the numbers and drop the conclusion. A request stating that big transfers over port 80 hold at around half the expected rate during these hours, with the plateau figures attached, is actionable. A request saying the VPN is faster is not, because it reads as a claim about the tunnel instead of an observation about the line. Attach both runs and their timestamps, then let the operator describe the policy.

Do not push every application into the tunnel just to chase that figure.

The tunnel still costs you a hop, encryption and a fresh set of failure modes, while the limited port remains limited for anything else that uses it. When large transfers have to finish reliably, keep your own note of which port carries the limit. Moving a listener onto port 80 also collides with any web server already bound to it, and that produces a new outage instead of a fix.