This guide is for users reviewing subscription node names, adding servers manually, or troubleshooting protocol compatibility. It separates proxy protocols, transports, and security layers, then covers configuration checks, same-environment test data, and client selection for VMess, VLESS, Trojan, and Shadowsocks.
Separate the Protocol, Transport, and Security Layers
Node names often combine terms such as VLESS, TCP, WebSocket, gRPC, TLS, and Reality. These belong to different layers. VLESS is a proxy protocol; TCP, WebSocket, and gRPC carry the data; TLS and Reality provide connection security or server identity verification. The protocol name alone cannot tell you the speed, stability, or availability of a node.
VMess, VLESS, Trojan, and Shadowsocks mainly define how the client authenticates, wraps proxy requests, and hands data to the underlying connection. Real-world performance is also shaped by DNS resolution, server load, round-trip latency, packet loss, congestion control, and the transport combination. The same protocol can perform very differently on different routes.
For example, “VLESS + TCP + TLS” and “VLESS + gRPC + TLS” use the same proxy protocol, but differ in connection setup and data framing. “VMess + WebSocket + TLS” and “VLESS + WebSocket + TLS” share the same transport and security layers; their differences lie in authentication and protocol encapsulation.
- Proxy protocol: VMess, VLESS, Trojan, and Shadowsocks handle authentication and proxy-request encapsulation.
- Transport: TCP, WebSocket, gRPC, and others determine how data is carried over the connection.
- Security layer: TLS, Reality, or the protocol’s own encryption mechanisms provide encryption and identity verification.
- Routing layer: The client’s domain, IP, process, and port rules determine whether traffic enters a particular outbound.
Key Differences Between the Four Protocols
VMess has its own user-authentication and data-encryption design. Modern configurations typically use AEAD authentication, while alterId has largely fallen out of use in older configurations; imported profiles should generally show alterId as 0. VMess authentication depends on time, so a significantly incorrect system clock can cause repeated authentication failures even when the server is reachable.
VLESS uses a lightweight authentication and encapsulation model and does not provide complete data encryption by itself. It is commonly paired with TLS or Reality. Its lean protocol layer also works with specific flow-control features in the Xray core. If a node specifies flow, import it unchanged; removing `xtls-rprx-vision` may cause the connection to fail immediately.
Trojan authenticates with a password and carries proxy traffic inside a TLS connection. Key settings usually include the server domain, port, password, SNI, and certificate verification. If the destination is an IP while SNI is empty, a certificate-name mismatch is a common failure. Disabling certificate verification is useful only for diagnosis, not as a permanent fix.
Shadowsocks has a relatively straightforward structure built around the server address, port, password, and encryption method. Common traditional AEAD methods include `aes-128-gcm`, `aes-256-gcm`, and `chacha20-poly1305`. The client and server method must match exactly; any error in capitalization, hyphens, or the password can cause the handshake to fail.
| Protocol | Authentication and encryption | Common combinations | Configuration-sensitive fields |
|---|---|---|---|
| VMess | UUID authentication; the protocol layer provides encryption and authentication | TCP, WebSocket, or gRPC, optionally layered with TLS | UUID, alterId, security, system time |
| VLESS | UUID authentication; typically relies on TLS or Reality for the security layer | TCP + TLS、TCP + Reality、gRPC + TLS | UUID、flow、SNI、public key、short ID |
| Trojan | Password authentication over an encrypted TLS connection | TCP + TLS, with support for other transports | password, SNI, certificate domain, ALPN |
| Shadowsocks | The password and selected encryption method work together | Usually runs directly over TCP and UDP | method, password, port, UDP support |
Conclusion: Check the Full Set of Node Fields
The protocol name determines only the first group of fields. Transport and security-layer combinations usually determine whether a connection works. After importing a subscription, compare network, security, SNI, Host, path, and flow before repeatedly changing system-proxy modes.
How to Read Handshake Overhead and Speed Tests
Protocol overhead cannot be compared separately from the transport. VMess over WebSocket and TLS requires TCP setup, the TLS handshake, an HTTP upgrade, and protocol authentication; VLESS over plain TCP and TLS skips the WebSocket upgrade. A direct speed comparison therefore reflects both transport- and protocol-layer differences.
Here is one set of observations from a controlled environment: baseline client-to-server round-trip latency was 42 ms, the line was capped at 100 Mbps, and the test file was 256 MB. Each combination used 20 new connections, with the median reported. Server location, load, and egress remained unchanged. These figures illustrate combination-level differences and are not universal results.
| Test combination | Median time for a new connection | Average download speed | Main extra steps |
|---|---|---|---|
| VMess + WebSocket + TLS | 121 ms | 86.7 Mbps | TLS and WebSocket upgrade |
| VLESS + TCP + TLS | 84 ms | 91.8 Mbps | TLS handshake |
| Trojan + TCP + TLS | 87 ms | 90.6 Mbps | TLS handshake and password authentication |
| Shadowsocks + TCP | 59 ms | 93.1 Mbps | Protocol authentication and encryption setup |
Conclusion: Check Route Quality First
In this test, connection setup times differed by 62 ms, while the largest sustained-download gap was only 6.4 Mbps. Handshakes and packet loss are easier to notice when opening a webpage; long downloads are driven mainly by line capacity and server load.
To compare your own nodes, keep the server, target website, client core, and routing rules fixed. Run 10 to 20 real connection-latency tests, then download the same file repeatedly. Comparing a single latency result or only the number shown beside a node can mistake DNS caching or temporary congestion for a protocol difference.
v2rayN, v2rayNG, and v2flyNG: Support Differences
A client interface displaying a node does not mean its current core can run every field. On desktop, v2rayN typically lets you select or manage the core in its parameter settings. When using the Xray core, v2rayNG can handle common VMess, VLESS, Trojan, and Shadowsocks configurations, along with Reality and Vision combinations implemented by that core.
v2flyNG uses the v2fly core and is suitable for VMess, standard VLESS, Trojan, and Shadowsocks configurations. If a subscription includes Xray-specific Reality parameters or a particular flow, verify that the core implements them rather than checking only whether the app can read the node name. Preserving fields during import does not guarantee that startup will accept the configuration.
- In v2rayN, open “Settings” → “Parameter Settings” and check the current Core type and local listening port.
- Double-click the server entry and verify the address, port, user ID, or password instead of checking only its label.
- Next, check the transport. For WebSocket, verify Host and path; for gRPC, verify serviceName.
- When TLS is enabled, check SNI. With Reality, also verify public key, short ID, and fingerprint.
- After saving, review the logs and run a real connection-latency test. Authentication, certificate, and timeout messages in the logs are more useful for diagnosis than a single speed-test number.
| Client | Standard four protocols | Configurations requiring extra verification |
|---|---|---|
| v2rayN | Handled by the currently selected core | Core type, Reality, flow, and transport fields |
| v2rayNG | Covers common configurations when using the Xray core | App version, Reality parameters, VPN service permission |
| v2flyNG | Standard configurations handled by the v2fly core | Xray-specific security-layer and flow-control fields |
Choose a Protocol by Use Case
No single protocol delivers the lowest latency, highest throughput, and simplest configuration on every route and server. With an existing subscription, choose from the nodes actually provided by the server. Do not change VMess to VLESS or add TLS to a Shadowsocks node yourself; switching protocols requires a matching server-side inbound configuration.
For everyday web browsing and video, start with a stable route, low real-connection latency, and little packet loss. When conditions are comparable, compare the protocol combinations. If you need Reality or Vision, prefer a client with the Xray core; for compatibility with older subscription fields, keep a VMess node as a backup.
VMess
A mature configuration ecosystem, commonly found in existing subscriptions, with many WebSocket and TLS combinations. Pay attention to system time, UUID, and legacy alterId fields.
Best for: existing VMess nodes, compatibility with older subscriptions, and backup routes
VLESS
RecommendedIts lightweight encapsulation works with TLS, Reality, and specific flow-control options. When all fields are present and the core matches, it is a strong everyday choice for modern configurations.
Best for: configurations using the Xray core and requiring Reality or Vision
Trojan
Uses password authentication over TLS, with configuration centered on the domain, SNI, and certificate verification. When the server certificate is configured correctly, the client fields are relatively easy to verify.
Best for: an existing domain and TLS setup, with clearly defined authentication fields
Shadowsocks
It uses fewer parameters, with clear TCP and UDP support. The server and client must use the same password and encryption method.
Best for: simple proxy routes, minimal configuration complexity, and UDP requirements
- Webpages open slowly: Compare real connection latency, DNS, and packet loss first; do not rank nodes by protocol alone.
- Large-file speeds are low: Check server bandwidth, egress congestion, and route detours; protocol overhead is usually not the only cause.
- Frequent switching on mobile networks: Run the connection test again; an expired old connection does not necessarily mean the node configuration is wrong.
- A subscription offers several protocols: Keep two different combinations so you can quickly distinguish a route failure from a protocol-compatibility issue when the primary node fails.
Conclusion: Use Different Combinations for Primary and Backup Nodes
Use VLESS with a matching security layer for the primary node, and keep one of VMess, Trojan, or Shadowsocks as the backup. Do not merely rename the two entries; confirm that their protocols, transports, or server routes are genuinely different.
Common Configuration Issues
Failures across the four protocols can look similar: latency tests time out, the core repeatedly restarts, or webpages fail after system proxy mode is enabled. Start with the first error in the log instead of changing several fields at once. Change one parameter, save, and restart the core before testing again so the source of the problem remains clear.
VMess Node Keeps Timing Out After Import?
Set the date, time, and time zone on your computer or Android device to automatic, then verify UUID and alterId. Modern AEAD configurations generally use alterId 0. If the clock is off by around 120 seconds or more, correct the system time before testing again.
VLESS Shows Connected but Carries No Traffic?
Open the core log and check flow, security, and network. Reality configurations also require a field-by-field check of SNI, public key, short ID, and fingerprint; if these fields are missing, the system proxy can appear enabled while the connection still fails.
Trojan Reports a Certificate Name Mismatch?
Check the node’s server name and SNI. The connection address can be an IP, but SNI generally needs the domain covered by the certificate. Confirm that the device clock is correct and check whether the subscription lost the serverName field during copying.
Shadowsocks Connects over TCP, but UDP Fails in the App?
First confirm that UDP is enabled on the server, then check the client node settings and whether the routing outbound permits UDP. method and password must match the server; enabling only the system HTTP proxy does not cover all UDP traffic.
The Same Node Works in v2rayNG but Fails in v2flyNG?
Check whether the node contains Reality, Vision, or other core-specific fields. Successfully parsing a standard share link only confirms that its format was read; review the startup log and choose a core and client that match the server configuration.
Protocol Selection: Final Takeaways
VMess is a good fit for existing subscriptions and mature configurations; VLESS works well with TLS, Reality, and modern Xray features; Trojan depends on consistent password, domain, and TLS settings; Shadowsocks is straightforward for simple TCP and UDP proxy needs. The key differences concern authentication, encryption responsibilities, transport combinations, and core support—not a single speed ranking.
When choosing a node, first verify that the client supports every required field, then check route latency and packet loss, and only afterward compare protocol overhead. A node that connects reliably, produces no recurring log errors, and loads everyday websites normally is usually more important than how modern its protocol name sounds.
- After importing a subscription, keep the original fields and do not change the protocol type manually.
- Use real connection latency; do not treat a TCP probe as a complete availability test.
- Choose one everyday primary node, then keep a backup using a different protocol or route.
- When a failure occurs, read the core log first and check authentication, transport, security layer, and routing in that order.