If you already have a subscription, start with nodes your client’s core fully supports—don’t judge speed by protocol name alone. For a custom setup, compare authentication, encryption layers, and transport requirements. This guide helps you distinguish VMess, VLESS, Trojan, and Shadowsocks, check key settings, determine whether TLS is needed, and choose based on actual desktop and Android support.
Separate protocol, transport, and encryption layers
VMess, VLESS, Trojan, and Shadowsocks are proxy protocols, not client names. v2rayN is a desktop client; v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Clients let you edit, import, and run configurations; the selected core establishes the connection. Being able to import a link does not mean the core supports every combination it contains.
A node includes at least a server address, port, authentication details, and transport settings. The protocol defines how authentication works and how the destination is specified. Transports such as TCP and WebSocket carry the connection, while security layers such as TLS and REALITY protect the relevant transport. Keep these layers separate when troubleshooting—for example, a wrong WebSocket path is not a protocol incompatibility.
- Protocol layer: Identify whether it’s VMess, VLESS, Trojan, or Shadowsocks. Don’t just change the protocol in the client’s dropdown.
- Authentication layer: VMess and VLESS typically use a UUID; Trojan uses a password. Shadowsocks credentials depend on the encryption method.
- Transport layer: Check options such as TCP or WebSocket. For WebSocket, the path and request headers must also match the server configuration.
- Security layer: Check TLS, the server name, certificate verification, and whether the server requires settings such as REALITY.
Encryption and handshake comparison
Protocol authentication and data encryption are different things. A UUID or password proves that you’re authorized to connect; it does not, by itself, tell you whether the connection is encrypted. This table compares common deployments. The available settings depend on the implementations on both ends and the server configuration.
| Protocol | Authentication and handshake | Encryption and TLS | What to check |
|---|---|---|---|
| VMess | Uses a UUID as the user credential and AEAD authentication in modern configurations. System time is part of the authentication process. | Provides built-in data protection. Common payload encryption methods include AES-GCM and ChaCha20-Poly1305; TLS can be added as an outer layer. | UUID, encryption options, system time, transport type, and TLS settings. |
| VLESS | Authenticates with a UUID and uses a compact protocol header; some configurations also require a matching flow. | A typical base VLESS setup does not encrypt the payload. Pair it with a security layer such as TLS or REALITY; extended capabilities depend on the core. | UUID, security, flow, and the associated TLS or REALITY settings. |
| Trojan | Sends password-based authentication details and the destination request over a TLS-protected connection. | Standard deployments rely on TLS to protect authentication and application data, so certificate verification must be configured correctly. | Password, server name, certificate trust, and transport settings. |
| Shadowsocks | Uses a shared password or a key in the required format, depending on the selected method, and includes the destination address in the protocol. | AEAD methods provide authenticated encryption themselves, so a basic setup does not require TLS. Legacy methods and different generations of methods are not interchangeable. | method, password or key, port, and support for the selected method on both ends. |
Configuration complexity: fewer fields don’t guarantee an easier connection
Typical VMess imports include a UUID, encryption options, and transport settings. Modern VMess AEAD configurations generally use alterId=0; don’t copy a nonzero value from an outdated guide to try to “improve compatibility.” If authentication fails, check the device and server clocks instead of repeatedly changing the UUID.
VLESS has fewer basic fields, but enabling a specific security layer can add settings to check. For example, with VLESS and REALITY, the server name, public key, and short ID must match the server’s requirements. xtls-rprx-vision is a specific flow value—not something every VLESS node needs, or a setting to add arbitrarily to a WebSocket configuration.
- Confirm the protocol first: Check the provider’s documentation or the original subscription. Don’t guess based on the port.
- Then confirm authentication: Copy the UUID, password, or key in full, and remove any spaces or line breaks added accidentally while copying.
- Next, check the transport: Treat the WebSocket path and Host, and the TLS server name, as separate settings. They may all differ.
- Finally, check optional settings: Enter a flow, security layer, or method only when the server explicitly requires it. Don’t add unrelated parameters.
For Trojan, check that the certificate is valid and matches the server name. For Shadowsocks, the encryption method must match exactly: aes-128-gcm and chacha20-ietf-poly1305, for example, are not interchangeable. For Shadowsocks 2022 methods, also confirm core support and the required key format; a regular password is not necessarily a valid key for every method.
Choosing a protocol: start with the server, then check the client
These recommendations assume you’re creating a new configuration, using Xray, and can manage the server. They’re not a speed ranking. If your existing subscription works reliably, keeping a fully supported protocol is usually easier than switching. Latency and throughput also depend on the route, congestion, server load, transport, and device performance—not just the protocol name.
VLESS: for a new Xray setup
RecommendedA strong candidate for a new setup when both ends support the same options and you can configure TLS or REALITY correctly. Decide on the security layer and transport combination before entering authentication details.
Best for: users who manage the server, use Xray, and can maintain the associated security settings.
VMess: keep an existing setup
If you already have a working VMess subscription or server, continuing to use it is usually the simplest option. Check the AEAD settings, system time, and existing WebSocket or TLS parameters.
Best for: users with an existing VMess service who need to stay compatible with its current configuration.
Trojan: for setups with managed certificates and domains
Most settings concern the password and TLS. Keep certificates renewed, and maintain the server name and certificate chain. Disabling certificate verification is not a long-term solution.
Best for: users who can maintain a domain, a valid certificate, and a standard TLS service.
Shadowsocks: a lean setup with a known method
A basic connection requires a matching address, port, method, and credentials. Choose a modern AEAD method supported by both ends, and confirm requirements such as UDP separately.
Best for: users with a known encryption method and credentials who want fewer transport settings.
Using one subscription on desktop and Android
A single subscription can include multiple protocols. v2rayN and v2rayNG can use the same subscription source, but the nodes available on each device depend on the subscription format, client parser, and core support. Check node details after importing, especially for flow, REALITY, and newer encryption methods.
Using the same subscription on two devices: check each core and local proxy
Desktop: v2rayN
- Check which core is actually running, then choose a compatible node.
- Make sure the node’s protocol, transport, security layer, and flow are all present.
- Check the local listening port under Settings → Parameter Settings. Section names may change as the interface evolves.
- Check whether the system proxy is enabled separately from whether the remote node is reachable.
Android: v2rayNG / v2flyNG
- v2rayNG uses Xray; choose nodes that work with the combinations supported by that core.
- v2flyNG uses V2Fly; don’t assume it supports every Xray extension.
- After importing, check authentication, transport, and security settings one by one.
- Grant system VPN permission, then test the connection in an app you actually use.
You can use the same subscription source on both devices, but verify each runtime configuration separately. A node working on one device doesn’t guarantee it will work on the other.
Subscription links may contain access credentials, so treat them as sensitive information. When investigating import differences, compare the protocol and any missing fields, but don’t share the full subscription URL, UUID, password, or key. Remove server addresses and authentication details from logs before sharing them.
Ports and connectivity: test the right endpoint
A local proxy port and a remote server port are different things. The ports 10808 and 10809 below are examples of local proxy endpoints; 443 is a common TLS server port. None of these is required for every node. Check the client’s actual listening ports before running a command.
If you’ve confirmed that a local SOCKS proxy is listening on 127.0.0.1:10808, you can specify it explicitly with the command below. In Windows PowerShell, use curl.exe; in other terminals with curl installed, use curl. This uses a reserved example domain to demonstrate the test—not to report a speed result.
curl.exe --head --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 https://example.comsocks5h sends the destination domain to the proxy for resolution. If your actual endpoint is HTTP, use the corresponding proxy address. Don’t just change the SOCKS port number while leaving the wrong protocol prefix in place.
curl.exe --head --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10809 https://example.com- Local connection refused: First check whether the core is running and the listening port matches. This alone doesn’t indicate a problem with the remote protocol.
- TLS certificate error: Check the server name, device time, and certificate chain. Don’t simply bypass certificate verification.
- Connection timed out: Check the logs alongside the remote address, port, network route, and server status. A timeout alone doesn’t prove that a protocol is unavailable.
- Command works, but the app fails: Check the system proxy, the app’s own proxy settings, or per-app routing on Android.
FAQ: What to check before switching protocols
VLESS uses encryption=none. Does that mean the connection is unprotected?
In base VLESS, encryption=none means the protocol layer does not encrypt the payload; it doesn’t mean the entire connection is unprotected. Open the node details and check whether TLS or REALITY is enabled as required by the server. Don’t judge protection from this setting alone, and don’t use unprotected base VLESS on an untrusted network.
VMess works. Would switching it to VLESS make it faster?
Not by itself. The server must offer a VLESS endpoint, and the UUID, port, transport, and security layer must all match. If you have two working nodes, test them repeatedly on the same device, close together in time, and against the same destination. Compare packet loss and logs as well—don’t rely on a single latency result.
Trojan reports a certificate error. Can I enable skip verification?
First check that the node’s server name is correct, the device clock is accurate, and the certificate hasn’t expired. If you connect by IP address, the TLS server name may still need to be the domain on the certificate. Permanently skipping verification removes an important identity check; fix the configuration or the server certificate instead.
The Shadowsocks password is correct. Why can’t it connect?
Also check method, the port, and the key format, then confirm both cores support that method. If regular websites work but a particular app fails, check UDP support, routing rules, and destination resolution too. Matching passwords alone doesn’t rule out a configuration issue.
Will changing protocols affect routing rules?
The protocol defines how the remote connection works; routing rules decide which outbound handles the traffic. After changing nodes, check that the routing rule’s outboundTag still points to a valid outbound, then test the same destination again. On Android, check per-app settings too—app bypass can look like a node failure.
Choose in this order: confirm what the server offers, check what the core fully supports, then compare maintenance effort and real-world connection performance. For an existing setup, prioritize compatibility. For a new one, make the security layer and authentication requirements clear. The protocol name is only a starting point; complete settings and runtime logs are what matter.