UDP or TCP for a VPN?
Use UDP unless the network forces you not to. A tunnel carried inside TCP stacks two reliability layers, so a single lost packet triggers retransmission at both levels and throughput collapses on a lossy link. TCP mode is a compatibility feature, not a performance option.
4 min read
The choice only exists for OpenVPN and a few SSL VPNs. WireGuard is UDP only, with no fallback, so this question does not arise there. Where the choice does exist, the answer is UDP unless something is stopping you.
What each one does
UDP sends packets and does not care what happens to them. No handshake, no acknowledgements, no retransmission, no ordering.
TCP guarantees delivery and order. It acknowledges, retransmits what is lost, and slows down when it detects congestion.
A VPN carries whatever your applications send. Those applications already chose their own transport — a web page over TCP, a video call over UDP — and they handle their own reliability.
The TCP-over-TCP problem
If the tunnel is UDP, a lost packet is handled once, by whatever protocol was inside it. TCP inside the tunnel notices, retransmits, and adjusts.
If the tunnel is TCP, a lost packet is handled twice. The tunnel's TCP retransmits it, and while it does, the inner TCP is also waiting. The inner connection sees a delay, assumes congestion, and slows down. The outer connection then retransmits more aggressively.
The two control loops interact badly. The classic description of this is titled "Why TCP over TCP is a bad idea", and the effect it describes — a meltdown where throughput collapses far below what the link can carry — is observable on any lossy connection.
On a clean, low-latency link the effect is small. On mobile data, on distant servers, or on any connection with a few percent loss, it is dramatic.
Head-of-line blocking
TCP delivers bytes in order. If one segment is lost, everything behind it waits, even though it has already arrived.
Inside a tunnel that means a single lost packet stalls every connection passing through it, not just the one that lost the packet. Your video call freezes because someone else's download lost a packet. With a UDP tunnel each inner connection handles its own loss independently.
So why does TCP mode exist
Because some networks block UDP.
Corporate networks that permit only TCP 80 and 443. Hotel Wi-Fi with an appliance that drops unusual UDP. Some mobile roaming partners. On those networks a UDP tunnel does not connect at all, and a slow tunnel beats none.
OpenVPN over TCP 443 has a second property: it is very hard to distinguish from HTTPS without deep packet inspection. Blocking it means blocking a pattern that describes the whole web.
The practical rule
| Situation | Transport |
|---|---|
| Normal home or mobile use | UDP |
| Streaming or video calls | UDP |
| Gaming | UDP |
| Network blocks UDP | TCP 443 |
| Deep packet inspection blocking VPNs | TCP 443, plus obfuscation |
| Connection is lossy | UDP, definitely |
How to tell which you are on
Most clients show it in the connection details or the log. In an OpenVPN config
the line is proto udp or proto tcp, and the port usually gives it away —
1194 is the UDP default, 443 is almost always the TCP fallback.
If a connection is unexpectedly slow, checking this is worth thirty seconds. A client that silently fell back to TCP because a UDP attempt timed out is a common and unannounced cause of poor performance.
Measuring the difference
Run the speed test on UDP, then force TCP in the client and run it again from the same place to the same server. On a good connection expect UDP to be somewhat faster. On a poor one expect the gap to be large.
Watch latency and jitter as well as throughput. TCP mode's effect on jitter is usually more noticeable in use than its effect on the download number.
What about QUIC
QUIC carries a reliable, ordered stream protocol over UDP, and it solves head-of-line blocking by keeping streams independent. A few VPN products use QUIC or something like it as a transport, which gets the blocking resistance of looking like ordinary web traffic without the TCP-over-TCP penalty.
It is a genuinely better answer to the problem TCP mode solves. It is not yet common in consumer VPN clients, so for now the choice remains the one above: UDP by default, and TCP when a network leaves no alternative. On Windows and elsewhere, a client that automatically falls back should tell you when it has.
