VMess, VLESS, Trojan, and Shadowsocks aren’t four speed tiers. They use different approaches to authentication, encryption, and forwarding. If you already have a subscription, match the server settings and client core first. If you’re setting up a new connection, choose based on your transport requirements and device capabilities. This guide explains protocols, TLS, and transports separately, then walks through checks for desktop and Android.
Understand protocols, transports, and cores
A node labeled “VLESS + WebSocket + TLS” combines three layers: VLESS handles proxy authentication and request formatting, WebSocket carries the data, and TLS provides encryption and server authentication for the connection. Knowing only that it uses VLESS—and missing the other two settings—usually isn’t enough to get a working connection.
v2rayN is a desktop client for importing configurations, selecting nodes, and setting the system proxy; the core handles the actual connection. On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. A client’s ability to parse a share link doesn’t guarantee that its current core supports every extension parameter in that link.
- Protocol: VMess, VLESS, Trojan, or Shadowsocks determines the authentication fields and how the protocol handles traffic.
- Transport: Check fields such as TCP, WebSocket, and gRPC. The client and server must use compatible settings.
- Security layer: Check settings such as TLS or REALITY. REALITY is not a standalone fifth proxy protocol.
- Routing: Determines whether requests connect directly, go through a proxy, or are blocked. This is separate from the protocol used by a node.
How the four protocols handle encryption and authentication
When comparing protocols, first ask which layer provides encryption, then how the server identifies users. A UUID or password is authentication data, not a complete security configuration. And setting the port to 443 doesn’t automatically add TLS protection to a connection without TLS enabled.
| Protocol | Authentication and encryption | Common combinations | What to check |
|---|---|---|---|
| VMess | Identifies users by UUID; supports protocol-level data encryption, with modern configurations using AEAD authentication. | TCP, or combinations such as WebSocket + TLS. | UUID, encryption settings, transport, and device system time. |
| VLESS | Authenticates with a UUID; common configurations don’t encrypt data at the protocol level and rely on TLS, REALITY, or similar solutions to protect the connection. | WebSocket + TLS, or TCP + REALITY in Xray configurations that support it. | Security layer, server name, transport fields, flow, and REALITY parameters. |
| Trojan | Authenticates with a password; standard deployments commonly rely on TLS for encryption and server authentication. | Usually TCP + TLS; other transport combinations depend on the implementation. | Password, certificate validity, server name, and transport support. |
| Shadowsocks | Uses an agreed encryption method and key material; legacy AEAD and Shadowsocks 2022 differ in format and requirements. | Carries TCP and UDP traffic directly; both ends must support any additional encapsulation. | method, password or key format, and UDP support. |
VMess AEAD authentication and the AEAD encryption methods used by Shadowsocks are not the same configuration field. Don’t blindly copy alterId from older VMess guides, either: modern VMess AEAD configurations typically use 0. For an existing node, follow the server’s actual requirements.
For Shadowsocks, a correct password alone doesn’t guarantee a complete configuration. For example, aes-128-gcm and 2022-blake3-aes-128-gcm are different methods, and the latter has specific key-format requirements. Changing the encryption method won’t make the server switch to match.
Choose for your setup, not by ranking protocol names
These recommendations assume you can choose the server configuration. If your provider offers only one protocol, first make sure it works end to end on your device rather than forcing a different protocol in the client. There’s no universal speed ranking independent of the route, configuration, and device.
VLESS: Check requirements for new configurations
RecommendedA good first choice for a new configuration when the server provides complete TLS or REALITY settings and the client core supports the combination. This recommendation is about compatibility with the deployment, not a guarantee of faster performance on every network.
Best for: New connections where you can confirm core support and need the corresponding transport and security layer.
VMess: Keep a proven setup
If your existing VMess subscription works reliably, there’s no need to switch just because the protocol name is older. Use a compatible modern authentication configuration, keep the device clock accurate, and confirm the server’s transport settings.
Best for: Users with a working subscription or a server already configured for VMess.
Trojan: For existing TLS deployments
If the server has a valid certificate, a clearly specified server name, and Trojan support, configure the connection to use its existing TLS setup. Using TLS doesn’t mean you can skip certificate validation.
Best for: Users whose server provides complete Trojan settings and who want to use an existing TLS deployment.
Shadowsocks: Match the encryption method
Shadowsocks uses a relatively compact set of configuration fields, making it a good fit when the server provides a specific method and key. Whether to use legacy AEAD or a 2022 method depends on support at both ends—not just whether the client offers a Shadowsocks option.
Best for: Users with an existing Shadowsocks server or those comparing the overhead of different encryption methods on their devices.
What to consider for everyday browsing, mobile networks, and older devices
Everyday web browsing is more likely to be affected by round-trip latency, DNS resolution, and server load. If you switch protocols and also change regions and providers, you won’t know which change caused the difference. Keep the server, test destination, and network conditions as consistent as possible.
- Everyday browsing: First check that HTTPS pages load consistently and images finish loading, then test large downloads. A successful latency test only confirms that one probe worked—it doesn’t mean every browser request will work.
- Mobile networks: Switching from Wi-Fi to cellular may require existing connections to reconnect. First check that the tunnel comes back, then check DNS and UDP. Don’t assume every reconnection means the protocol is unsuitable for mobile devices.
- Older devices: Actual overhead depends on CPU encryption acceleration, core implementation, and additional encapsulation. It’s not safe to assume Shadowsocks always uses the least power, or that “lightweight” in the name VLESS guarantees the lowest resource use.
- Voice calls and gaming: UDP forwarding must be supported by the client entry point, proxy protocol implementation, server, and routing. If web browsing works but voice calls fail, check the UDP path separately.
Check a configuration in the client in four steps
On desktop, start by testing one complete configuration in v2rayN before dealing with routing or application traffic. The menu paths below refer to common Chinese-language desktop interfaces; labels may vary slightly by version. Match options by function, and don’t change unrelated settings just to find an exact label.
-
Import the complete link
Copy the complete share link from your provider, then press Ctrl + V in the v2rayN main window to import it. A subscription URL isn’t the same as a single-node link, and you shouldn’t split a node link into separate parts before pasting.
-
Check the node settings
Double-click the node to open its settings, then check the address, port, user ID or password, transport protocol, and TLS settings. For WebSocket, check the path and Host. For REALITY, verify the public key, shortId, server name, and flow against the server’s settings.
-
Start the connection and check the logs
Set the target node as the active server and check the log area in the main window to confirm that the core starts. If you see an “unsupported transport” or configuration parsing error, check core compatibility first instead of repeatedly changing the local listening port.
-
Route application traffic through the client
Right-click the tray icon and choose “System Proxy” → “Automatically configure system proxy,” then test with a browser. To check the local listening port, open “Settings” → “Parameter Settings” and note the actual port. For apps with a manually configured proxy, enter the matching address and port.
On Android, first identify the core: v2rayNG’s Xray features aren’t interchangeable with v2flyNG’s v2fly features. For VLESS in particular, check that the app’s current core supports the extensions, security layer, and flow you need. After importing, start the connection and test it; seeing a node in the list only confirms that the link was parsed.
Don’t confuse ports, domains, and security settings
The remote port is where the server accepts connections; the local port is where applications connect to the client. The three numbers below are configuration examples for illustration only—not required ports for any of the four protocols or universal v2rayN defaults.
For example, a browser can use the SOCKS proxy at 127.0.0.1:1080 if the client is actually providing a SOCKS service at that address. Even if the remote node is set to example.com:443, don’t change the browser’s proxy port to 443. example.com is used only to illustrate how these fields relate.
- Server address and server name: The address is used to establish the connection; the server name is typically used for TLS SNI and certificate validation. They can differ, but both must match the server’s setup.
- WebSocket Host and path: These are transport settings, not a UUID. Don’t copy them from another node without checking.
- Allow insecure connections: Skipping certificate verification isn’t a routine fix. First check the system clock, certificate domain, expiration date, and server certificate chain.
- REALITY parameters: Use the complete set provided by the server. Don’t blindly copy fields from a standard TLS node into a REALITY node.
Proxy protocol FAQs
My subscription only has VMess. Should I switch to VLESS?
Not just to change the protocol name. Start the existing node and confirm it works. If your provider also offers a VLESS link, import it as a separate node and compare. Changing the protocol type in the editor won’t change the server configuration.
VLESS imported successfully, but why does it fail on startup?
Check the first configuration error in the logs, then verify the transport, security layer, and flow. On Android, check whether you’re using v2rayNG or v2flyNG and confirm that its core supports the settings. A link starting with vless:// doesn’t guarantee that every field will work.
Trojan reports a certificate problem. Can I turn off verification?
First correct the device clock, then check the node’s server name against the domain covered by the certificate. If the certificate has expired or the chain is incomplete, the server needs to be fixed. Turning off verification weakens server authentication and isn’t a suitable long-term solution.
Web pages load, but voice calls won’t connect. What should I check?
First confirm that the app’s traffic is going through the proxy, then check UDP support in the configuration and the server firewall. A system HTTP proxy generally can’t capture UDP traffic from arbitrary apps. If needed, use the client’s TUN or system-tunneling feature and test the routing rules again.
Still getting timeouts after switching protocols. What next?
Check the local listener, application proxy settings, core logs, remote address, and server reachability—in that order. First confirm that the request reaches the client, then check whether the handshake fails. If the connection never reaches the client, changing the UUID or encryption method usually won’t help.
Your choice comes down to three things: the complete setup the server provides, whether your device’s core can run it, and how reliably it works on your network. Keep existing working nodes and import new configurations separately for comparison. Once the protocol matches, check the system proxy, DNS, and routing rules to make troubleshooting easier.