Why a VPN Feels Slow During Uploads: Queueing Delay

A backup starts uploading, the transfer counter looks healthy, and the video call turns to mush. The link is not short of bandwidth in the way that number suggests; packets are waiting in a queue somewhere and the interactive ones sit behind bulk data. That is queueing delay, commonly called bufferbloat. A VPN can add its own queue but rarely invents the problem alone.

Bandwidth and delay are different measurements

Throughput answers how much data moves per second, while delay answers how long one packet takes to cross the path. A saturated link can hold a large backlog and still report good throughput, because the queue drains at line rate once the burst ends. Interactive traffic suffers first, since a call needs a packet every few milliseconds rather than a big file eventually. Measuring only a speed-test result therefore hides the symptom that made you look.

Note the direction under load as well. A full upload buffer can delay everything else even while download capacity sits idle.

Measure the round trip under load

Take a baseline on a quiet link, then repeat the same measurement while one controlled transfer runs. Compare the two runs rather than the absolute numbers.

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

The first command samples round-trip time, and the second creates a sustained upload without needing a speed-test service. A baseline that stays flat followed by a loaded run that climbs by hundreds of milliseconds is the signature to look for. Some networks deprioritise ICMP, so treat ping as a clue and confirm with the application's own latency display. Keep the test short on metered links, because a repeatable contrast matters more than a long saturation.

Move the queue to where the bottleneck is

Queue management helps only on the device that actually holds the backlog. Inspect what the interface is doing before adding rules.

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

The show command reports the current discipline plus backlog and drop counters, which tells you whether this interface is the bottleneck or merely passing traffic. Replacing the root discipline with a fair queueing algorithm gives short flows their own turn instead of one FIFO shared with bulk data. Apply it on the router's WAN interface when the router is the bottleneck, not on the tunnel device out of habit. Keep the previous configuration and retest both loaded responsiveness and transfer rate, because a slightly lower bulk rate is a fine trade for usable calls.

What the tunnel changes and what it hides

A VPN adds encryption and another hop, and it also hides individual flows from equipment outside the tunnel. That matters when an upstream device offers per-application prioritisation, since it sees encrypted packets rather than the original conversations. A router that terminates the tunnel itself has a different view and workload and can classify inside it. Neither arrangement removes the queue at the access link, which is usually where the delay accumulates.

If delay does not track load, stop tuning queues and look elsewhere: Wi-Fi conditions, packet-size problems or one poor exit path. Queue settings applied without a measurement merely move the mystery.