OpenVPN TCP vs UDP: Which Should You Use (2026)

Use OpenVPN UDP by default — it is meaningfully faster and handles packet loss better. Switch to OpenVPN TCP on port 443 only when the network blocks UDP (hotels, offices, filtered countries), because TCP-over-TCP adds latency and can melt down on lossy links. Speed: UDP. Reachability: TCP 443.

OpenVPN is the only mainstream VPN protocol that lets you choose its transport — and the choice matters more than any other setting in the config. We run both on every node of our fleet; here is the operational reality.

The one-table answer

OpenVPN UDP OpenVPN TCP (443)
Throughput Higher (often 30–50%+) Lower
Latency Lower Higher, grows under loss
Lossy links (mobile, long-haul) Degrades gracefully Can collapse (TCP meltdown)
Blocked networks Often dropped Almost always gets through
Looks like Opaque UDP Ordinary HTTPS

Why is UDP faster for a VPN tunnel?

A VPN tunnel does not need a reliable transport, because the traffic inside it already brings its own reliability. Your browser's HTTP/2 connections, your downloads, your video calls — each already handles ordering and retransmission end-to-end. UDP just carries the encrypted packets and lets the inner protocols do their jobs.

Put the tunnel on TCP and you have two reliability layers stacked: the outer TCP retransmits a lost packet, the inner TCP's timer also fires and retransmits, queues build, and effective throughput dives. On a clean line you may only lose 20–30%; on a lossy mobile or intercontinental link the stacking can spiral until the tunnel is unusable — the well-documented TCP-over-TCP meltdown.

So why does TCP 443 exist at all?

Because it connects when nothing else will. To a firewall, OpenVPN TCP on port 443 looks like a long-lived HTTPS session — the one kind of traffic no network can afford to block. In our fleet telemetry, connection success on hostile networks (hotel captive portals, corporate guest Wi-Fi, heavily filtered countries) is dramatically higher on TCP 443 than on any UDP variant. That is why it stays a first-class option in our apps even though WireGuard and OpenVPN UDP outrun it.

One detail worth knowing if you run your own server: modern OpenVPN also multiplexes nicely behind a port-share setup, letting 443 serve both VPN handshakes and a real HTTPS service — handy, but it makes TLS handshake debugging more confusing when it breaks.

Practical rules

  1. Default to UDP (or WireGuard, which is UDP-only and faster still — comparison here).
  2. Can't connect, or UDP crawls? Switch to TCP 443. Hotel, airport, office, festival networks: TCP is your escape hatch.
  3. Gaming or calls on TCP? Expect added latency. If you must stay on TCP, prefer a nearby server to keep the base RTT low.
  4. Never tunnel-in-tunnel. Running a TCP VPN inside another TCP VPN doubles the meltdown math.

In the Secure Paid VPN apps this is a one-tap switch — Settings → Protocol — and the app remembers which transport worked on which network, so the fallback happens once, not every day.

Frequently asked questions

Why is OpenVPN TCP slower than UDP?

Your applications already run TCP. Tunneling TCP inside TCP makes two reliability layers fight: both retransmit on loss, timers stack, and throughput collapses on bad links — the classic "TCP meltdown."

Why does OpenVPN TCP use port 443?

Port 443 is HTTPS. Firewalls that block unknown traffic almost never block 443, and OpenVPN TCP traffic on it is very hard to distinguish from ordinary secure web browsing.

Which port should OpenVPN UDP use?

The default 1194 is fine on open networks. Some providers also listen on UDP 443 or 53 to slip past sloppy filters that only check port numbers.

Keep reading