V2Ray Protocols
and Core Reference

VMess authentication and transport trade-offs

VMess is an earlier proxy protocol in the Project V ecosystem, with mechanisms for user identity, request framing, and data protection. It has a long history of use, and many older subscriptions and deployment guides still rely on it. When evaluating VMess, distinguish between a protocol that remains usable and old instructions that may no longer apply. Authentication methods and auxiliary fields in older configurations may not suit current cores. Start with the server's actual implementation; don't infer compatibility from a guide's age or a node name.

User ID, encryption method, and time

“User ID” is usually a UUID used for authentication, not a free-form label. Generating a UUID in the client doesn't authorize it on the server; it must match the server's user configuration. The “encryption method” also has a protocol-specific meaning and shouldn't be confused with the TLS setting. Automatic selection typically lets the implementation choose a suitable method; check that both sides support an algorithm before setting it manually. Hardware acceleration affects the actual processing cost, so an algorithm's name alone doesn't establish a reliable speed ranking.

VMess authentication includes time-related checks, so a significantly incorrect system clock can cause authentication to fail. First enable automatic time synchronization and check that the displayed date, time, and time zone look right. The time zone affects display; the underlying system clock must be accurate. Changing only the displayed time without correcting the actual clock won't solve the issue. Don't repeatedly rebuild subscriptions or change encryption methods before checking the clock; that introduces variables and makes the problem harder to reproduce.

Older shared configurations often include alterId. Common current VMess AEAD setups typically use a value of zero or handle it according to the client implementation; it's not a setting where a higher value means better security. If a subscription retains this legacy field, check whether the server uses the corresponding authentication method and how the client interprets it. Don't copy a nonzero value from an old guide without checking. If server documentation conflicts with the imported settings, rely on the actual deployment and the documentation for the core in use, rather than changing both sides at random.

Why WebSocket and TLS often appear together

VMess can use different transports. WebSocket with TLS is common in deployments that use a reverse proxy: the client completes the TLS handshake, sends the correct HTTP upgrade request, and then starts a VMess session. So an open port doesn't prove the path is correct. The WebSocket path and Host must match the deployment, and the reverse proxy must forward the request to the right backend. A typo in the path, an extra or missing trailing slash, or the wrong target site can cause a failed handshake or return a regular webpage instead.

This combination adds framing and handshake steps, but it doesn't mean that the full cost is repeated for every request. Connection reuse, connection pools, app behavior, and timeouts on intermediate proxies all affect the result. Conversely, direct TCP has less framing, but that doesn't guarantee faster page loads in every environment. If server locations, link quality, or DNS differ, results from two differently deployed servers can't reliably show whether VMess itself is faster or slower.

Keep an existing deployment or migrate?

If an existing VMess configuration works with maintained client and server software, its age alone isn't a reason to migrate. Check whether it still uses an old authentication method, imports reliably, has clear transport settings, and is backed by a maintained server. Moving to VLESS requires the server to create a matching inbound and provide new settings; changing the client dropdown to VLESS isn't enough. The protocols use different authentication and request formats, so renaming one side isn't a compatibility shortcut.

For a new deployment that depends on Xray's VLESS and REALITY combination, configure it accordingly. To connect to an existing VMess server, keep the protocol and transport aligned. If import succeeds but the connection fails, compare the original shared configuration with the editor's encryption method, transport, security layer, and path, then check the logs. For general troubleshooting, see Frequently Asked Questions. Don't mistake a local system proxy issue for VMess incompatibility.

Where Trojan and Shadowsocks differ

Trojan and Shadowsocks are two other common options, but they focus on different design choices. Common Trojan deployments center on a TLS connection and password authentication, making the certificate and server name important settings. Shadowsocks uses a lean proxy-forwarding design with authenticated encryption and has multiple generations of methods. “Password required” doesn't mean the security layers are identical, and an SS node doesn't necessarily use one fixed algorithm or feature set.

Trojan: certificates and server names matter, too

When adding Trojan in v2rayN or v2rayNG, you'll usually need an address, port, password, and TLS settings. Preserve the password exactly; don't let the input method replace its symbols. The remark is just a label and isn't used for authentication. The server name must match the deployment requirements and certificate validation. The address can be an IP while validation uses a domain, but only if that's how the server is set up. If the certificate name doesn't match, check SNI and the server certificate first—not the password length.

A first Trojan connection usually involves a TCP connection and a TLS handshake. Connection reuse can affect the experience with many short requests, while throughput and server resources matter more for sustained transfers. TLS is a mature, general-purpose security foundation, but real-world performance still depends on the implementation, certificate deployment, intermediary proxies, and handshake resumption. TLS doesn't automatically make a connection slower, and having only a few common settings doesn't mean there's just one thing to check when troubleshooting.

Shadowsocks: match the encryption method exactly

Common Shadowsocks settings include server, port, password, and encryption method. Newer AEAD methods and earlier stream-based methods come from different generations of design; AEAD also authenticates the data. The client and running core must support the method specified by the server. Similar names in a dropdown aren't interchangeable. The connection won't work with the wrong method, even if the password is correct. Importing an old configuration only shows that the client recognized its sharing format; it doesn't prove the current core accepts the algorithm.

Methods such as AEAD 2022 may require a specific key format. Don't assume you can enter any ordinary text password. Some deployments support extensions such as multiple user keys, and the shared configuration must preserve them. Check the server's method and client support first, then copy the key exactly. Truncating content with separators or letting a subscription converter reinterpret it as a traditional password can change its meaning. Key format is a protocol requirement, not a display choice.

For a basic Shadowsocks setup, TCP and UDP support also depends on how the client receives traffic. A server allowing UDP doesn't mean apps using the client's system HTTP proxy will get transparent UDP forwarding. Some shared links include plugin parameters. If the client and core used here don't implement that extension, keeping only the server and password doesn't make an equivalent configuration. Ask for a complete setup supported by both sides instead of deleting unrecognized fields and carrying on.

Choose based on the existing deployment, not the number of fields

If the server already provides a correctly maintained Trojan configuration and the client fully supports its transport and TLS settings, there's no need to switch protocols just to reduce the number of settings. For Shadowsocks, record the exact method and key format, especially across different generations. Don't “improve compatibility” by disabling security checks or removing unknown settings. Preserving an error message is more useful for troubleshooting than making a connection stop reporting errors after changing what the configuration means.

Also consider ongoing maintenance: is there a reliable process for renewing certificates? Are key changes reflected in subscriptions? Does the target core support the required extensions? For beginners connecting to an existing service, matching the current deployment matters more than changing the protocol. If a password or subscription may have been exposed, revoke it on the server and issue a new one; changing the local remark isn't enough. Client logs and shared links can contain sensitive settings, so remove credentials and full subscription URLs before asking for help.

Connection overhead, resource use, and mobile battery life

To answer “Which protocol is fastest?”, first define what you're measuring. For the first connection, consider DNS resolution, connection setup, and the security handshake. Web browsing also depends on the destination site, connection reuse, and the number of assets. Sustained downloads depend more on throughput, packet loss, and server capacity; voice and real-time apps care about jitter and the UDP path. These metrics can vary independently. A latency figure in the client doesn't represent every app, and two numbers from different servers don't reveal a protocol's inherent speed.

Separate handshake overhead from sustained transfers

DNS, TCP setup, TLS or another security handshake all add time before a connection is ready. WebSocket and gRPC have their own setup steps, too. Connection reuse and handshake resumption can reduce repeated overhead, while network retransmissions can magnify the cost of a failed attempt. For apps that frequently open new connections, reducing unnecessary round trips may help. For a long-lived data stream, the initial handshake accounts for less of the total time. Keep these scenarios separate in tests; a single long download isn't a substitute for measuring short-connection performance.

CPU use depends on the encryption algorithm, hardware instructions, data copying, and implementation optimizations. An algorithm that is efficient on one desktop processor may not be on a phone with a different architecture. Memory use also depends on connection counts, buffers, routing data, DNS cache, and log volume—not just the protocol. If the client is using more resources, first check whether it's downloading rules, holding many connections open, or producing detailed logs before considering a protocol change.

Why mobile battery use isn't just about encryption

Phones use power for many reasons, including wireless radio wakeups, retransmissions on weak signals, background connections, frequent reconnects, and other app activity. Encryption does use processing power, but it may not be the main factor. A stable connection with fewer wakeups can use less battery than a theoretically leaner setup that keeps retrying. Cellular and Wi-Fi networks also have different power profiles. Don't attribute battery drain directly to Xray or V2Fly when the network and screen brightness also differ.

When Android traffic goes through a VPN interface, the client also reads and forwards packets. Desktop TUN involves a virtual network interface, routing, and DNS handling as well. These change which traffic is captured and how it's processed; they don't upgrade the server protocol. If the system proxy already covers the apps you use, TUN may not improve speed. If an app ignores the system proxy, TUN may extend coverage. For steps, see setting up TUN mode in v2rayN.

Practical limits of Mux, keepalives, and UDP

Multiplexing lets multiple logical requests share fewer underlying connections, which can reduce repeated setup costs for some short-connection workloads. But congestion or packet loss on a shared connection can affect multiple requests. Some protocol and flow-control combinations restrict Mux, so don't enable it by default. Keepalives involve trade-offs, too: sending them too often increases background activity, while sending them too rarely may not preserve idle mappings on some networks. Start with compatible defaults and adjust only after identifying a specific issue.

For real-time apps using UDP, verify the entire path: local traffic handling, core forwarding, server, and destination network. Sending UDP through a proxy doesn't guarantee lower jitter; a longer route or congested link can make things worse. DNS resolution can affect the destination address and routing, so keep it consistent during tests. FakeDNS involves domain mapping and caching behavior; it's not a general speed boost. For details, see the FakeDNS use cases guide.

Change one variable at a time. Record startup, the first request, sustained transfers, and idle behavior, and repeat the observation instead of keeping only the best result. Without controlled tests using the same server setup, describe the outcome as “a difference between these two configurations,” not a protocol ranking. For everyday use, a stable connection, full feature support, and easy recovery usually matter more than small test differences. That's why you should check compatibility before comparing performance.

Choose a protocol and core for your use case

Choose based on your constraints, not a protocol ranking. First identify the device platform, the combination the server actually provides, the apps that need proxy access, and whether they rely on UDP. Then pick a client and core that can fully represent those settings. Finally, compare maintenance requirements and runtime behavior. Without the server's cooperation, users generally can't switch protocols freely; they can only choose among the configurations provided. A protocol dropdown is a configuration input, not a tool for converting the remote server to a different protocol.

Getting started on desktop and Android

v2rayN is the recommended first choice for desktop. On the downloads page, choose a build for your operating system and processor architecture, then check which core the protocol requires. The Windows desktop and classic WPF versions are choices of interface and runtime environment, not different remote protocols. On macOS and Linux, check the system and architecture requirements as well. If your browser is already covered by the system proxy, start without TUN to establish a baseline with fewer variables. Then decide whether you need broader traffic coverage.

On Android, choose v2rayNG based on the server's capabilities, especially when you need Xray features. If the deployment specifically requires the V2Fly path and the configuration is supported, consider v2flyNG. On first launch, grant the system VPN permission and check whether another VPN connection is occupying the same interface. Then check background restrictions and behavior when switching networks. If the app disconnects in the background, don't assume the protocol is at fault; investigate power management, background permissions, and signal changes separately.

Existing services, new deployments, and real-time apps

When connecting to an existing service, the safest approach is to keep its protocol and transport and verify the full import first. If an existing VMess + WebSocket + TLS setup works, there's no need to migrate just to change its name. For Trojan, maintain the certificate, server name, and password. For Shadowsocks, match the method and key format exactly. For VLESS + REALITY, choose an Xray path that supports the full combination and use the server's flow-control and handshake settings. Don't borrow fields from another entry.

For a new deployment, choose based on maintenance requirements: can you manage certificates and server names? Do you need a reverse proxy? Do all target devices support the same security approach? Can the subscription tool output every required setting? A checklist is more useful than optimizing for a theoretical overhead figure. For real-time voice or other UDP apps, verify end-to-end UDP and routing; a webpage loading isn't enough. App-specific regions, routes to destinations, and server location also affect the experience.

Establish a minimal, recoverable baseline

For your first test, use a single server, a clear routing plan, and compatible defaults. First confirm the core starts, then check that requests reach the local port, and finally verify the server handshake and destination access. The JSON below shows only the minimal rule structure of a native configuration's routing object: private addresses go to an outbound named direct. It isn't a complete connection configuration. Before using it, make sure an outbound with that tag exists and check the order of existing rules. If you use a graphical client, configure the equivalent behavior through its routing settings.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

This illustrates another boundary beyond protocols: routing can change whether a request uses a node even when the node itself hasn't changed. Rules are evaluated according to the implementation's matching behavior. A broad rule near the top may match first, preventing a more specific rule later from taking effect. Real setups also depend on the availability of geolocation data files. Don't replace the whole routing object with this example. Understand the existing rules, add a clearly defined condition, and test access to both the local network and the destination network.

When something breaks, roll back based on the evidence

If the core won't start, check configuration generation and port conflicts. If the handshake fails, check identity, security settings, and system time. If the connection is established but the app gets no response, check local traffic handling, DNS, and routing. For local listening conflicts, see the port conflict and listening port guide. Change one setting at a time and keep the last working state. To recover, first disable newly added advanced features instead of re-entering every protocol field.

Record the final choice as one complete combination: client, core, proxy protocol, transport, security layer, traffic handling, and routing plan. This makes it easier to verify each item when changing devices and describe exactly what differs when a problem occurs. The goal isn't to make the protocol name as complicated as possible; it's to match server capabilities, client implementation, and real app requirements. Once you have a baseline, use the performance section to make controlled comparisons. For everyday setup, return to the quick-start guide; for specific questions, continue with Frequently Asked Questions.