Somewhere in your VPN app's settings there is a protocol option, and next to it a choice between UDP and TCP. Most people never touch it, which is usually the right call - until a connection refuses to establish on a hotel network and the setting suddenly matters. This guide explains what the two actually change, why UDP is the correct default, and the one situation where TCP earns its place.
The short answer
Use UDP. It is faster, it has lower latency, and it is what every modern VPN protocol reaches for first. Change to TCP only when UDP does not get you a connection at all.
That is the whole decision for most people. The rest of this article is about why - and about a trade-off that is widely stated backwards.
What each one is doing under the tunnel
A VPN takes your traffic, encrypts it, and wraps it inside another connection to the VPN server. UDP and TCP describe how that outer wrapper behaves.
UDP sends packets and does not track what happens to them. There is no handshake to establish, no acknowledgement to wait for, no automatic re-sending of anything lost. That sounds careless, and for a VPN it is exactly right: the traffic inside the tunnel already has its own reliability machinery, and the applications sending it already know how to react to loss.
TCP does the opposite. It establishes a connection, numbers everything, waits for acknowledgements and re-sends whatever goes missing. Every packet arrives, in order, or the connection reports a failure.
Why "reliable" is the wrong reason to pick TCP
The obvious reading is that TCP is the safer choice because it guarantees delivery. In a VPN this reasoning inverts, and it is worth being precise about why.
The traffic you are tunnelling is, most of the time, already TCP - web pages, APIs, file transfers. Wrap TCP inside TCP and you now have two independent retransmission timers stacked on each other. When the link starts dropping packets, the outer connection begins re-sending, and the inner connection - which has no idea it is inside a tunnel and sees only its own delays - starts re-sending the same data too. Each layer interprets the other's recovery attempts as further congestion and backs off harder.
This is the TCP-over-TCP problem, and its signature is distinctive: rather than degrading gracefully as loss increases, throughput falls off a cliff. A connection that would merely stutter over UDP can stall completely over TCP.
UDP avoids this by not competing. Loss is handled exactly once, by the layer that understands what the data means.
The one job TCP does better
TCP's advantage is not performance. It is getting through.
VPN traffic over TCP port 443 shares a port with ordinary HTTPS. A firewall that allows web browsing but blocks unfamiliar traffic will generally let it pass, because from the outside it looks like someone loading a website. That is why the TCP option exists, and it is genuinely useful in specific places:
- Hotel, airport and café Wi-Fi that permits only ports 80 and 443
- Corporate or campus networks where UDP is filtered by policy
- Any network where the VPN simply will not connect and you have ruled out the obvious causes
Be clear about what this buys you, though. Looking like HTTPS to a port-based filter is not the same as being unidentifiable. Deep packet inspection examines the shape of a connection's handshake rather than its port number, and it is not fooled by the switch to TCP. Networks that inspect at that level require dedicated obfuscation, which is a different feature entirely - see our guide to obfuscated VPN servers for how that works.
What this means per protocol
| Protocol | Transport | Practical consequence |
|---|---|---|
| WireGuard | UDP only | Fastest in general use. On a network that blocks UDP it will not connect, and no in-app setting changes that. |
| OpenVPN | UDP or TCP | The flexible one. UDP by default; the TCP-443 fallback is its main advantage in 2026. |
| IKEv2/IPsec | UDP (ports 500, 4500) | Fast and very good at surviving network changes, but those ports are easy to block. |
WireGuard being UDP-only is a design decision, not a gap. Keeping the protocol small is much of why it is fast and auditable, and refusing TCP sidesteps the stacked-retransmission problem by construction. The cost lands on the user exactly once - on a network that filters UDP, where the only routes forward are a provider's obfuscation feature or falling back to OpenVPN over TCP.
A practical order of operations
- Leave it on UDP (or automatic) and forget the setting exists.
- If the connection fails, first rule out the ordinary causes: wrong credentials, an expired subscription, a captive portal you have not accepted yet.
- Then try TCP, ideally on port 443.
- If TCP on 443 also fails, the network is inspecting rather than merely filtering. That calls for obfuscation, not another transport setting.
- Switch back to UDP once you are on a normal network. TCP is a workaround, not a destination - leaving it on quietly costs you speed everywhere else.
The trade-off, stated plainly
UDP is faster because it does less. TCP connects in more places because it looks like the web. And if your tunnel establishes on either of them but nothing flows afterwards, the transport is no longer the suspect, four pings locate the real cause. Neither is more secure than the other: your encryption does not change with this setting. The tunnel's cryptography is the protocol's business - UDP versus TCP only decides how the encrypted packets are carried, and how badly things degrade when the network beneath starts losing them.
Get NordVPN at its best price
2-year plan · audited no-logs (PwC) · 30-day money-back
