Does TCP 443 actually help? Only if the server listens there

TCP 443 is a fallback with a precondition, not a disguise that slips a tunnel past any filter. It helps when the operator already publishes a TCP listener on that port and the path tolerates a connection that stays open for hours. It fails, usually as a timeout, when either of those is missing, and the timeout rarely says which one. Deciding whether to switch takes three questions, and only one of them is about the port number.

A port number is not a transport promise

A port names an endpoint; TCP turns it into an ordered byte stream; OpenVPN decides what travels inside that stream. A web server on the same number uses a completely different application arrangement, so sharing port 443 makes the two look alike to a filter and nothing more. The number is a hint that a filter reads, not a property that changes what the packets contain. Treating the two as the same because they share a port is the mistake behind most of the confusion here.

Middleboxes rarely make a simple allow-or-deny decision about a port. Many inspect the first bytes, some pin a destination, and some reset connections that stay open too long. That is why the same profile can work from one network and time out from another, and why a fallback is worth testing as a supported option rather than trusting as a promise. When a filter examines traffic, the port number is only the first thing it looks at.

Confirm the listener before you touch the profile

The server has to be configured for TCP on the port, and the client profile has to ask for the same transport. Rewriting a UDP profile to request TCP does not create the listener, and the resulting timeout is indistinguishable from a firewall that drops the port. Download the operator's own TCP profile when one exists, because some services publish a separate endpoint and separate identity settings for each transport. Hand-editing is fine for a controlled test and a poor way to guess at a provider's intended configuration.

The two sides of that match appear in the configuration, and the OpenVPN project's link options document both forms. A minimal pair looks like this:

# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443

Three conditions decide whether the fallback pays off

The first condition is that the operator offers the transport at all; without it, nothing else matters. The second is that the path keeps a long-lived session alive, since some networks reset connections that stay open rather than blocking the port outright. The third is whether the fallback is a deliberate exception or a workaround hiding a fault you have not fixed.

Each condition has a cheap check. A failure at any of them looks the same from the client:

Before you compare transports, finish any captive portal sign-in. A network that has not admitted your device blocks both transports, and the comparison then measures the portal rather than the tunnel. Sign in, confirm that ordinary browsing works, and only then start the test.

The cost you accept: TCP inside TCP

TCP retransmits lost segments and preserves their order. When an application that also uses TCP runs inside a TCP tunnel, two recovery layers react to the same loss, and that interaction is what makes the tunnel feel slow on a lossy path. The symptom is delay and jitter rather than a clean failure, which makes it easy to blame the far end. Measure from the client under both transports before drawing a conclusion.

UDP avoids the nesting, which is the main reason operators prefer it and offer TCP only as an alternative. A stable TCP connection is still more useful than an unreachable UDP one, so the comparison is between two real costs rather than between a good option and a bad one. Hold the device and the access network steady while you compare, or the result describes the wrong variable.

Some client features are documented for one transport only, so a fallback profile can quietly drop behaviour you depended on. Read the option's transport requirement before treating the TCP profile as a straight swap.

Faults a different transport does not touch

An expired certificate still needs a clock check or a renewal, and a rejected account still needs the right credentials. Keep the server-identity checks the operator supplied, because a familiar port number authenticates nobody. A port that answers says only that something is listening.

If the tunnel comes up and destinations still fail, the remaining problem is routing or name resolution after the connection, not the transport. Follow that path instead of cycling through ports, which is how an afternoon disappears. The profile tells you which transport to try; it never tells you why the UDP path failed.