Node lists often mix Shadowsocks, VMess, VLESS, and Trojan. Many people pick by speed and never ask what the protocol is. This article sketches the design differences on a rough timeline so the "protocol" field in node info actually means something.
When you add a node or open a subscription, each entry has a protocol such as ss (Shadowsocks), vmess, vless, or trojan. That field is how the client and server pack, encrypt, and send data. Protocols trade off encryption, traffic fingerprint, and efficiency. Day-to-day actions (pick a node, connect, check speed) look the same. Differences show up as stability and how easy the traffic is to identify. Shadowrocket speaks all of these; which one you use depends on what the node or subscription provides.
| Protocol | Roughly appeared | Design idea |
|---|---|---|
| Shadowsocks | Around 2010 | Simple idea: encrypt and forward, keep the protocol light, keep client and server easy to implement |
| VMess | Around 2017 | On top of Shadowsocks: user identity (UUID), protocol-layer encryption, timestamps against replay, and other fuller machinery |
| Trojan | Around 2019 | Shift toward camouflage: make proxy traffic look as close as possible to normal HTTPS web traffic |
| VLESS | Around 2020 | Drop protocol-layer encryption, keep identity checks, and let the outer TLS connection do the crypto, so the protocol itself is lighter |
The direction is roughly: from "the protocol encrypts the payload itself" toward "keep the protocol thin, and let a more standard outer transport (such as TLS) handle security" — traffic that is harder to single out.
Newer is not automatically better. Each protocol was answering problems the previous generation exposed:
That is why "protocol" is not the same as "secure." The same protocol behaves differently depending on how it is configured. Newer designs are often more mature, but they are not foolproof just because you selected them.
Usually no. The provider already chose the protocol; it is written on the node, and Shadowrocket connects with that protocol automatically. You do not pick "connect with X." This article is mainly to explain why one provider's subscription sometimes lists several protocols — extra options for different networks, not a menu where you pick whichever looks "faster."
If a protocol is unstable on your network, try another protocol type in the same node list instead of arguing which protocol is theoretically better. How the server is deployed usually matters more than the protocol name.
No, and you should not read it that way. Protocol is already set on the node. Like the rest of this site: we do not resell or recommend providers. This article only explains the names in the node list. It is not advice on which protocol to buy.
Note: The timeline is based on public technical material. Implementation details follow each project's official docs. This article does not review any subscription provider.