Start with the complete configuration provided by the server, then check whether your client core supports it. VMess includes encryption at the protocol layer. Common VLESS setups rely on TLS or REALITY for confidentiality, Trojan uses TLS, and modern Shadowsocks encrypts traffic with a pre-shared key. This guide is for readers comparing subscription nodes, planning a self-hosted setup, or sharing configurations across devices. Learn how protocols, transports, and security layers fit together—and why changing only the protocol name can break a connection.
1. Understand protocols, transports, and clients
VMess, VLESS, Trojan, and Shadowsocks are proxy protocols, not client apps. v2rayN is a desktop client for storing nodes, managing subscriptions, configuring proxies, and running a core. On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Being able to add a node in the interface does not mean the active core supports every transport and security option in its configuration.
It’s more useful to break a node into layers than to memorize which protocol is “best.” The protocol name in a subscription is only the first layer; the address, port, transport, security layer, and authentication fields must all work together. This is especially important with VLESS: matching protocol names do not mean a configuration can be copied unchanged between different cores.
- Proxy protocol: Defines how users are authenticated, destination addresses are represented, and proxy requests are encapsulated—for example, VMess or Trojan.
- Transport: Determines how proxy data is carried, such as over TCP, WebSocket, or gRPC. Not every protocol or core supports every combination.
- Security layer: Examples include TLS and Xray’s REALITY. This is separate from the proxy protocol.
- Client and core: The client provides the interface; the core handles connections. When troubleshooting compatibility, note the version of each.
2. How the four protocols handle authentication and encryption
First identify what provides encryption, then compare configuration complexity. The table covers common current setups: VMess AEAD, VLESS with encryption=none, standard Trojan, and modern Shadowsocks AEAD variants. Don’t assume the same behavior for legacy configurations or newer extensions based on the protocol name alone.
| Protocol | Authentication method | Source of confidentiality | Configuration essentials |
|---|---|---|---|
| VMess | UUID and protocol-level authentication | AEAD encryption at the protocol layer; TLS can also be added | UUID, encryption options, system time, transport settings |
| VLESS | Usually a UUID | Common configurations with none rely on a security layer such as TLS or REALITY | Security layer, server name, flow, and core support |
| Trojan | Shared password, authenticated through the protocol | TLS connection | Password, certificate validation, server name |
| Shadowsocks | Shared password or a pre-shared key in the required format | Authenticated encryption provided by the selected cipher | Cipher, key format, and compatibility between implementations |
VMess: Check AEAD and time synchronization
VMess doesn’t mean you have to use an outdated configuration. Modern setups commonly use AEAD, and legacy VMess configurations typically set alterId to 0. Don’t increase it at random to fix connection problems. VMess authentication depends in part on the time, so even a valid UUID may fail if the device clock is significantly off. Enable automatic time synchronization in the operating system before checking other fields.
VLESS: none does not mean the entire connection is unencrypted
In common VLESS configurations, encryption=none means this layer does not encrypt the payload; it does not mean that outer TLS or REALITY provides no encryption. Conversely, without protocol-level encryption or a reliable security layer, the VLESS name alone does not make a connection secure. For other encryption extensions, verify the implementations and versions on both ends rather than applying assumptions from none mode.
Trojan and Shadowsocks: Similar password fields, different mechanisms
Trojan relies on TLS for confidentiality, and a proper deployment must validate the server certificate. Shadowsocks protects proxy traffic directly with the selected cipher and doesn’t require a domain certificate for a basic setup. Legacy AEAD methods and Shadowsocks 2022 have different key requirements. For example, 2022-blake3-aes-128-gcm requires a key of a specified length; an arbitrary password won’t meet the requirement.
3. How TLS, REALITY, and WebSocket work together
“VLESS + REALITY” and “VMess + WebSocket + TLS” describe combinations of different layers. REALITY is a security mechanism provided by Xray, not a standalone proxy protocol. WebSocket is a transport and cannot replace TLS. A standard CDN reverse proxy generally requires a supported HTTP-based transport; changing the address of an arbitrary TCP node to a CDN hostname won’t make it work.
A port number only identifies where a service listens. A server on port 443 may still be running an incompatible service, and TLS can be configured on other ports. Check the actual configuration and handshake logs rather than relying on the port number. With standard TLS, you can connect by IP, but the server name used for certificate validation must still match the certificate.
- Standard TLS: Check the server name, certificate validity period, certificate chain, and device clock. Don’t treat “allow insecure connections” as a standard fix.
- WebSocket: Check the path and Host, and confirm the reverse proxy forwards requests to the correct endpoint. Differences in capitalization or a trailing slash can prevent a match.
- gRPC: Check the service name and confirm the server supports HTTP/2. Don’t reuse the WebSocket path field.
- REALITY: Check the server-provided public key, shortId, server name, and related settings. A correct UUID doesn’t make these fields correct automatically.
VLESS flow is not a plug-in performance setting. Configure a value such as xtls-rprx-vision only when the server uses the corresponding flow and the client core and transport combination support it. Importing a complete subscription is usually more reliable than assembling fields manually, but make sure the subscription comes from a trusted source.
4. How to make meaningful performance comparisons
There’s no fixed speed ranking independent of the network. Different protocols on the same server may be affected by different endpoints, reverse proxies, or throttling rules. A single download test can’t prove that one protocol is faster when nodes are in different regions. Encryption, handshakes, transport overhead, and packet loss can all become bottlenecks; actual performance depends on the device and network.
- Encryption workload: AES hardware acceleration affects AES-GCM performance; ChaCha20-Poly1305 may be a better fit on some devices. You can’t determine speed or battery use from the cipher name alone.
- Handshake overhead: For frequent short connections, network round trips and TLS handshakes affect the first request. Long transfers depend more on bandwidth, congestion, and packet loss.
- Extra encapsulation: WebSocket, gRPC, and reverse proxies add processing steps, but may be required by your setup. Fewer steps don’t guarantee a faster connection.
- UDP support: The protocol, core, server, and local traffic routing must all support UDP. If a game or voice call fails, a working web connection doesn’t prove the UDP path is working.
A repeatable comparison process
- Use endpoints in the same region, on the same server, with the same bandwidth limits where possible. Record the client version, core version, protocol combination, and test time.
- Close background downloads and use the same test resource. Run one warm-up, then test three times and record the median instead of keeping only the best result.
- Test initial page loads, sustained downloads, and real-time traffic separately. A client’s latency test measures only a specific probe; it isn’t a substitute for testing the service you actually use.
- On mobile devices, also check background stability and battery use. Retest after switching networks; don’t mistake changes in wireless signal for a protocol issue.
5. Choosing a setup for home, mobile, and multiple devices
The recommendations below apply to common Xray setups with a compatible server and support on both ends; they are not a speed ranking for every network. If your existing node is stable, keep its complete configuration. When setting up a new endpoint, weigh certificate management, core compatibility, and the number of devices.
VLESS + a compatible security layer
RecommendedA good option to evaluate for a new Xray deployment. Choose TLS or REALITY based on your setup and match all security parameters. If you need compatibility with other cores, verify the specific combination—don’t check only that it says VLESS.
Best for: Managed servers and compatible cores on desktop and Android
VMess AEAD
If your existing VMess subscription works reliably, there’s no need to migrate just for the name. Keep the correct transport settings, address time synchronization, and make sure you aren’t using outdated authentication settings that don’t apply.
Best for: Existing stable nodes and setups that need to keep their current configuration
Trojan + TLS
Uses password authentication and TLS, with certificates and the server name as key configuration points. Suited to environments where domains, certificates, and endpoint forwarding can be maintained. Skipping certificate validation is not a maintenance shortcut.
Best for: Setups with an established domain and certificate maintenance process
Shadowsocks AEAD variants
A basic setup has few configuration fields and generally doesn’t require a certificate. For use across devices, check that the cipher and key format match. Before choosing a 2022 variant, confirm support on every device and the server.
Best for: Simple direct setups and multi-device environments with confirmed compatibility
For home networks, prioritize evening stability and simultaneous use across devices. On mobile networks, also consider network switching, UDP reachability, and background management. Android battery restrictions can stop a proxy process, and switching protocols may not help. First determine whether the system stopped the process or the core is still running but timing out.
Using one subscription across devices: check each device’s capabilities
Desktop: v2rayN
- Record the active core and its version, not just the client version.
- First test the system proxy in a browser, then configure terminal or TUN support if needed.
- Keep one verified node as a baseline for comparisons after updates.
Android: v2rayNG or v2flyNG
- Check nodes against Xray’s capabilities in v2rayNG and v2fly’s capabilities in v2flyNG.
- On first launch, approve the VPN permission and check that the target app is included in any per-app routing rules.
- Test mobile data and home Wi-Fi separately; don’t treat one test as evidence for both.
A single subscription doesn’t guarantee that every device can use the same nodes. For REALITY, flow, or specific ciphers, check what both ends actually support.
6. Troubleshoot connection failures by configuration layer
After choosing a protocol, the most common issue isn’t that the protocol is “bad”—it’s that only part of the configuration matches. Keep a copy of the original node, change one field at a time, and note the time of each log entry. When asking for help publicly, hide subscription URLs, UUIDs, passwords, and private keys. Redact real node addresses in logs as needed.
The VLESS UUID is correct. Why can’t it connect?
Check the address and port, security layer, server name, transport, and flow—in that order. With REALITY, also confirm the public key and shortId come from the same server endpoint. Don’t mix fields from TLS and REALITY nodes.
Trojan only works when certificate verification is disabled. What should I do?
Turn certificate verification back on. Check the device clock and server name, then have the server administrator verify the certificate’s validity period and full chain. When connecting by IP, keep the correct verification name too; completing a handshake doesn’t prove the server’s identity was verified.
Changed the Shadowsocks cipher, but the same password still doesn’t work?
The client and server must use the same cipher. If you switch to a 2022 variant, generate a new key that meets its length and encoding requirements. Don’t just change the client’s dropdown, and don’t assume an old password counts as a valid new key.
The node’s latency test succeeds, but web pages won’t load. Why?
First confirm the core is running and the browser is using the current local proxy port, then check DNS and routing. If the inbound listener is 127.0.0.1:10808, the app must connect using a proxy type supported by that inbound. The port is only an example; use the value in your actual settings.
All the VMess nodes in a subscription suddenly stopped working. Should I switch protocols?
First sync the system clock automatically, refresh the subscription, and check whether the nodes expired or the endpoint changed. If the log reports an authentication failure, check the UUID and authentication settings. For a connection timeout, check the address, port, and network reachability first; don’t change multiple protocol fields at once.
The key is to evaluate the complete configuration: the protocol handles authentication and encapsulation, the security layer provides confidentiality and identity verification, and the transport and network affect reachability and performance. To compare clients, see the client comparison. To learn how DNS, routing, and system proxies work together, see the user guide. Get one configuration running reliably, then optimize it step by step—it’s easier to troubleshoot than changing the protocol, core, and routing all at once.