V2Ray Protocols and Cores
Technical Reference for Choosing a Client

Protocol and configuration layers: how to read a node

Break the connection into four questions

A node in your client is a set of connection parameters, not a standalone protocol switch. When reading a configuration, ask four questions: Which server are you connecting to? How is your identity authenticated? How is the data transported? Which security mechanism protects the connection? The server address and port identify the endpoint; VMess, VLESS, Trojan, or Shadowsocks define the proxy protocol; TCP or WebSocket defines the transport; TLS or REALITY relates to the security layer. These elements interact, but they are not interchangeable options at the same level.

For example, with “VLESS + WebSocket + TLS,” check the user ID, WebSocket path, request host, and TLS server name separately. A correct path won't fix an incorrect user ID, and a correct server name doesn't mean the remote server is listening on that port. Some clients put all these fields in one window, which can make it seem as if choosing a protocol completes the setup. Use the full set of parameters provided by the server and check each layer rather than guessing from the node label.

System proxy and TUN operate at another layer

The system proxy determines whether apps send requests to the local proxy endpoint. TUN uses a virtual network interface to receive traffic routed through it. These options change how traffic enters the client; they won't turn VMess into VLESS or fix failed authentication on the remote server. If one browser connects but another app doesn't, first check whether the app respects the system proxy. If all apps fail, troubleshoot in order: local endpoint, core outbound, then remote endpoint.

Know where each domain is resolved

If the server address is a domain name, it must be resolved before connecting. The domain of the destination website may instead be resolved by the local app, the client’s DNS module, or the remote server. These are separate resolution paths. Changing routing rules for destination domains may not affect how the server’s domain is resolved. If a domain address fails but entering an IP address works, check endpoint DNS resolution and address-family selection before changing protocols. Using an IP address is a troubleshooting step; keep the correct server name for the security layer.

Use the same layers to choose a setup: first check which combinations your service supports, then whether the client’s core implements them, and finally whether you need TUN, split tunneling, or subscription management. On desktop, start with the v2rayN download page and select your platform. If you only have a subscription link, import it first and then inspect the node details. Switching the security layer to a different option without checking compatibility usually breaks the configuration.

VMess and VLESS: authentication and encryption trade-offs

VMess: design background and compatibility

VMess is a proxy protocol in the Project V ecosystem. Its design includes user authentication and data protection, with a relatively comprehensive protocol-processing flow. It remains common in existing subscriptions, so its earlier origins alone are no reason to consider it obsolete. Check whether the current client core and server implementation are compatible, whether the configuration is complete, and whether the connection meets your needs. Data protection within the protocol and outer TLS belong to different layers; using both doesn't simply mean duplicating an encryption setting.

Common VMess troubleshooting points include the user ID, encryption settings, and system time. Authentication involves time-based checks, so a clock that's significantly off can cause the handshake to fail. Enable automatic time sync rather than repeatedly refreshing the subscription. Older configurations may contain additional identity parameters, while newer implementations generally use AEAD authentication. Ask your service provider whether legacy fields still apply; don't fill them in based on old screenshots or assume support for legacy parameters guarantees interoperability across all versions.

VLESS leaves security to the overall configuration

VLESS simplifies protocol processing and does not provide the same data encryption at the protocol layer as VMess. It's commonly paired with TLS or REALITY. Simpler doesn't automatically mean safer or faster on every connection. On public networks, make sure you understand how the outer security layer is established. Changing a VMess node’s protocol dropdown to VLESS won't work unless the server has a matching endpoint. Both client and server must be configured for the change; switching the client alone isn't enough.

The user ID in a VLESS configuration is still an identity parameter; don't confuse it with the TLS server name. Flow-control fields also depend on the implementation. If your provider specifies Vision-related settings, check the transport, core support, and server requirements. Not every VLESS node uses the same flow control, and seeing REALITY doesn't mean you should add a flow-control value. Keeping settings explicitly provided in the subscription is more reliable than applying supposedly universal parameters.

How to choose between them

If your existing VMess configuration works reliably and imports correctly into your target client, there's no need to switch based on a blanket claim that “newer protocols are faster.” If the server explicitly offers VLESS with a suitable security layer and your client uses a core that supports that combination, you can test it with the original parameters. Keep the server, test destination, and local traffic-routing method constant when comparing options. Otherwise, differences in endpoint load, network path, and routing policy will obscure protocol differences; your results will compare two nodes, not the protocols themselves.

Before migrating, keep the original configuration and import the new one into a separate group. Test web access, persistent connections, and any UDP apps you need before deciding whether to replace the default node. Don't overwrite a working entry and troubleshoot afterward. If the new configuration fails only with one core, check transport and security-layer support. If it fails with every core, revisit the server parameters and network reachability. For import instructions, see the v2rayN subscription import tutorial. This chapter explains how the fields relate.

Trojan and Shadowsocks: two connection models

Trojan relies on a complete TLS connection

Trojan typically carries proxy requests over a TLS connection and uses a password for authentication. Its configuration screen may look simple, but that doesn't mean you only need an address and password. The server name, certificate validation, and transport settings matter too. The IP address used to connect can differ from the domain used for identity verification: the former locates the server, while the latter establishes the expected TLS identity. If the server provides a dedicated name field, keep it rather than copying the node address into every field.

To troubleshoot certificate errors, start by checking whether the name matches, the system clock is accurate, and the trust chain is complete. Disabling certificate verification changes the security assumptions and shouldn't be a routine fix. If the server uses a custom deployment, confirm which transport it uses. Different cores and clients may represent extended combinations differently. A working standard Trojan endpoint doesn't prove that an additional transport extension is supported; check the actual implementation and parameters.

The Shadowsocks method field is required

Shadowsocks, often abbreviated to SS, uses a shared-key model. The client needs the server address, port, password, and encryption method. This differs from configurations that rely primarily on outer TLS; don't put an SS method name in the VLESS security-layer setting. Older methods differ from modern AEAD methods, and the server’s supported options determine what to use. Changing the method to a seemingly stronger option in the client won't upgrade the server; it will prevent the two sides from interpreting the data correctly.

Some newer Shadowsocks methods have strict key encoding and length requirements, so an arbitrary short phrase may not work as a general-purpose password. A method appearing in the client doesn't guarantee it's implemented by the running core. If a method disappears on import, a password is truncated, or authentication keeps failing, compare the result with the original share format rather than retrying the same connection. Check plugin parameters too: basic SS support doesn't mean the client can run a particular external plugin or extended transport.

UDP, connection reuse, and practical limits

For either protocol, “UDP supported” alone doesn't guarantee that a particular app will work. The remote server must allow forwarding, the client must enable the capability, the app’s traffic must enter the proxy, and routing must permit it. Some tests check only whether a TCP connection can be established; they say nothing about voice, games, or other UDP apps. If websites work but a particular app doesn't, first check its transport and traffic-routing path, then check remote support—not the password.

For configuration maintenance, Trojan usually hinges on the TLS name, certificate, and password; SS usually hinges on the method, key, and optional extension parameters. If the server offers only one, use a client that supports the original combination. There's no need to convert it to another protocol just to standardize names. On desktop, inspect the full node parameters in v2rayN. On Android, choose v2rayNG or v2flyNG based on core requirements. Using the same server parameters on both platforms helps distinguish client-specific issues from server-side problems.

TLS and REALITY: check security-layer parameters one by one

Separate identity validation from the network endpoint

TLS protects the connection, and in typical use it also verifies the remote server’s identity. The server name expresses the expected identity and doesn't have to match the address used to connect. ALPN negotiates the application-layer protocol; it's not a general-purpose speed setting. Set these values only when required by the server configuration. Ignoring name or certificate errors to make a connection work removes the original verification safeguards. First confirm that your configuration source and the remote deployment match.

With WebSocket or another intermediary transport, the request host, TLS server name, and path may each affect a different stage. Some deployments use the same domain for all three; others don't. When troubleshooting, list each field and its purpose rather than replacing them all just because the interface has only a few input boxes. Being able to open a domain in a browser proves only that browser access works; it doesn't verify proxy authentication, the path, or forwarding on the remote server.

REALITY is not a fifth outbound protocol

REALITY is a security-layer mechanism in the Xray ecosystem, commonly used with VLESS. Its configuration differs from standard TLS certificate deployments; changing the security-layer setting to REALITY alone doesn't complete a migration. Clients typically need the server name, authentication public-key parameters, and shortId from the server. You may also need to check the fingerprint and flow control. Clients may label related fields “public key” or use names that change as cores evolve. Follow the core documentation and the subscription provider’s field mapping.

The public key corresponds to the private key held by the server; it can't be derived from a domain name. The shortId must be in the set allowed by the server, and an empty value is valid only if the server explicitly permits it. Don't reuse these parameters from another node. The connection address locates the endpoint; the server name must meet the deployment’s requirements. They serve different purposes. If these fields change after a subscription update, the old configuration may no longer work. Reimport the complete parameters rather than updating only the address and port.

Fingerprint and flow control aren't performance toggles

The client fingerprint relates to how TLS handshake characteristics are implemented. Available values depend on the core, so compatibility can't be inferred from a label. Flow control is likewise constrained by the protocol combination and remote configuration. If the client reports an unknown parameter after import, first check that you've selected the right core, that the configuration format can represent the fields, and that conversion hasn't dropped information. Defaults can differ between clients, so inspect the saved configuration rather than relying on the original share text.

A sensible check order is: confirm whether the server uses standard TLS or REALITY, then verify the server name. For REALITY, also check the public-key parameters and shortId, followed by the fingerprint, flow control, and transport. Change one related group of fields at a time and keep the original values so you can identify the cause. For handshake errors, use the connection troubleshooting guide to interpret logs, but never post a full configuration containing authentication parameters.

Connection speed, resource use, and mobile battery life

Separate initial connections from ongoing transfers

Before asking “Which protocol is fastest?”, define what you're measuring. Opening a page for the first time involves DNS resolution, connecting to the server, protocol authentication, and possibly a TLS handshake. Sustained downloads depend more on link capacity, congestion, remote load, and device performance. Removing one processing step won't noticeably reduce page-load time on every network. If the test destination or server endpoint differs, you can't attribute the full result to the protocol—especially not use it to create a universal speed ranking.

Handshakes are sensitive to round-trip time, while large file transfers depend more on sustained throughput. Connection reuse can reduce repeated setup in suitable scenarios, but it can also affect contention between connections and the scope of a failure. A reuse toggle in the client doesn't mean it should be enabled for every node. Some combinations have specific reuse or flow-control constraints, so follow the server’s recommendations. To test the effect, hold other settings constant and compare short requests, persistent connections, and concurrent access separately.

CPU and memory use depend on the whole processing chain

VMess processing, SS encryption methods, TLS handshakes, data copying, and transport encapsulation all add overhead. Hardware acceleration in modern processors changes their relative costs. VLESS reduces protocol-layer processing, but its outer security mechanism still uses compute resources. TUN, DNS modules, and rule matching use resources too, so total client usage can't be attributed to one protocol. If memory use changes after switching modes on desktop, first check whether you also enabled extra core features or rule sets.

On mobile, watch wakeups and reconnects

Battery use on Android isn't just about encryption. It also depends on keeping the wireless connection active, background heartbeats, DNS requests, and repeated reconnects after failures. The same protocol can behave differently with a weak signal or frequent network changes. If standby battery drain rises after enabling the client, check for repeated failure logs, apps that connect too often, and overly frequent subscription or health checks. Changing protocols without fixing the reconnect loop usually won't address the underlying cause.

When comparing battery use, keep the apps and usage pattern the same under similar signal conditions. Separate screen-on tests from background standby tests; a brief battery percentage change doesn't prove one protocol is better. On desktop, compare idle and busy states, and don't run other downloads during the test. If you need non-browser apps to use the proxy, read how v2rayN TUN mode works and how to configure it. Fix the traffic-routing path before measuring the added overhead.

V2Fly, Xray, and the roles of three clients

Core families and graphical interfaces are different layers

Project V provides useful background for understanding this ecosystem. V2Fly continues development related to V2Ray, while Xray shares history with V2Ray and evolves independently. They have common foundations in protocols, transports, and configuration structures, but each has developed its own features. Open source means you can review and use code under each project’s license; it doesn't mean different projects will always share identical configuration semantics. For a specific feature, check the implementation in the core you're running, not just its family name.

Graphical clients manage subscriptions, edit nodes, launch cores, and control the system proxy. Cores handle connections, implement protocols, and apply rules. v2rayN is the primary desktop client for Windows, macOS, and Linux. Different interface styles or packaging for the same client don't constitute different proxy protocols. When choosing an installer, first check your platform and processor architecture, then confirm which core will run and what configuration it receives.

Choose an Android client based on core requirements

v2rayNG is an Android client that uses the Xray core; v2flyNG is an alternative using the V2Fly core. Their import workflows may look similar, but their cores don't necessarily have the same capabilities. If you need Xray features such as REALITY, first confirm that v2rayNG supports your specific combination. Don't assume v2flyNG can handle it unchanged. For an existing V2Fly configuration, assess v2flyNG based on its actual transport and protocol support rather than the similar name.

If v2rayN lets you select a core, check which one receives the node and routing configuration. The interface accepting a field only means the editor can store the text; it doesn't prove the backend core implements the feature. If startup fails, check the core error first. If the connection fails, then inspect handshake and routing errors. An unknown-field or unsupported-transport message points to core compatibility, not a system proxy toggle. These errors occur at different stages.

Check compatibility field by field

Two cores both using JSON doesn't mean you can swap their entire configurations directly. A protocol may have the same name in both, while extension parameters, defaults, transport implementations, or DNS behavior differ. When migrating, start with the smallest working outbound configuration, then add routing, DNS, and other features one at a time. Copying a complex setup all at once can carry over unsupported fields and dependencies, making it look like the node is broken when the real issue is a configuration load failure.

When upgrading a client, distinguish interface changes from core changes. A new interface option doesn't necessarily mean existing configurations need editing; a core update may also flag legacy fields or change compatibility. Keep a recoverable copy of the configuration, note the current core, and test a single node first to reduce migration effort. For installation and environment issues, see v2rayN first-time installation and setup. The download center covers clients and platforms, so there's no need to look for a separate core download page.

Subscription format compatibility: what to check after import

Subscription URLs, share links, and core configurations

A subscription URL usually points to a network resource that returns node data. A single-node share link encodes one connection configuration, while a core configuration file may also include local inbounds, DNS, and routing. These serve different purposes; a long-looking string isn't enough to tell you how to import it. Some clients automatically recognize several formats, but that recognition has limits. Identify whether you have a subscription URL or a single-node entry, then choose the right import option. This avoids treating a webpage URL or full configuration file as a node link.

Traditional subscriptions often contain multiple share entries encoded in Base64, along with other structured formats. Base64 is an encoding, not encryption; being able to decode it doesn't mean every line is a valid node. VMess share entries often put fields in encoded JSON, VLESS and Trojan commonly use URIs with query parameters, and SS has several encoding formats. Formats differ in which newer fields they can represent, so pay close attention to security layers, flow control, and extended transport parameters when converting subscriptions.

Valid encoding can still lose meaning

Passwords, paths, and query parameters may contain special characters that must follow the relevant format’s encoding rules. For example, URL separators can't be used as ordinary characters without care, and line breaks or truncation when copying through a chat app can break a link. When troubleshooting, recopy from the original source rather than decoding, editing, and re-encoding it by hand. If a subscription returns a login page or error message, the network request may succeed but it still won't produce valid nodes.

The example below is a minimal local SOCKS inbound, included to show that a core configuration and a node share link are different structures. It isn't a complete client configuration and can't be imported as a subscription. It must be placed in the appropriate core configuration with an outbound configured. The example binds only to the loopback address, so it doesn't expose the local proxy endpoint to other devices. When using a graphical client, change the local port in its interface and let the client generate the configuration; don't also edit the generated file by hand.

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

Subscription conversion can't add core capabilities

Subscription conversion reformats existing information; it can't implement a feature the target client doesn't support. If the target format can't carry the parameters required by REALITY, the node list may look fine while the handshake fails. Compare the original configuration and check that the protocol, security layer, server name, public-key parameters, and shortId were preserved. If the original was missing fields, a conversion service can't infer the right values. Ask the configuration provider for the complete details.

Subscription URLs often include identifiers that grant access to account configuration, so treat them as sensitive. Submitting a URL to a third-party conversion service gives that service access to the subscription contents. Keep links, QR codes, and authentication fields out of screenshots too. If an update fails, first check the subscription’s validity and response, then distinguish between a direct update failure and one that occurs through the proxy. For troubleshooting steps, see how to diagnose subscription parsing failures; for conversion limits, see subscription conversion FAQs.

Choose a setup for your use case and verify the connection

Already have a working subscription? Check compatibility first

If you already have a valid subscription, the practical choice is a client that can represent all its parameters correctly. For desktop, start with v2rayN and select the installer for your operating system and processor. On Android, choose v2rayNG based on core requirements; consider v2flyNG for existing V2Fly configurations. Don't rank protocols in advance and force every node to use the name at the top of the list. The server determines which combinations are available; the client’s job is to reproduce them correctly, not replace them.

For your first test, keep the workflow simple: import the subscription, choose a node with complete parameters, and test access from an app known to support the system proxy. Once the basic connection works, add routing rules, TUN, or other features. Enabling everything at once makes it hard to tell whether a failure involves the protocol, DNS, rules, or permissions. For quick steps, see the subscription import guide; for Android, see importing a subscription into v2rayNG.

Treat mobile use and complex apps separately

Mobile devices often switch networks, so pay attention to reconnects, background operation, and system battery management—not just a single connection test. If the connection drops after sleep, check whether the system is restricting the client, whether it reconnects after a network change, and whether the endpoint domain can be resolved again. To reduce battery use, unnecessary health checks and repeated failed connection attempts matter more than a particular protocol name. Keep subscription update intervals reasonable; see the v2rayNG subscription update guide.

On desktop, consider TUN only if an app doesn't respect the system proxy, and check system permissions, DNS, and routing loops as well. Enabling a virtual network adapter doesn't mean every connection should go through the remote server or that local network access can be ignored. Remote work, LAN devices, and local services may need direct routes. Router or secondary-router deployments involve a different environment, including processor architecture and configuration maintenance. For more, see an overview of running Xray on a router.

Narrow down failures with layered checks

Verify the connection in four steps. First, confirm the client core starts and the local endpoint has no port conflict. Second, check that the server domain resolves and the endpoint is reachable. Third, verify protocol authentication and the security-layer handshake. Fourth, check the target app’s DNS, routing, and transport requirements. Each step should have observable evidence. An open port doesn't prove authentication succeeded; successful authentication doesn't prove the destination website is reachable; and a working browser doesn't mean other apps are using the proxy.

When comparing setups, record the client, core, protocol combination, and traffic-routing method, and change only one variable at a time. If the issue follows a particular node, check its server parameters and remote status. If it follows an app, check proxy support and routing. If it appears only after switching networks, check DNS, reconnects, and network restrictions. Choose based on maintainable parameters, reliable performance in the apps you need, and acceptable device impact. No protocol has a universal ranking independent of its deployment environment; keeping a recoverable configuration is more useful than repeatedly applying unfamiliar settings.