proto udp or tcp-client: Which One Does Your Server Hear?

A profile that worked last month now times out, and someone suggests switching proto udp to proto tcp-client. Sometimes that is the right move, and sometimes it produces a client that connects to a port where nothing is listening, because the server was never configured for the other transport. The directive describes how your end talks; it cannot create a listener at the far end. Read the profile and the server together before changing either.

Read the transport the selected connection uses

A profile can carry several remote entries, and each one may name its own transport. The client works through them in order, so the line you see first is not necessarily the one that applies.

Find the entry that is actually being tried, then read its transport. Order matters, because the client does not fall through silently. Some builds try the next entry only after a timeout, so a working alternative at the bottom of the file is reached seconds later than you expect. Watch the log for the endpoint being attempted rather than assuming the first line won.

If the file has one proto line near the top and several remotes below it, that line is the default for any remote that does not override it. A local edit to the default does nothing for a remote entry that names its own.

grep -nE '^(remote|proto)\b' client.ovpn

UDP and TCP are not a speed setting

UDP sends datagrams without building an ordered stream, so the tunnel's own traffic is not wrapped inside a second reliable transport. TCP gives you a path through networks that drop or block UDP, at the cost of nested retransmission behaviour that can make a lossy link feel worse.

That is a reachability trade, not a universal ranking. The right choice is the one the network in front of the client allows. A path that drops UDP on the VPN port will never negotiate, however well the profile is written. Test the path, then pick the transport.

Choosing between them by benchmark alone is a mistake, because the answer depends on what the network in front of you permits. A hotel or a corporate proxy may allow outbound TCP on 443 and nothing else, which is why providers offer that variant. It remains an OpenVPN connection on that port, not an HTTPS session, even though the port number is the familiar one.

What tcp-client actually means

The client-side directive names the initiating end of a TCP connection. The server side uses its own listening form, and copying the client's word into a server configuration produces a listener that expects to be dialled rather than one that accepts.

Matching means the two ends agree on transport, not that they share the same string.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Ask the server what it is listening on before you assume the profile is wrong. A UDP listener does not appear in a TCP socket listing, and the reverse is also true, so check the protocol-specific view rather than a generic one.

When the profile imports but never connects

An imported profile that immediately times out usually fails before any authentication. The packet goes to a port with no listener, or the network drops it silently.

Test the path in the simplest possible way: connect to the same host and port with the transport the profile claims, from the same network as the failing client.

If a UDP probe gets nothing and a TCP probe connects, the server is offering the other transport and the profile is simply out of date. If neither responds, the problem is upstream of the transport choice and no edit to the profile will fix it. Distinguishing those two cases takes a minute and saves an hour of certificate debugging that was never relevant.

Record the working transport

Once a combination works, write it down with the server, port and protocol, and note which network it was tested from.

The next person to hit a timeout will otherwise try the same experiment in the other direction, and possibly change a server that was fine.

If the provider publishes both variants, keep both files and label them by the network they suit. Two clearly named profiles prevent the accidental mixture of a client transport with a server listener that was never configured for it.