The short answer: the path through a server is longer than the direct one, and that is the price of the route, not a fault. Distance to the server and its load matter most; the protocol noticeably less; the client barely at all. Check them in that order.
What happens to the traffic along the way
Without a tunnel, a packet goes from the phone to the service by the shortest route your provider built. With a tunnel it goes to your server first, is decrypted there, leaves for the service from there — and the whole answer comes back the same way. The road grew longer by exactly the distance to the server, there and back.
Two smaller things add to that, and together they cost percentages rather than multiples: the housekeeping data every packet acquires, and the processor work of encryption. On a modern phone the second is barely noticeable.
Distance is the first thing to look at
Latency grows with distance, and nothing gets around it: a signal cannot travel faster than the length of the route allows. A server in a neighbouring country will almost always feel faster than one on another continent, even if the second has a formally wider channel.
It shows most where the response, not the throughput, is what matters: messengers, calls, games, any page that pulls in dozens of small files. Downloading one large file survives latency far more easily.
How many people are on the server, and what channel it has
The second most important factor is how much traffic the server serves at once. The machine has one channel, and it is shared between everyone going through it. Hence the familiar picture: fast in the morning, slow in the evening, with nothing about the server changed.
If the server is your own, this is checkable: look at channel and processor load at the moment the speed drops. If the access came from elsewhere, comparison is what is left: another server from the same list at the same time of day tells you more than any single measurement.
The protocol: where it really matters
There is a difference between transports, but it is smaller than the one distance makes. The most noticeable is SSH: it carries a TCP stream inside another TCP stream, and when the network loses packets the two delivery-control layers start working against each other. On a good channel you will not see it; on a bad one the drop is clear.
At the other end is AmneziaWG: it works over UDP, the connection comes up almost instantly, losses are handled more gently, and battery use is lower. The flip side is also UDP — where it is throttled, the transport will not work.
The lightest of the modern ones is VLESS: it has no encryption of its own, deliberately, and TLS encrypts from the outside. XTLS-Vision removes the double encryption inside TLS — less processor load and a higher speed ceiling, especially on weaker devices.
What you can measure in the client itself
The "Test" button on a server card shows the response latency or the error text. The "Proxies (check)" screen lists servers with status, ping and transport type — that is where to start when something is off.
The threshold is set in the same place: a slider from 500 ms to 15 s. If the response is slower than the threshold, the client treats the proxy as unavailable and switches to the fallback group. The fallback is set on the group, the same way the main proxy is.
The most underrated fix: do not send everything through the server
Half the complaints about a slow connection are about traffic that needs no tunnel at all. Updates, cloud backups, streaming and downloads eat the server's channel, share it with whatever you needed the server for, and run into its distance as well.
Per-app routing solves this without any speed settings: only what you ticked goes through the server, the rest goes direct, at the provider's full speed. It also removes the other problem — the apps that break when the address changes.
What not to expect
Changing the transport almost never cures a slow connection. If the server is far away or overloaded, every protocol on it will be slow — the difference between them is measured in percentages, the difference between continents in multiples.
And one more: the client does not affect the speed of the server itself. It can show the latency, switch to a fallback and keep needless traffic out of the tunnel, but it will not make the server faster.