Before choosing a protocol, check what the server provides and which client core you’re using, then verify the transport and security settings. This guide is for users importing subscriptions, migrating existing nodes, or comparing connection options. Learn to distinguish protocols from transports, identify fields such as UUID, password, SNI, and flow, and test configurations over the same connection to avoid mistaking network differences for protocol differences.
First, distinguish protocols, transports, and security layers
VMess, VLESS, Trojan, and Shadowsocks are proxy protocols. WebSocket and gRPC are transports that carry proxy traffic; TLS and REALITY are separate security settings to verify. A subscription entry like “VLESS + WebSocket + TLS” combines different layers of one connection—not three interchangeable protocols.
A client is not a protocol, either. v2rayN is a desktop client; v2rayNG uses the Xray core on Android, while v2flyNG uses the V2Fly core. Being able to save a configuration doesn’t mean the active core supports every field in it. Check core compatibility especially for REALITY, specific flow values, and newer encryption options.
- Protocol layer: Defines authentication, request format, and related encryption—for example, the UUID used by VMess or the method and password used by Shadowsocks.
- Transport layer: Defines how the connection carries traffic, such as using TCP directly or routing through a reverse proxy over a WebSocket path.
- Security layer: Check the TLS certificate and server name, or parameters such as the REALITY public key.
- Routing layer: Determines which outbound handles each request. Switching between “Global” and “Bypass mainland China” does not convert VMess to VLESS.
Encryption and configuration differences
The comparison below covers common deployments; it doesn’t treat any transport as the only way to use a protocol. In particular, distinguish encryption built into the proxy protocol from outer TLS: they operate at different layers, so the protocol name alone doesn’t tell you whether a connection is fully protected.
| Protocol | Authentication and encryption | Common combinations | What to check after importing |
|---|---|---|---|
| VMess | Identifies users with a UUID; modern deployments typically use AEAD authentication, while data encryption depends on the security setting. | TCP, or WebSocket + TLS. | UUID, security, transport type, path, and TLS; older configurations may also include alterId. |
| VLESS | Authenticates with a UUID; common configurations with encryption=none don’t encrypt data at the protocol layer and are usually paired with TLS or REALITY. | TCP + TLS, TCP + REALITY, or WebSocket + TLS. | UUID, encryption, flow, server name, and the REALITY public key and shortId. |
| Trojan | Authenticates with a password; classic deployments rely on TLS to protect the connection. | TCP + TLS; both sides must support any other transport encapsulation. | Password, port, SNI, certificate validity, and transport type. |
| Shadowsocks | Encryption is determined by the method and password or key; AEAD methods and Shadowsocks 2022 follow different key requirements. | TCP and UDP forwarding are built into the protocol; confirm any additional encapsulation separately. | method, password or key, server address, port, and whether UDP is enabled. |
VMess authentication depends on the time, so a significantly incorrect device clock can prevent connections. Enable automatic time sync first, then check the UUID and transport settings. If an older share link contains alterId, don’t follow outdated guides that set it to a nonzero value across the board. Modern AEAD configurations generally use 0, but the server setting is authoritative.
In common VLESS configurations, encryption=none doesn’t mean the entire connection is unencrypted: the outer layer may use TLS or REALITY. But VLESS doesn’t provide those protections automatically, either. If a configuration uses a newer VLESS encryption extension, confirm that both ends and their versions support it; don’t assume the fields work like those in classic configurations.
Bottom line: choose based on the full configuration
When comparing setups, record “protocol + transport + security layer + core,” such as “VLESS + TCP + REALITY + Xray.” Recording only “VLESS node” leaves out compatibility-critical details and makes problems harder to reproduce.
Handshake overhead and speed: how to compare meaningfully
Handshake count is not a download-speed ranking. TCP, TLS, proxy authentication, and transport encapsulation can all add connection setup time. Once a connection is reused, large transfers are affected more by bandwidth, congestion, server load, and packet loss. VLESS has a relatively compact protocol header, but that doesn’t make every VLESS node faster than every VMess node.
WebSocket and gRPC are often used with existing access infrastructure, not as free speed boosts. TLS session resumption, connection reuse, and server setup also affect real-world performance. The two ports below illustrate connection direction only; they are not default ports for any client or performance measurements.
- Keep the route consistent: Use the same server, exit route, and time window where possible. Nodes in different regions aren’t a fair way to compare protocol overhead.
- Keep test conditions consistent: Use the same routing mode, DNS settings, and destination. Don’t compare TUN mode with system proxy mode.
- Track metrics separately: Record time to first page load, sustained download speed, and connection failures separately. A TCP probe latency is not a page load time.
- Repeat the test: Run the same request five times for each configuration and record the median and number of failures. This is a testing method, not a claim about measured performance.
Choose a protocol for your use case
The recommendations below assume a new deployment, Xray support on both ends, and access to the full configuration. If your existing service is stable, compatibility matters more than switching just for a different protocol name. Without server-side access, you can’t add a protocol locally.
VLESS: a candidate for new configurations
RecommendedIf both ends support the features you need, consider VLESS + TLS or REALITY. Verify flow, server name, and key parameters individually; REALITY is not required for every VLESS node.
Best for: New Xray deployments where you have the complete server configuration.
VMess: keep an existing setup
If your existing VMess + WebSocket + TLS service works, you can keep using it. Check time synchronization and AEAD-related settings first; there’s no need to rebuild just because other protocols exist.
Best for: Existing VMess services where you want to keep the current connection setup.
Trojan: for existing TLS setups
A good fit when you can manage a domain, certificate, and TLS inbound. Troubleshoot expired certificates, incorrect SNI, and wrong passwords separately; disabling certificate verification is not a routine fix.
Best for: Setups with an established domain and certificate management process where the server explicitly offers Trojan.
Shadowsocks: when the encryption method is specified
The main parameters are the server address, port, method, and password. Choose an encryption method supported by both ends. For Shadowsocks 2022, also confirm both ends support the required method and key format.
Best for: Server-provided Shadowsocks configurations that are compatible with your client.
For clients, choose an available core in v2rayN that supports the node’s features. v2rayNG uses Xray, but check whether the current core supports newer fields. v2flyNG uses V2Fly; being part of a related ecosystem does not guarantee support for Xray features such as REALITY or specific flow values. A successful subscription update only means the configuration was retrieved—it doesn’t mean every node can start.
Import and verify: from share link to working connection
A subscription URL and a single-node share link are different ways to get configurations. A subscription URL usually fetches a group of nodes over HTTPS. Single-node links often start with vmess://, vless://, trojan://, or ss://. The prefix identifies the general protocol, but doesn’t guarantee that your core supports every extension field.
-
Identify the link type
First, distinguish a subscription URL from a single-node share link. These steps cover single-node links. Don’t treat a subscription webpage as a node password, and never post a full link containing a UUID, password, or key in a public forum.
-
Import the node
In v2rayN, the usual path is “Servers” → “Import share links from clipboard”; in v2rayNG, tap “+” in the top-right corner of the main screen → “Import from clipboard.” Labels may differ between versions; choose the share-link import option, not subscription settings.
-
Check the fields
In v2rayN, select the node and open its editor; in v2rayNG, tap the node’s edit icon. Check the address, remote port, UUID or password, transport type, and TLS or REALITY. For WebSocket, also verify the Host and path.
-
Start the client and check the logs
Start the node, then enable the proxy entry you need. In v2rayN, select “Set system proxy automatically” from the “System proxy” menu at the bottom. In v2rayNG, allow the VPN connection when prompted by Android. If the connection fails, check whether the logs show a configuration parsing error, handshake failure, or timeout, then change the relevant setting.
Troubleshooting: which layer to check first
VLESS imports successfully, but why does it fail to start?
Check for unsupported fields, flow values, or security types first. Verify the active core, then compare the UUID, REALITY public key, and shortId with the server configuration. Don’t delete unfamiliar fields just to make the configuration save; they may be required by the server.
Trojan reports a certificate error. Can I just skip verification?
Check the device time, SNI, and certificate validity first. If the connection address is an IP, enter the server name specified by the provider as well. Skipping verification weakens server identity checks; it’s no substitute for a valid certificate and correct name.
The Shadowsocks password is correct. Why can’t it connect?
Check the method and port, too. Password and key requirements vary by method, so copying the password alone may not be enough. If websites load but apps that rely on UDP fail, check server-side UDP support, firewall rules, and client forwarding settings.
The node latency looks fine. Why won’t my browser load pages?
First confirm that browser traffic is actually going through the client, then check DNS and routing. A successful TCP probe doesn’t mean proxy authentication or the TLS handshake succeeded. On desktop, test the system proxy on its own; while troubleshooting, don’t switch TUN, routing, and protocol settings at the same time.
Make your final choice based on verifiable requirements: the server provides it, the client core supports it, the full configuration imports correctly, and real apps can access the network reliably. The protocol name is just the first item on the checklist. Keep a working configuration and change one variable at a time; that usually makes problems easier to pinpoint than repeatedly switching protocols.