Choosing V2Ray Protocols and Cores

1. Understand Protocols, Transports, and Security Layers

Three Client Settings, Three Different Things

A proxy configuration includes at least a server address, port, credentials, and connection method. The protocol defines how requests describe their destination, authenticate users, and package data. The transport determines how that data travels, while the security layer protects communications and verifies the connection. VMess, VLESS, Trojan, and Shadowsocks are protocols; TCP, WebSocket, and gRPC are common transport options; TLS and REALITY are security mechanisms. Comparing options from different layers in one speed ranking usually tells you very little.

For example, VLESS can use different transports and security layers, so the word “VLESS” alone says little about real-world performance. TCP carries a connection directly; WebSocket adds an upgrade handshake and frame encapsulation; gRPC carries data over HTTP/2. Each combination has requirements for the server, reverse proxy, and client. Seeing an option in the client only means it’s available in the interface—it doesn’t mean the server has the matching endpoint or that every protocol and transport can be freely combined.

How to Describe a Complete Configuration

Before comparing two connections, note the protocol, transport, security layer, flow control, and core. Also record the server location, device type, and test application. Changing the protocol while also switching servers and networks makes it impossible to identify what caused the difference. Subscription labels are usually set by the provider, not generated by feature detection. A label mentioning REALITY or Vision doesn’t replace checking the actual fields and startup logs.

Choose options based on server capabilities

If you already have a subscription, use the complete combinations it provides. Don’t change a VMess node to VLESS as an “upgrade.” Switching protocols requires coordinated changes to the server inbound and client outbound; changing only one side leaves the other unable to understand the request. If you manage the server yourself, check which protocols and transports the existing deployment supports before configuring the client. When your goal is simply to use an existing service, keeping the subscription’s settings is more reliable than guessing from a dropdown menu.

Troubleshoot one layer at a time. If the address won’t resolve, check the domain and network. If the port won’t connect, check the listener and reachability. If the security handshake fails, check the server name, system time, and authentication parameters. If the connection is established but the destination remains unreachable, check routing, DNS, and app proxy settings. Change only the relevant fields at each step to avoid breaking settings that already work. For more, see connection troubleshooting.

2. VMess: Authentication, Encryption, and Legacy Fields

Design Goals and Existing Configurations

VMess is an earlier proxy protocol in the Project V ecosystem. Authentication and data protection are central to its design. It does more than add a password to a regular connection: it also defines how requests and data streams are structured. Its long history means it appears in many clients, subscriptions, and tutorials, along with some legacy parameters. When reading older guides, distinguish their configuration methods from the fields current cores still accept. Matching labels in the interface don’t guarantee that old settings can be reused as-is.

VMess typically identifies users with a UUID. A UUID is not a server address and can’t be shared with another node’s user ID. Even when the address, port, and identity all match, the transport and security layer must also be configured correctly. A common misconception is that a correct UUID should guarantee a connection. But if the server expects WebSocket and the client sends a direct TCP request, the two sides still can’t communicate as intended. Successful protocol authentication is just one step in the connection chain.

Why Time and Legacy Parameters Matter

VMess authentication involves time, so a significantly inaccurate device clock can cause verification failures. If import succeeds but authentication errors persist, enable automatic time synchronization and check that the displayed time and time zone are correct instead of repeatedly changing the user ID. The time zone mainly affects how time is displayed; the important factor is whether the system clock is accurate. The server’s clock must also be correct. Fixing the client alone won’t help if the server time is still off.

Older guides often mention alterId, a legacy setting related to additional identity IDs. Modern configurations typically use a value of zero and the corresponding AEAD authentication method. Don’t increase the value just to follow an old tutorial, or copy legacy subscription parameters into a different core without checking. If an importer reports an unsupported field, ask the provider to confirm the currently valid VMess parameters, then check how the client and core parse them. An unrecognized legacy field doesn’t necessarily mean the server is unusable.

Treat Protocol Encryption and Outer TLS Separately

VMess encryption options and outer TLS belong to different layers. An automatic setting in the interface usually lets the core choose an algorithm it supports; it doesn’t “configure the entire node automatically.” When selecting an algorithm manually, both sides must support the implementation. Hardware acceleration also affects processing costs, so no single algorithm is fastest on every device. Outer TLS still has its own handshake, server identity verification, and certificate-chain requirements. Inner-layer encryption doesn’t replace those checks.

For WebSocket, check the path and Host. For gRPC, check the service name and other transport parameters. These fields belong to the transport, not the UUID or encryption option. Paths are often matched exactly, so a leading slash, capitalization, or extra characters can matter. If a reverse proxy forwards only specific paths, a request may reach a regular website endpoint even when the address and port are reachable, resulting in a failed handshake or immediate disconnect.

When to Keep Using VMess

You can keep using VMess if your existing service is stable, your client fully supports it, and you don’t need a specific new feature. Migrating means rechecking the server inbound, subscription generation, and client compatibility—not just changing a dropdown. Compare the stability, maintenance effort, and device load of the complete setup rather than the protocol’s age. If your provider has supplied a complete alternative configuration, test it alongside the original and keep the original as a baseline. Switch only after confirming that browsing, file transfers, and UDP apps all work.

3. VLESS: A Lightweight Protocol Still Needs a Complete Security Setup

The Trade-Off Behind a Leaner Protocol

VLESS is designed to be lightweight, separating how proxy requests are represented from external security mechanisms. Unlike VMess, it doesn’t use the same built-in data encryption design; a basic setup typically relies on an outer layer such as TLS or REALITY to protect communications. So “less protocol overhead” doesn’t mean “the entire connection is unencrypted.” Check the full configuration to see what protection is in use; the node type alone doesn’t tell the whole story. And don’t omit the external security settings just because VLESS is described as lightweight.

VLESS, like VMess, typically uses a UUID, but the two protocols format requests differently. Sharing a user ID doesn’t make the protocols interchangeable. In common basic configurations, the encryption parameter in a VLESS share link is set to none. This means protocol-level encryption isn’t enabled by that field; it doesn’t mean TLS or REALITY should be disabled. If the client offers other extensions, verify their availability against the specific core and server implementation rather than inferring support from the basic fields.

Check the Security Layer and Flow Control Separately

With TLS, confirm that the server name matches the certificate identity and that the device trusts the certificate chain. The connection address can be a domain or an IP, but the name used for identity verification must come from the server’s configuration. Being able to reach an IP doesn’t mean that IP is the correct certificate name. Some deployments require the server name to be entered separately. If the client derives it automatically from the address, the result may not suit that deployment. Before entering a value, distinguish the connection destination from the identity being verified.

Flow is another parameter to understand on its own. xtls-rprx-vision is not a transport type or a general speed switch for every VLESS connection. It requires compatible core and server capabilities, as well as a supported transport. Adding flow to a node that doesn’t use this feature can cause authentication or data-processing failures. Conversely, if the server requires a flow setting, a node may not work if that setting is lost during import.

Check Fields in the Client Interface

In v2rayN’s node editor, check settings in this order: address and identity, transport, security layer, and flow control. Follow the same order in v2rayNG to avoid guessing across multiple settings pages. Save a copy of the original before changing anything. If the node comes from a subscription, manual edits may be overwritten on the next update. Put a test copy somewhere separate and note why you changed it rather than overwriting the subscription’s baseline.

The fields visible after import may not match what the core ultimately receives. A client may fill in defaults or convert interface options to a different internal structure. Check configuration-generation messages and startup logs to confirm the result. If you see an unknown-field or unsupported-flow error, check the selected core and configuration combination before deleting anything. The error identifies the parsing stage; the root cause may be an incompatible core, not a typo in the parameter.

Use Cases and Migration Considerations

VLESS suits setups with a compatible server where you want explicit control over the security layer and flow combination. It doesn’t guarantee lower latency than other protocols, especially when the nodes use different server routes. For apps that create many short-lived connections, outer handshakes and connection reuse can have a noticeable effect. For sustained large file transfers, throughput, CPU usage, and server load matter more. Test these use cases separately.

Before migrating from VMess to VLESS, get the complete new configuration and test name resolution, regular web browsing, long-lived connections, and any UDP apps you need. Don’t delete the old group after loading a single page. If the new setup uses REALITY or Vision, make sure the subscription format preserves the required fields. For background and trade-offs, see proxy protocol comparison. For your actual connection, use the parameters supplied by the server provider.

4. REALITY and Vision: Handshakes and Data Streams Have Different Roles

REALITY Is Not a Standalone Proxy Protocol

REALITY is a security mechanism commonly used with VLESS, while Vision is a related data-stream processing mechanism. Clients often group them together under a label such as “REALITY protocol,” but they need to be understood separately when configuring a node. VLESS or another protocol describes proxy requests; REALITY handles the relevant security handshake and authentication; Vision processes data streams under supported conditions. These are distinct roles. Selecting REALITY as the proxy protocol doesn’t make the remaining fields automatic.

REALITY uses TLS-related mechanisms and adds its own authentication parameters. In common deployments, the proxy service doesn’t need the same public-certificate setup as a regular TLS website, but that doesn’t mean the client can skip identity verification. It still needs the correct public key, server name, and short ID. The server’s chosen target and behavior are also subject to constraints; choosing any reachable website doesn’t create a reliable deployment. When setting up a client, use the complete parameters from an existing deployment.

Authentication Fields That Are Easy to Mix Up

The server name may appear as serverName or as sni in a share link, and must be one the server allows. The public key corresponds to the private key held by the server; never request or enter the server’s private key in the client. The short ID, or shortId, must match an ID allowed by the server. It’s usually written in hexadecimal, and its length and value must meet the core’s requirements. It isn’t a free-form label, and you can’t substitute part of a UUID. Some deployments allow specific empty values, but use them only if the server is explicitly configured that way.

The fingerprint setting describes how the client behaves during the relevant handshake and must be supported by the selected core. It isn’t a device name to change at random, and an obscure option isn’t inherently more effective. Share links may use abbreviations such as fp, pbk, and sid, while the client interface displays translated labels. Match each field by its meaning after import; a different label doesn’t mean the field was lost. Core updates may also change field names, so old tutorial syntax can’t replace current core documentation.

What Overhead Does Vision Reduce?

HTTPS application data is already protected by TLS. Carrying it through a proxy security layer adds another layer of processing. Vision optimizes data-stream detection and handling for supported traffic, reducing some repeated encapsulation and copying costs when conditions allow. It doesn’t remove the app’s own HTTPS, and it doesn’t route all traffic through the same optimized path. Request type, connection stage, core implementation, and deployment all affect the result. Theoretical gains don’t translate into a fixed speed multiplier.

For small requests, DNS resolution, connection setup, and network round trips may account for most of the delay, so reducing data-processing overhead may barely affect initial page load. With sustained high-volume transfers, optimization may be more noticeable if the CPU is the bottleneck. If the device isn’t saturated but the server route is congested, changing flow control won’t bypass bandwidth limits. Evaluate task completion time, CPU load, and connection stability together instead of relying on a single latency figure in the client.

What to Check When a Handshake Fails

First confirm that you’re using an Xray core that supports the combination. Then check the address, port, UUID, security type, public key, short ID, server name, and flow. Correct one item at a time and keep the original error category from the logs. For timeouts, check reachability first; for authentication failures, verify the complete set of parameters; for unsupported fields, check the core and import format. For background, see REALITY and XTLS Vision explained. The client can’t enable this combination unless the server provides a matching endpoint.

5. Trojan and Shadowsocks: Two Different Paths to Simpler Setups

Trojan Uses TLS for Connection Security

Trojan uses TLS to protect the connection and carries proxy authentication and requests within it. Users typically enter a password rather than the UUID common with VMess or VLESS. This password is a proxy credential, not a system login or website account password. The client and server must also agree on transport and security settings. Password authentication doesn’t mean you can ignore the server name or certificate verification.

Trojan’s connection quality depends heavily on the TLS setup. An expired certificate, a name mismatch, an incorrect system clock, or an incomplete certificate chain can prevent a connection. Check the server details and device time first. Leaving insecure connections enabled weakens server identity checks and can hide deployment problems. Even if a temporary test helps pinpoint a certificate issue, fix the name or certificate chain rather than keeping the test setting as your normal configuration.

Shadowsocks Focuses on Encrypted Proxy Forwarding

Often shortened to SS, Shadowsocks uses a relatively streamlined configuration for encrypted proxy forwarding. Common fields include the server, port, password, and encryption method. Its encapsulation and authentication differ from TLS-based setups, so don’t copy a TLS server-name field into it. Fewer parameters can reduce configuration errors in deployments that don’t need extra transport features, but suitability still depends on the specific methods supported by the client, core, and server.

Legacy methods, AEAD methods, and newer protocol variants have different compatibility limits. Some newer methods have strict key format and length requirements, so an arbitrary text password won’t work. Don’t assume every implementation is interchangeable just because it uses SS. If the client reports that an encryption method is unsupported, verify its full name and the current core’s capabilities. Don’t choose a similar-sounding substitute; the two sides generally can’t decrypt traffic if they use different methods.

Password, Encoding, and Extension Parameters

Share links may encode passwords and other fields to avoid ambiguity from separators and special characters. When copying manually, truncating encoded text, adding spaces, or decoding it more than once can change the actual credentials. Prefer the client’s built-in import, then check the visible fields. If the server requires an extra transport extension, the server and password alone may not be enough. Confirm that the current core implements the extension rather than relying on a node label.

Trojan and Shadowsocks may both support UDP, but protocol support alone doesn’t mean an app’s UDP traffic is reaching the client. Check the local inbound, TUN or system traffic capture, and whether the server permits forwarding. If web browsing works but live voice apps don’t, don’t start by changing the password. First check the app’s transport, whether the client captures that traffic, and whether routing sends it to the intended outbound. Then check the server and return path.

Choose for the Existing Setup, Not by Name

If you already have a well-maintained TLS service and complete Trojan settings, Trojan can fit neatly into an established certificate-management workflow. If the server offers a compatible Shadowsocks method and your device has limited resources, you can test its real-world performance as well. Neither protocol can be judged in isolation from the server route, encryption implementation, and app requirements. For most users, complete settings, core support, and reliable performance matter more than a protocol name that sounds more advanced.

6. Connection Speed, Resource Use, and Mobile Battery Life

Separate Connection Setup from Sustained Transfers

What users call “speed” includes at least DNS lookup time, connection setup, time to first byte, and sustained throughput. A client’s latency test may cover only some of these, depending on how it works. A fast response from a port doesn’t mean the target website will be fast, and a quick page load doesn’t guarantee fast large-file transfers. Before comparing protocols, define the goal: faster page loads, better sustained throughput, or lower battery use while maintaining a background connection.

TCP, TLS, and additional transport handshakes can add round trips during connection setup. Connection reuse and session resumption may reduce repeated overhead, depending on the implementation and connection lifecycle. WebSocket and gRPC aren’t simply slow or fast: they add structure but may meet specific deployment and connection-management needs. On high-latency networks, an extra round trip may matter more than a small difference between encryption algorithms. On low-latency networks, the bottleneck may instead be the CPU or server bandwidth.

Resource Use Depends on the Entire Processing Chain

CPU load depends on the encryption algorithm, hardware acceleration, encapsulation layers, connection count, and traffic volume. Memory use also includes the client interface, subscription entries, DNS cache, connection buffers, and logs—not just the protocol. A combination with low overhead per connection may still use substantial resources under high concurrency. For a fair comparison, use the same client, similar background tasks, and identical test content. Interface rendering or other apps can otherwise skew the results.

Multiplexing lets multiple logical connections share an underlying connection, but it also changes congestion behavior, error recovery, and connection lifetime. It can reduce the cost of repeated handshakes in suitable scenarios, but packet loss or a dropped connection can affect multiple requests at once. Don’t treat a multiplexing toggle as a universal speed boost or apply settings from one setup directly to combinations such as Vision. Keep the defaults unless you know what the current core supports and have a specific app requirement to test.

You Can’t Estimate Phone Battery Use from the Protocol Alone

Mobile power use is influenced by wireless radio wakeups, retransmissions on weak signals, frequent polling, background updates, and app activity. Even a steady trickle of traffic can keep the wireless radio from entering a lower-power state. On the other hand, if the system repeatedly kills the connection and forces it to reconnect, that also takes extra work. Keeping a connection alive and minimizing battery use can be competing goals. Consider the OS battery policy, how often you use the connection, and whether the app really needs a persistent connection.

In v2rayNG, the system VPN interface captures app traffic, but that doesn’t mean every app generates the same amount. Full-device capture, per-app exclusions, and background behavior all affect battery use. If you notice unusually high drain, check the system’s battery usage statistics, then look for repeated reconnects, automatic tests, or excessive logging. Don’t disable every background permission at once; the connection might stop working with the screen off. Test screen-off standby, foreground browsing, and network switching separately.

Compare with a Repeatable Test

Keep two complete configurations and alternate between them on the same device and network, testing the same tasks. Record whether each test starts cold, uses connection reuse, and what the network conditions are. Start with a brief web request, then try a sustained download, and finally observe a commonly used app in the background. Repeat each test several times, excluding updates, cloud sync, and other high-traffic tasks. Don’t run two TUN clients at once: competing routes can skew the results or even send one client’s traffic through the other.

7. V2Fly and Xray: Similar Configurations Aren’t Automatically Interchangeable

The Client Interface and Core Have Different Jobs

Project V provides useful context for this ecosystem. V2Fly and Xray are distinct development paths among its related core families. The client manages subscriptions, graphical settings, system proxy options, and startup controls; the core reads the configuration and handles connections. They aren’t the same thing. The v2rayN interface name doesn’t mean it runs only one type of core, and a protocol shown in the interface isn’t necessarily implemented by the currently selected core. Actual capabilities depend on the core in use and the configuration it generates.

The two core families share some concepts, such as inbounds, outbounds, and routing, but their feature sets and field requirements aren’t identical. Features from the Xray ecosystem, including REALITY and Vision, can’t be handed to V2Fly unchanged just because both use JSON configuration files. Likewise, check whether an Xray configuration uses the same semantics as the corresponding V2Fly setup. Assess compatibility at the level of protocol, transport, security layer, and specific fields—not simply by noting that both belong to the V2Ray ecosystem.

Choosing Among Three Clients

For Windows, macOS, and Linux desktops, start with v2rayN for managing subscriptions, reviewing logs, and adjusting routing in one place. On Android, v2rayNG, based on the Xray line, is usually the first choice. Consider v2flyNG as an alternative when an existing configuration depends on V2Fly behavior. The similarly named mobile clients don’t just offer different interfaces; they use different execution environments. See the platform downloads and comparison of the three clients for more details.

Switching cores isn’t just a matter of replacing an executable. A client may generate different fields for different cores or limit which protocol options are available. If startup fails, check the active core and error logs first, then confirm the features the node requires. If the interface has been updated but the client still runs a different core environment, import and configuration generation may succeed before startup fails. Use the client’s supported core-management options. Don’t move files between locations manually without understanding the paths and how they’re called.

Understand the Configuration Structure with a Shared Skeleton

This example shows the basic relationship between an inbound and an outbound: a SOCKS inbound accessible only from the local machine and a direct outbound. It doesn’t connect to a remote proxy server or include any node credentials. Before saving it as a configuration file, confirm that the target core accepts these fields. The basic structure is straightforward: the inbound receives app requests, and the outbound determines how they’re sent. To use a remote proxy, replace the outbound with complete settings that match the server.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

The loopback address limits where the listener is available. If you change it to listen on a local network address, consider access controls and the system firewall; don’t expose the listener more widely without authentication. Choose a port that isn’t already in use by another client to avoid an address-in-use error. For how configuration files map to client interface options, see inbounds, outbounds, and routing explained.

Verify in Two Stages When Migrating

In the first stage, test one node with the simplest routing rules. Confirm that the core starts and an app can connect. In the second stage, restore DNS, split routing, multiplexing, and other custom settings. This helps separate protocol-support issues from problems caused by additional rules. Don’t keep deleting unknown fields until the core starts; a removed field may be essential for security or routing. First identify which core and feature the field belongs to, then adapt it to the target core’s supported format. If there’s no equivalent, keep using that feature in the original environment.

8. Subscription Compatibility and Choosing for Your Use Case

Share Links, Subscriptions, and Runtime Configurations

A single-node share link describes one connection. A subscription URL fetches a set of connection details that may be updated over time. A core runtime configuration also includes execution settings such as inbounds, routing, and DNS. These are different formats. Pasting a subscription URL into a single-node import field, or importing a full runtime configuration as a share link, can fail. Before troubleshooting, identify which type of content you have and choose the matching import option in the client. For the full process, see how to import a subscription.

Common share-link schemes include vmess://, vless://, trojan://, and ss://. They differ in how they encode data, name parameters, and represent extensions. Even a single protocol may have multiple legacy share-link formats. A link opening in a browser or text that looks complete doesn’t prove the client can parse it. Subscriptions may also return different content depending on the requester. If the URL works but the format doesn’t suit your client, ask the provider for a compatible format instead of changing the file extension.

What Can Be Lost in Conversion?

Subscription converters generally map recognized fields into another format; they don’t verify whether the server actually works. A converter may ignore or replace unfamiliar transports, security mechanisms, flow settings, or extensions with defaults. A node still appearing in the list only confirms that its basic record was retained—not that all its features survived. After conversion, check key settings such as REALITY authentication parameters, Vision flow, the WebSocket path, and the gRPC service name.

Use the target client format generated directly by the provider whenever possible to avoid unnecessary conversions. If conversion is unavoidable, keep the original subscription for comparison and check every field on one node first. Subscription URLs can grant access to your account, so don’t submit them to online tools from unknown sources. A change in node count after an update may reflect your plan, group filters, or server changes; it doesn’t automatically mean the protocols are incompatible. For more, see share links and subscription URLs explained.

Choose Based on the Task

For everyday browsing, prioritize the stability of the existing service and connection setup time. Use a configuration the client can parse completely. For large file transfers, focus on sustained throughput, CPU use, and recovery after interruptions. Compare flow control and encryption implementations only if data processing is the bottleneck. For extended mobile use, test network switching, recovery after the screen turns off, and battery policies together. On lower-spec devices, reduce unnecessary encapsulation and background polling—but keep any security mechanism required by the deployment.

For live voice or other UDP apps, check the local traffic-capture and server-forwarding path before comparing protocols. If a subscription is used across devices, choose a combination supported by every device’s core or ask the provider for client-specific subscription formats. Using the same subscription URL doesn’t mean you can sync an entire configuration directory between devices. Desktop ports, per-app rules on mobile, and system proxy settings vary by platform; maintain them separately instead of copying settings between devices.

Keep a Reproducible Baseline

When settling on a configuration, record the client, active core, protocol combination, and tasks you tested. Promotional names that don’t affect your decision aren’t necessary. Keep a recoverable copy before updating a subscription or switching cores. After making changes, test one node before restoring all your rules. If something breaks, return to the last working baseline and check each layer in order: address, authentication, security, transport, and routing. The right protocol isn’t the one with the most options in a menu; it’s the one your device can run correctly and that reliably handles the tasks you actually need.