Buffering with a VPN on: is the VPN the cause?

Adaptive streaming downloads video in short segments and keeps a buffer of several seconds ahead of what you are watching. Buffering happens when that buffer empties, and the buffer empties when segments arrive late — not necessarily when average bandwidth is low.

That distinction is why "I have 300 Mbps and it still buffers" is a coherent sentence.

Check the numbers first

4K needs about 25 Mbps sustained, HD about 5 to 8. Add 10 to 30 percent for a tunnel on a nearby server and 4K needs roughly 35 Mbps of line speed.

Run the speed test on the device that is buffering, with the tunnel up. If it comfortably clears the figure above, bandwidth is not your problem and no amount of extra capacity will fix it.

Cause one: jitter, not throughput

Adaptive players react to variation. If segments sometimes arrive in 200 milliseconds and sometimes in two seconds, the player concludes the connection is congested and drops to a lower bitrate — or runs dry while waiting.

The usual source is bufferbloat: an over-buffered router that lets latency climb to hundreds of milliseconds whenever the link is busy. Test by measuring latency during a download. If ping triples, that is it, and smart queue management on the router fixes it for everything at once.

Cause two: Wi-Fi

The device that buffers is usually the television, and the television is usually the furthest thing from the router.

A 2.4 GHz link in a dense building can fail to sustain 25 Mbps regardless of the line behind it. Test wired once if the device supports it. That single test eliminates or confirms the most common cause.

Cause three: a congested exit

A busy VPN server at nine in the evening drops packets when its uplink saturates. The signature is time-of-day dependence: fine in the morning, poor at peak.

Test by connecting to a different server in the same country from the server list. If the neighbour is clean, the first was busy.

Cause four: MTU

If large packets are silently discarded, segments arrive incomplete and stall. This produces buffering that looks exactly like insufficient bandwidth while the speed test reports fine numbers, because a test with small transfers may not trigger it.

Set the tunnel MTU to 1380 and retest.

Cause five: device CPU

A streaming stick decrypting a tunnel and decoding 4K at once may not manage both. Cheaper hardware is where this appears, and the symptom is a stream that holds at a lower resolution rather than stopping.

WireGuard's cheaper cipher genuinely helps here, and moving the tunnel to the router shifts the work off the stick — at the cost of moving it to hardware that is often slower still.

Cause six: the service's own delivery

Content delivery networks pick an edge based on where your connection appears to come from. With a tunnel up, that may be an edge near the VPN exit rather than near you, and if the exit is far away the path is long.

Nothing to configure. Connecting to a nearer server usually resolves it, which is another reason nearest-by-default is the right habit.

The order to check

1. Speed test on the buffering device with the tunnel up.
2. Latency during a download, for bufferbloat.
3. Wired instead of Wi-Fi.
4. A different server.
5. MTU at 1380.
6. Watch the device's CPU if it exposes it.

When it is not buffering at all

If the stream refuses to start rather than stopping partway, that is a block rather than a performance problem — an address classification result, not a bandwidth one. The two produce similar frustration and have nothing else in common.

How adaptive streaming decides to drop quality

Worth understanding because it explains why buffering and quality drops are the same phenomenon at different severities.

The player measures how long each segment took to download and estimates available throughput. If the estimate falls, it requests the next segment at a lower bitrate. If the estimate falls sharply or a segment stalls entirely, the buffer empties before the next one arrives and playback pauses.

So a connection that is fast on average but erratic produces worse results than one that is slower and steady. That is the opposite of the intuition most people bring to it, and it is why the jitter measurement matters more than the download number.

Multiple devices in one household

Two 4K streams through one tunnel need roughly 70 Mbps of line speed, and if the tunnel is on the router they also share one CPU core doing the encryption.

That is the case where a router's ceiling shows up as buffering rather than as a slow speed test, because the test runs alone and the real workload does not. Testing with the household's normal evening load running is the only way to see it.

When to stop troubleshooting

If the same content on the same device buffers with the tunnel off, the VPN was never the cause. That single comparison is worth doing first, and it resolves a surprising share of reports before any of the six checks above are needed.