Culvert VPNFast at home, slow at work: read the network, not the app
When the same VPN is fast on one network and slow on another, the slow network is almost always filtering UDP, forcing the app onto a slower TCP method.
When the same VPN app on the same phone is fast on one network and slow on another, the difference is nearly always the network, and the usual mechanism is this: the slow network filters UDP, so the app cannot use its quick UDP-based method and drops to a slower one that runs over TCP, often on port 443 so it looks like ordinary web traffic. Same app, same server, different transport. Offices, campuses, hotels and some cafés do this by policy; home Wi-Fi and mobile data rarely do.
Why UDP is the fast path
Modern VPN protocols run over UDP because UDP does nothing but deliver packets. The VPN's own encryption and the applications inside the tunnel handle reliability, so a lost packet costs one retransmission at the application layer and nothing else. WireGuard, for example, runs over UDP only.
When UDP is blocked, the only way through is to wrap the tunnel in a TCP connection, usually dressed as TLS on port 443 so that a filter that allows web browsing allows it too. That works, and on a filtering network it is the difference between connecting and not, but it is slower for a structural reason. TCP inside TCP means two layers are each trying to make sure every byte arrives: when a packet is lost, the outer connection stalls to recover it, every inner connection stalls with it, and then the inner connections notice their own timeouts and retransmit as well. The effect is small on a clean link and severe on a lossy one, which is exactly what a crowded office Wi-Fi is. The UDP vs TCP post goes into the mechanism.
How to confirm it is the transport
- On the slow network, note how long the app takes to connect. A UDP handshake completes in well under a second; if the app sits on "connecting" for ten seconds or longer and then connects, it burned its UDP budget and fell back.
- Run a speed test through the VPN on the slow network and note down and up.
- Switch to mobile data, connect the VPN again, and run the same test. If this is several times quicker and the connection came up at once, the Wi-Fi is the difference.
- Turn the VPN off on the slow network and run the test once more. If the network is fast without the VPN and slow with it, the network is handling the tunnel differently from ordinary traffic. If it is slow either way, the network is simply slow.
A connect screen that shows current throughput makes this easier: with the same app doing the same download on both networks, the numbers tell the story directly.
Other things a network can do
UDP filtering is the common cause, but a network can also slow a tunnel in ways that look similar.
- Per-device bandwidth caps on guest networks apply to everything, VPN or not; step 4 above catches this.
- Traffic shaping that throttles encrypted or unrecognised flows while leaving web browsing alone. The VPN's TCP-on-443 method often escapes this because it looks like a website.
- A small MTU on the network, common with some corporate and hotel gateways, which causes large packets inside the tunnel to be fragmented or dropped. It presents as some sites loading and others hanging rather than as uniform slowness; the MTU post covers it.
- Crowded 2.4 GHz Wi-Fi with high packet loss, which hurts a TCP-wrapped tunnel far more than a UDP one, for the reason above.
- A congested uplink shared by a whole building, which has nothing to do with the VPN and is the same for everyone.
What you can do about it
On a network you do not control, the options are limited but real. Mobile data, or a hotspot from your phone, avoids the filtering entirely. If it is your workplace and the policy is deliberate, the network team can allow UDP to the VPN's ports, though most will not. Choosing a nearer city helps a little with latency but does not change the transport, so fix that first. And on a genuinely lossy Wi-Fi, moving closer to the access point or switching to the 5 GHz band lowers the packet loss that makes the TCP fallback suffer.
What you cannot do is make a TCP-wrapped tunnel as fast as a UDP one on a network that has decided to block UDP. The fallback exists so that you have a connection at all there, and the UDP blocked post explains what the app is doing when it takes it. For slowness that is the same on every network, the causes are different, mostly distance and server load, and they are in why your VPN is slow.
Culvert VPN tries a UDP method first on every network and moves to its TCP-based methods only when the network filters it, switching automatically and showing no protocol names, with live down and up throughput on the connect screen so you can see the difference for yourself; it is on Google Play.
Questions people also ask
Why does the connection take longer to establish on the slow network?
The app tries its UDP method first and only moves on when that method's time budget runs out. A network that drops UDP silently, rather than refusing it, makes the app wait out the whole budget before it falls back, and the longer connect is the sign that it did.
Would choosing a nearer server help?
Not much, if the transport is the problem. A nearer server lowers latency, but a TCP-based method on a filtering network is limited by how the network handles it, not by distance. Fix the transport first, then think about distance.
Is a slow VPN on office Wi-Fi a sign the network is watching me?
It is a sign the network filters UDP or VPN ports, which most managed networks do as a matter of policy. Your traffic inside the tunnel is still encrypted; the network sees a slower, TCP-shaped stream to one server and nothing more.