Start with UDP: it is usually better suited to video, calls and gaming. Switch to TCP if the network blocks UDP; where these modes sit among other options is explained in the overview of virtual private network (VPN) protocols.
How UDP and TCP differ
The transport determines how packets travel between your device and the server. The User Datagram Protocol (UDP) sends them without establishing a connection and does not itself retransmit lost data. The Transmission Control Protocol (TCP) verifies delivery, retransmits lost data and hands it to the recipient in order. Simply put, TCP adds waiting in exchange for delivery.
| Property | UDP | TCP |
|---|---|---|
| Packet loss | The transport does not resend it | The transport retransmits |
| Order of delivery | Not guaranteed | Preserved, sometimes at the cost of delay |
| Main VPN use case | Video, calls, gaming, everyday connections | Networks where UDP is unavailable |
For a call, fresh audio is more useful than a late fragment. The browser or application inside the tunnel can handle reliable delivery itself: UDP on the outside does not cancel their checks.
OpenVPN supports both transports: udp and tcp-client on the client side. In the OpenVPN 2.6 manual, UDP is listed as the default mode for which the protocol is optimised. The standard OpenVPN port is 1194, but a service may use other ports.
How UDP and TCP differ
Why TCP inside TCP slows a VPN down
When the application uses TCP and the OpenVPN tunnel also runs over TCP, two independent retransmission mechanisms appear. This is known as TCP over TCP.
When an outer packet is lost, the tunnel delays subsequent data until the gap is filled. Meanwhile, the application's inner connection may decide that its data has also been lost, trigger its own retransmissions and slow its sending rate. Two layers of waiting interfere with each other. On a congested line this leads to pauses and a drop in usable throughput.
Why TCP inside TCP slows a VPN down
When the application uses TCP and the OpenVPN tunnel also runs over TCP, two independent retransmission mechanisms appear.
Two layers of waiting interfere with each other.
A UDP tunnel adds no outer retransmission mechanism.
A UDP tunnel adds no outer retransmission mechanism. But UDP is not always faster: the result also depends on the server and the route. These factors are examined in the article on choosing a fast VPN protocol.
The VPN itself checks the connection with service packets. Behind network address translation (NAT), whereby a router maps devices to an external address, periodic keepalive packets keep the mapping alive for return traffic. In WireGuard this setting is off by default; if needed, the documentation suggests an interval of 25 seconds.
When to switch to TCP
TCP is more likely to pass through the strict filters of public and corporate networks. The UK's National Cyber Security Centre also notes differences in how VPNs traverse NAT and filters in its guidance for organisations. Its recommendations are aimed at corporate networks.
TCP on port 443 may help if the server supports that option. The port number itself does not make VPN traffic look like ordinary web traffic and does not guarantee bypassing a block.
| What happens | Possible cause | What to try | Limitation |
|---|---|---|---|
| UDP won't connect, TCP works | The network restricts UDP | Stay on TCP | The symptom does not prove the cause |
| On TCP, calls keep stuttering | Retransmission delays under packet loss | Switch to UDP | The network must allow it |
| Connection drops after idling | NAT mapping expires | Check the keepalive in the profile | Changing transport is not always needed |
| A long-lived UDP connection breaks off | A restriction on UDP or a specific port | Check for an available TCP option | There may be other causes of drops |
Hysteria2 and VLESS: two paths for different networks
Hysteria2 runs on top of QUIC, a secure transport protocol that uses UDP. Its disguise as HTTP/3 web traffic does not change the transport. If UDP is blocked entirely, Hysteria2 will not connect. Changing ports helps only when individual ports are restricted.
This is where the range of connection types that CitadelVPN offers in a single subscription comes in handy: if UDP will not pass, the same subscription includes a VLESS path over TCP, and if TCP feels slow, there is a UDP path via Hysteria2. The service lists Hysteria2 and variants of the VLESS proxy protocol with TCP and gRPC transports. The label "VLESS tcp" corresponds to the transport that Xray's documentation has renamed to RAW; gRPC carries data over HTTP/2 on top of TCP.
Update your subscription in a compatible client. Choose an available VLESS TCP connection if UDP will not connect. If TCP feels laggy, try Hysteria2 on a network where UDP is allowed. Passing any particular filter is not guaranteed; check profile and port availability in your own subscription.
Frequently asked questions about choosing a transport
Is TCP more secure than UDP?
No. In OpenVPN, with identical security settings, the choice of transport does not strengthen encryption: what differs is the order of packet delivery. Reliable delivery and content protection are separate properties.
Why doesn't WireGuard have TCP?
The developers deliberately excluded TCP because of the performance problems of TCP over TCP. External wrappers exist, but they are not part of WireGuard proper.
What does Adaptive in OpenVPN Connect mean?
Adaptive picks a transport from the addresses listed in the connection profile. It does not add a TCP server if the profile contains only UDP, nor does it cycle through every existing VPN protocol.
Which mode to keep
Stick with UDP if the connection works: for calls, video and gaming it usually avoids unnecessary waiting. Choose TCP when UDP is unavailable. If UDP is blocked outright, Hysteria2 will not help either; you need a working TCP path. Where to find the relevant setting or pick another profile is shown in the guide to changing your VPN protocol.