Choose a protocol based first on what the server supports, then on whether your client’s core supports it fully. There’s no need to replace a working VMess node just because it’s an older protocol. For a new setup, consider VLESS with TLS or REALITY if both ends support it; Trojan may suit servers with an existing certificate and domain; for a straightforward encrypted proxy, check the specific Shadowsocks method. This guide separates protocol, transport, and security layers to help macOS and Android users verify subscription settings and compare real-world performance under consistent test conditions.
1. Understand Protocols, Transports, and Security Layers
v2rayN is a desktop client, not a proxy protocol. V2Ray and Xray are proxy cores that handle connections, routing, DNS, and other settings. VMess, VLESS, Trojan, and Shadowsocks define how the client and server authenticate and encapsulate or encrypt data. A successful import only means the client could parse the link; it doesn’t guarantee that the installed core supports every feature in it.
A node labeled “VLESS + WebSocket + TLS” combines three layers. VLESS handles proxy requests and identity information; WebSocket carries the data; TLS encrypts the connection and verifies the server’s identity. Treating all three as one “protocol” can lead you to miss a path, domain, or security setting when switching nodes.
- Proxy protocol
- Check whether the protocol is VMess, VLESS, Trojan, or Shadowsocks. Both ends must use the same protocol; changing the label in the client alone won’t work.
- Transport
- Check the actual settings, such as TCP, WebSocket, or gRPC. Not every protocol, core, and version supports the same combinations.
- Connection security
- Check settings such as TLS or REALITY. REALITY is a security mechanism associated with Xray, not a standalone proxy protocol or a drop-in replacement for a standard certificate.
2. Encryption and Authentication: Four Protocols Compared
Whether a connection is encrypted depends on the entire connection, not just the protocol field. In common VLESS configurations, encryption=none means the protocol itself doesn’t encrypt payloads; the connection can still be protected if TLS or REALITY is correctly enabled at a higher layer. Conversely, using port 443 doesn’t prove that TLS is enabled.
| Protocol | Authentication and encryption | Common setups | What to check |
|---|---|---|---|
| VMess | Uses a UUID for identity; modern configurations use AEAD authentication, while payload encryption depends on the security settings. | VMess + TCP, or WebSocket + TLS. | UUID, payload security settings, system time, and transport parameters. |
| VLESS | Uses UUID authentication; the protocol itself doesn’t encrypt payloads, so it’s typically paired with an external security layer. | VLESS + TLS, or a REALITY setup supported by Xray. | UUID, security layer, flow, and parameters such as the public key required for REALITY. |
| Trojan | Uses password authentication; TLS protects the credentials and proxy traffic. | Trojan + TCP + TLS。 | Password, certificate domain, SNI, and certificate verification status. |
| Shadowsocks | Protection is provided by the selected encryption method; traditional AEAD and 2022-series methods use different key requirements. | Native TCP/UDP encrypted proxy. | Exact method name, password or key, and core support. |
VMess alterId is a compatibility-related parameter. Modern AEAD configurations typically use 0; don’t enter another value just because an older guide says to. VMess authentication also depends on time. If your system clock is noticeably off, first enable automatic time setting in macOS under System Settings → General → Date & Time, then check the node.
Shadowsocks isn’t a single encryption method. aes-128-gcm and 2022-blake3-aes-128-gcm are different configurations. The latter requires a correctly formatted preshared key; you can’t use any short password as the key. The server must be updated to match if you change methods.
3. Handshake Overhead and Speed: Keep Test Conditions Consistent
Loading a webpage for the first time involves DNS lookup, connection setup, security handshakes, proxy requests, and the destination server’s response. Trojan typically establishes a TLS connection before sending proxy requests. The actual overhead for VMess and VLESS also depends on whether TLS, WebSocket, or another transport is layered on top. A native Shadowsocks connection doesn’t use a TLS certificate handshake, but that doesn’t mean it’s faster on every network.
WebSocket deployments commonly using HTTP/1.1 also require an upgrade handshake. Connection reuse can reduce the cost of setting up connections for subsequent requests, but it also affects congestion and how widely a failure impacts traffic. So you can’t infer fixed latency from a protocol name, or treat the milliseconds from a single “latency test” as the time it takes to load a whole webpage.
- Use the same route: Compare configurations on the same server and egress IP, and as close together in time as possible. Nodes in different regions won’t isolate protocol differences.
- Use the same proxy entry point: Keep system proxy or TUN mode, routing rules, and DNS settings unchanged during testing. Otherwise, one test may use the proxy while another connects directly.
- Track results separately: Record page load time, sustained download speed, and failure count separately. Test each setup at least 5 times and compare the median, not just the best result.
- Test UDP separately: For calls, games, or QUIC, verify with the actual application. Being able to load a webpage doesn’t mean UDP is forwarding correctly.
Bottom line: rule out unstable configurations before comparing speed
If multiple timeouts occur across 5 tests, check the route and transport compatibility first. Median timings are useful only when every setup completes requests reliably. Without results from consistent test conditions, don’t rank protocols by name.
4. TLS, REALITY, and the Limits of Traffic Obfuscation
TLS can protect data in transit, but using TLS doesn’t make traffic indistinguishable from ordinary web browsing. Handshake fingerprints, domains, IP reputation, packet sizes and timing, and how the server responds to unusual requests can all affect detection. VMess with TLS can’t be assumed to be weaker than other protocols based on its name alone.
Trojan carries proxy traffic over TLS, but still requires a valid certificate, domain, and correctly configured server. VLESS with REALITY requires compatible cores at both ends and correctly configured parameters such as the public key, serverName, and shortId. Some setups also require a specific flow; these fields aren’t a case of more being better.
- TLS nodes: The certificate must be valid, and its name must cover the domain used for verification. Set SNI as specified by the server; don’t swap in a random popular website.
- REALITY nodes: Check the server-provided public key, serverName, shortId, and fingerprint settings one by one. Field names in the client may vary by version.
- CDN setups: A standard HTTP CDN requires a compatible HTTP-based transport and support from the provider. Raw TCP + REALITY can’t be connected to a standard WebSocket site as if it were one.
- Shadowsocks setups: Encryption hides plaintext, but native Shadowsocks traffic doesn’t automatically look like HTTPS. The server configuration determines whether another transport is needed.
5. Choose by Use Case: New Setups, Existing Subscriptions, and Android
The recommendations below apply to new configurations where the server can be adjusted and the client supports the required features. If you already have a working subscription, keep the complete setup provided by the service. Protocols aren’t rungs on an upgrade ladder; what matters is whether a setup suits your network and maintenance needs.
VLESS with TLS or REALITY
RecommendedA strong option to evaluate for a new setup. VLESS doesn’t encrypt payloads itself, so security depends on correctly configured protection at a higher layer. Before using REALITY or a specific flow, make sure the Xray core and server configuration are compatible.
Best for: Users who can manage the server configuration and are comfortable checking security settings.
Trojan with TLS
A straightforward option if you already have a domain and certificate maintenance process. Check the password, SNI, and certificate verification; don’t leave verification disabled to work around connection errors.
Best for: Users with existing TLS deployment experience whose server explicitly supports Trojan.
VMess AEAD
Keep using a stable VMess subscription. Preserve its existing transport and TLS settings, and confirm that the system clock is synchronized. There’s no need to redeploy just to change the protocol name unless there’s evidence of a problem with the current setup.
Best for: Existing subscriptions and setups where server compatibility comes first.
Shadowsocks AEAD / 2022
The settings are relatively straightforward, making this a good fit for servers that explicitly support the method you need. Check the exact method and key format before choosing it. If an app needs UDP, confirm that both the server and local entry point support forwarding.
Best for: Lightweight encrypted proxy setups where the encryption method and key are known.
When using v2rayN on macOS, check which core is selected rather than relying on the client version alone. On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. For REALITY, specific flows, or Shadowsocks 2022, verify support in the relevant core version; don’t assume every configuration works identically across all three clients.
- Desktop: Update v2rayN and its core to versions that support your subscription’s features, then import the original configuration. Keep a copy of the old configuration so you can roll back.
- Android: Import the same node into v2rayNG and check its transport and security fields. If switching to v2flyNG, first confirm that the node doesn’t rely on Xray-specific features.
- Using multiple devices: Ask the server provider which clients are supported and what the minimum core version is. A client recognizing a share link doesn’t prove that the configuration is compatible.
6. After Importing: Check Protocol Settings and the Local Proxy Entry Point
A node appearing in the client doesn’t mean app traffic is going through it. After importing, open the node editor to verify the server settings, then check the local proxy entry point. The port 1080 below is only an example SOCKS5 test port, not a fixed v2rayN default. Replace it with the port currently listening before running the command.
- Protocol and credentials: Check the VMess/VLESS UUID, Trojan password, or the complete Shadowsocks method and key. Watch for leading or trailing spaces when copying.
- Address and port: Check the server address and port. The local listening port is different from the remote server port.
- Transport and security: For WebSocket, check path and Host; for gRPC, check serviceName. For TLS, check serverName; for REALITY, also verify the public key and shortId.
- Local listener: In v2rayN, look under Settings → Parameter Settings for the local listener or inbound port. Labels vary by version, so check the current settings and startup log.
- App traffic: Confirm that the system proxy is configured or TUN is enabled if needed. When testing a single entry point, don’t change routing and DNS rules at the same time.
# Replace 1080 with the SOCKS5 listening port used by the current client
curl --proxy socks5h://127.0.0.1:1080 --connect-timeout 10 --max-time 30 -I https://example.com/socks5h sends the destination hostname to the SOCKS proxy for resolution, which can reduce interference from local DNS lookups during testing. It can’t guarantee that subsequent DNS requests use a particular encrypted channel. The command is also affected by client routing rules, so check the outbound logs too. If it can’t connect to 127.0.0.1, troubleshoot the local listener first. For handshake or authentication errors, check the remote settings.
7. Frequently Asked Questions About Choosing a Protocol
VLESS shows encryption as none. Should I change it?
Don’t change it without checking first. Open the node editor and confirm that TLS or REALITY matches the server configuration. Here, none refers to the VLESS protocol layer. If there’s no protection at a higher layer either, don’t treat it as a secure public internet connection; ask the server provider how it’s designed.
My VMess node still works. Do I need to switch everything to VLESS?
No, not just to change the name. Check time synchronization, the current core, and transport settings, then test under the same network conditions. Import a VLESS configuration for comparison only if the server provides a working one; you can’t switch protocols directly on the existing node.
Trojan reports a certificate error. Can I just disable verification?
First check the system clock and the node’s serverName. Then ask the server administrator to check the certificate’s validity period, chain, and domain coverage. Don’t leave verification disabled. Fix the certificate or domain settings, then test again with verification enabled.
Shadowsocks imported successfully, but authentication keeps failing. Why?
Compare the method name exactly and confirm whether the server expects a password or a key in a specific format. 2022 methods typically use a Base64-encoded key of a fixed length; don’t swap it with a traditional AEAD password. Also check that the core supports the method.
The same subscription works on my computer. Why does it time out on Android?
First compare the selected node, network, and security settings on both devices. v2rayNG and v2flyNG use different cores; check compatibility first if the setup uses REALITY or a specific flow. Then test both on the same Wi-Fi to distinguish configuration issues from mobile network differences.