Bandwidth needed for 4K over a VPN
Most services list around 25 Mbps for 4K and 5 Mbps for HD. A tunnel typically costs 10 to 30 percent of throughput on a nearby server, so any connection above roughly 40 Mbps carries a single 4K stream through a VPN without difficulty.
4 min read
The numbers here are smaller than most people assume, and that is worth knowing because it changes what to blame when a stream stutters.
What each resolution needs
| Content | Typical sustained bitrate |
|---|---|
| SD | 1 to 3 Mbps |
| HD 1080p | 5 to 8 Mbps |
| 4K | 15 to 25 Mbps |
| 4K with HDR, high-motion | 25 to 40 Mbps |
Services publish minimums around 25 Mbps for 4K, and modern codecs have pushed real bitrates below that. AV1 and HEVC deliver the same perceived quality at meaningfully lower rates than the H.264 those figures were originally set for.
Add the tunnel
A nearby server costs 10 to 30 percent of throughput. So the requirement becomes roughly:
- HD through a VPN: about 10 Mbps of line speed.
- 4K through a VPN: about 35 Mbps.
- 4K HDR through a VPN: about 55 Mbps.
Anyone on a 100 Mbps connection has ample headroom for one stream and enough for two. The arithmetic only gets tight on slow lines or on distant servers where the loss is much larger.
Why streams still stutter
Bandwidth is rarely the reason, which is why increasing line speed so often fails to help.
Jitter and bufferbloat. Adaptive streaming reacts to variation. If your latency triples whenever the link is busy, the player interprets it as congestion and drops to a lower bitrate — visible as a sudden quality drop even though average throughput is fine.
Wi-Fi. A 2.4 GHz link in a crowded building can fail to sustain 25 Mbps regardless of the line behind it. This is the most common cause on televisions, which are often the furthest device from the router.
Device CPU. A streaming stick that has to decrypt a tunnel and decode 4K at once may not manage both. On the Android TV class of hardware, WireGuard's cheaper cipher genuinely matters.
MTU. If large packets are being silently dropped, the stream stalls in a way that looks exactly like insufficient bandwidth.
Server congestion. A busy exit at peak time, which is per-server rather than per-provider.
Diagnosing in order
- Run the speed test on the device that is buffering, with the tunnel up. If it clears 35 Mbps, bandwidth is not the problem.
- Watch latency while a download runs. If it triples, that is bufferbloat and it is fixable on the router with smart queue management.
- Test wired if the device supports it, to eliminate Wi-Fi.
- Try a different server, to eliminate congestion.
- Check MTU if large transfers stall while small requests are fine.
Multiple streams
Two 4K streams through a tunnel need roughly 70 Mbps of line speed, three need about 105. That is where household capacity starts to matter, particularly on upload-asymmetric connections where a video call in the same house competes.
If the tunnel is on the router, this is also where the router's CPU ceiling appears: several encrypted streams at once is exactly the workload consumer router hardware handles worst.
The one thing more bandwidth will not fix
A service that blocks the connection. If a stream refuses to start rather than buffering, that is a proxy detection result rather than a capacity problem, and no amount of throughput changes it.
The distinction is easy: buffering is a performance issue, an error message is a policy one. They have nothing to do with each other and get conflated constantly.
Why the published minimums are conservative
Services quote a figure that has to work for the worst case: a busy scene, an older codec, a device with a small buffer, and a connection that varies. In practice a 4K stream on a modern codec often sits well below the quoted number for most of its running time and spikes during high-motion sequences.
That is why a connection that "should" be enough sometimes fails at exactly the wrong moment. The average is comfortable and the peak is not, and adaptive streaming responds to the peak by dropping quality.
Headroom rather than the exact minimum is what produces a stream that never visibly changes resolution.
Upload matters more than it looks
Streaming is overwhelmingly download, so upload rarely constrains it directly. It constrains the acknowledgements that keep the download flowing, and on an asymmetric connection where someone else is uploading — a backup, a video call, a large file — those acknowledgements queue behind that traffic.
This is another face of bufferbloat, and it is why a household video call can degrade a 4K stream on a connection with far more download capacity than the stream needs.
Testing the right thing
Run the speed test on the device doing the streaming, not on a laptop in another room. A television's Wi-Fi radio, its position, and its CPU are all part of the path, and a measurement from a different device measures a different path.
