Culvert VPN

Why VPN apps try port 443

Port 443 is where HTTPS lives, so nearly every network allows it. That is why VPN apps try it, over UDP first and then wrapped in TLS over TCP.

Public and restrictive Wi-Fi · 4 min read · By Culvert VPN

VPN apps try port 443 because it is the port HTTPS uses, and a network that blocks it cannot load a website. Hotels, campuses, offices and cafés that close most ports leave 443 open, so a VPN that can run on it connects where one on its default port cannot. A well-built app uses this twice: first by sending WireGuard's UDP packets to port 443, and then, if the network drops UDP, by wrapping the VPN inside a real TLS connection on TCP port 443 that the network handles like any other web session.

What a port is, briefly

An IP address identifies a device; a port identifies which program on that device should receive a packet. Web servers listen on port 443 for HTTPS and port 80 for plain HTTP. Email, DNS, games and VPN protocols each have their own conventions. WireGuard's default is UDP port 51820. OpenVPN's is UDP 1194. IKEv2 uses UDP 500 and 4500.

A firewall filters largely by port and by whether the packet is TCP or UDP. A network that wants to allow web browsing and nothing else can do it with two rules: allow TCP to 80, allow TCP to 443. That is a common configuration on hotel and guest networks, and it is why a VPN on port 51820 simply hears nothing back.

Why 443 is nearly always open

Every HTTPS website is reached over TCP port 443. Blocking it would break every secure page on the internet, so no network intended for guests does. It is the one port that is open on practically every network, and that makes it the natural port to try on a network that filters the others.

There is one caveat. Being open on TCP does not mean being open on UDP. Some networks allow UDP 443 too, because a newer web protocol, HTTP/3, runs over it and blocking it degrades video calls and some large sites. Others drop all UDP and let HTTP/3 fall back to TCP. That distinction is exactly why a VPN app tries 443 in two different ways.

The first try: WireGuard over UDP on port 443

WireGuard is the quickest VPN protocol on a phone, and it does not care which port it uses. An app can run it on 51820, on 443, or on 53, the DNS port, and the server can listen on all of them at once. Trying more than one is cheap, since each attempt is a single handshake packet with a short timeout.

On a network that allows UDP 443 for HTTP/3, WireGuard on that port connects at full speed, and the app never has to do anything slower. The UDP-dropped post covers what happens when the network does not.

The second try: VPN inside TLS on TCP 443

When UDP gets no answer at all, the app moves on to a transport that uses TCP 443 the way a browser does. It opens a TLS connection to the VPN server, completes an ordinary TLS handshake, and then sends the VPN's packets inside that encrypted connection. To the network's equipment, this is an HTTPS session to a server: the same shape, the same port, the same handshake.

That is what "TLS-wrapped" means, and the VPN over TLS post goes into how the wrapping works. The important properties are that it uses only what a web browser uses, so it connects wherever browsing works, and that the traffic inside is still encrypted by the VPN protocol, so the TLS layer adds a wrapper rather than replacing anything.

What it costs

The TLS transport is slower than WireGuard over UDP, and the reason is TCP, not the port. TCP ensures that data arrives in order and retransmits anything lost. A VPN carrying its own traffic inside a TCP connection ends up with two layers doing loss recovery, and when a packet is lost the inner and outer layers can both wait, which on a lossy Wi-Fi link shows up as stalls. UDP has no such machinery, so WireGuard handles loss itself, once, and stays quick.

MethodTransportTypical result on a filtered networkSpeed
WireGuard on UDP 51820UDPOften blocked by port filteringQuickest
WireGuard on UDP 443UDPWorks if the network allows HTTP/3Quickest
VPN wrapped in TLS on TCP 443TCPWorks wherever HTTPS worksSlower, more stalls on loss
IKEv2 on UDP 500 and 4500UDPBlocked wherever UDP isQuick, rarely reached

The UDP vs TCP post explains the loss-recovery problem properly.

Why the order matters

An app that started with TCP 443 would connect almost everywhere and be slower than necessary almost everywhere. An app that tried only UDP would be quick at home and silent in a hotel. The right design is to try the quick methods first with short budgets, then the compatible one, and keep whichever carried traffic, without asking the user to choose. On an open network that costs nothing; on a filtered one it costs a few seconds.

Culvert VPN does this automatically, trying WireGuard on several UDP ports including 443 before moving to its TLS transport on TCP 443, and never shows a protocol picker, on Google Play.

Questions people also ask

Is a VPN on port 443 the same as HTTPS?

Not quite. UDP on port 443 is just a port choice. A TLS-wrapped VPN transport on TCP 443 really is a TLS connection, the same kind a browser opens, with VPN traffic carried inside it.

Is port 443 slower for a VPN?

The port makes no difference. What costs speed is TCP, because carrying a VPN inside a TCP connection means two layers of loss recovery. WireGuard over UDP on port 443 is as quick as on any other port.

Which port does WireGuard normally use?

51820 by default. VPN servers often listen on several, including 443 and 53, so that a network which allows only common ports still has one the handshake can use.