The two dimensions they differ along
The first is overhead. Any tunnel adds service data to every packet and processor work for encryption. The less of that work there is, the closer the speed sits to a direct connection.
The second is how much the traffic looks like ordinary traffic. This is not about getting around anything; it is a property of the protocol itself: some look like recognisable service traffic, others are indistinguishable from everyday HTTPS. Indistinguishability is paid for in setup complexity and sometimes in speed.
There is no third dimension called reliability. Reliability is decided by the server and the channel to it, not by the protocol you take to reach it.
The plain ones: SOCKS5 and HTTP CONNECT
The oldest and the cheapest in resources. They carry no encryption at all: SOCKS5 simply passes bytes, HTTP CONNECT opens a tunnel with an HTTP command. Authentication is a username and password for SOCKS5, Basic for HTTP.
When they are chosen: inside a trusted network, for development, for reaching a service that already encrypts on its own. Worth remembering separately: SOCKS5 in the client handles UDP and HTTP CONNECT does not, and that is the only functional difference between them you notice in practice.
SSH Tunnel
A tunnel over an ordinary SSH connection. The encryption is there and it is sound, but SSH was built for a command line rather than for a stream of traffic: it carries a TCP stream inside another TCP stream, and when the network loses packets the two layers of delivery control start working against each other. On a good channel the difference is invisible; on a poor one the drop is plain.
When it is chosen: when the server already exists and you would rather install nothing else on it. SSH is almost certainly running there already.
Shadowsocks
A compromise between simplicity and being unremarkable: a light protocol with honest encryption and no service headers that make it easy to recognise. The classic methods are aes-128-gcm, aes-256-gcm, chacha20-ietf-poly1305 and xchacha20-ietf-poly1305.
One detail worth knowing in advance: the client does not support Shadowsocks-2022. If your server is set up for it, you will need ordinary Shadowsocks.
VMess and Trojan
VMess is a protocol with its own UUID-based authentication and transport parameters packed into the link. Trojan works differently: it impersonates an ordinary HTTPS server and serves a real site to anyone who arrives without the right password.
When they are chosen: both usually arrive as a ready configuration from whoever runs the server. People rarely choose between them deliberately — more often they take what the panel issued.
VLESS, Reality and XTLS-Vision
VLESS is the lightest of the modern ones: it has no encryption of its own, and that is deliberate. TLS encrypts on the outside, and the protocol inside handles routing only, spending no processor time on a second layer over the first.
Reality is a mode in which the server presents the certificate of a real third-party site during the handshake rather than its own. To an observer the connection looks like a visit to that site. Setup is harder than the rest: you have to choose a suitable target domain and align the keys.
XTLS-Vision is an optimisation that removes double encryption inside TLS. The practical effect is less processor load and a higher speed ceiling, especially on weaker devices.
When it is chosen: when you want the most speed from a modern protocol and you can set the server up properly.
AmneziaWG
The only one on the list that runs over UDP rather than TCP, and its properties follow from that. The connection comes up almost instantly, packet loss is handled more gently, and battery use is lower: the protocol holds no permanent connection and does not acknowledge every packet twice.
The other side is UDP as well: where UDP is throttled or heavily restricted it will not work, and no configuration changes that. The obfuscation parameters — Jc, Jmin, Jmax, S1-S4, H1-H4 — are set in the configuration and must match on both ends.
How the choice is made in practice
Most often it is not made at all: the transport arrives inside the configuration, and the decision was taken by whoever set the server up. A deliberate choice comes up in two cases: you are raising a server yourself, or you have several servers on different protocols and are deciding which to assign to which group of programs.
In the second case the sensible rule is simple. Give the lightest available transport to whatever is sensitive to delay. Give the one with the higher speed ceiling to whatever moves large volumes. Everything else can sit on any of them; the difference will not be noticeable.
And in general: changing the transport almost never fixes a slow connection. Check the server itself and the distance to it first.