Does a VPN slow your streams? What actually matters

The usual claim is that a VPN costs you bandwidth. For live streaming that is mostly the wrong worry. A 1080p live channel is a few megabits, and any VPN worth using carries that without noticing.

3 other things matter more.

Route, stability, and whether the tunnel is used at all#

Route length. Your traffic now goes to a VPN endpoint and then to your provider, instead of straight there. If the endpoint is in another country and your provider is 2 countries the other way, you have added real distance. Higher latency does not reduce throughput on a steady stream. It does make every recovery slower, because every recovery path in the player is time-bounded rather than attempt-bounded: 8 seconds to reach first presentation on a retry, and a handover abandoned after 6. A longer round trip spends more of a fixed budget. We have measured this mattering: with both opening graces at 8 seconds, a total byte stall spent 8 of its 15.7 seconds restarting an address that was still dead, which is why a retry now gets 4 seconds of patience against 8 for a cold open.

Pick an endpoint near your provider, not near you. This is the single most useful change and the opposite of what most people do.

Stability, not speed. A stream is a continuous read that has to keep up in real time. A tunnel that averages high throughput but drops packets in bursts is worse for live television than a slower, steady one. Bandwidth tests measure the first and say nothing about the second. A tunnel that drops quietly is worse still: a stream that stops sending while its socket stays open produces no player event at all, so detection is a timer over byte counters, and the symptom is nothing happening.

Whether the tunnel is used at all. This is the one that produces confusing results, and it has a specific shape when you use the app's own connection profiles rather than a system-wide VPN.

The app's own connection profiles#

A named connection profile carries an HTTP or SOCKS5 proxy, a DNS override (system, plain UDP, or DNS over HTTPS), a udpxy relay and an HTTP identity, and it binds either to one source or as the app default. Two things about how it works show up as behaviour.

Media goes through a local relay. I did not expect to need one. The player has proxy support of its own and that was the obvious route; it turned out non-functional for this purpose. The reason is structural: the player fetches manifest-referenced URIs itself, so a proxy applied to the top-level request does not cover the segments it goes on to request. A loopback relay that rewrites HLS manifests does.

without a profile   player -> provider
with a profile      player -> loopback relay -> proxy -> provider
                    (relay rewrites the manifest so segments follow the same path)

It fails closed. If the relay cannot carry a scheme, playback fails rather than falling back to a direct connection. That is the correct trade: a privacy setting that silently stops applying is worse than one that visibly stops working.

So a channel that worked before you configured a profile and fails after it is not necessarily a broken profile. It may be a stream refusing to leak. Check whether other channels from the same source still play. If they do, you have found a scheme the relay does not carry, not a broken configuration.

If it got slower after you turned a VPN on#

Work through these before blaming the tunnel.

Move the endpoint closer to your provider and retry the same channel. If that fixes it, the route was the problem.

Check whether you are still inside your connection allowance. Some providers count a connection from a new address as a new session while the old one has not timed out, so switching endpoint mid-evening can leave you holding 2 slots on a 2 slot line for a few minutes. Max connections covers that.

Give the player a minute before judging. Buffering starts at 1200 milliseconds of network cache and 800 of live cache, and when the player detects repeated rebuffering it raises its own floor by 1000 milliseconds per verdict up to 5000. An episode only counts below 62 percent cache and ends at 88, with 4 episodes in 60 seconds declaring a loop, because raw counting flagged healthy streams at segment boundaries. A connection that was marginal at first can settle once that adaptation has happened.

Storage and diagnostics#

Profile credentials are stored through the platform's data protection API, and a test greps the entire application data tree after a round trip to prove no plaintext escapes. Relay session tokens are released when playback stops, so a token cannot outlive the stream it was minted for. A 9 step diagnostic ships with the feature and is the right first stop when a profile misbehaves. Several parts are still unfinished and named as such: multiview and handover source plumbing, per-channel identity into playback, and recording identity among them.

Where that leaves you#

A VPN does not meaningfully cost you bandwidth for live television. It can cost you recovery time, and a badly placed endpoint can cost you a lot of it. Choose the endpoint by proximity to your provider and you will usually not notice it at all.

If the stuttering predates the VPN, the buffering checklist starts by classifying which of 9 faults you have, which is faster than changing network settings.