V2Ray Protocol Guide

Configuration Layers: Protocol, Transport, and Security

A protocol name isn't a complete connection setup

In a client, “protocol” usually means the proxy protocol: the rules for authentication, destination addressing, and forwarding data. VMess, VLESS, Trojan, and Shadowsocks belong to this layer. They define how the client and server handle a proxy request, but don't determine every networking detail. Two configurations using VLESS can still follow very different connection paths if their transport, security layer, or server entry point differs. The protocol name alone is not enough to judge compatibility or performance.

The transport layer determines how proxy traffic is carried, for example directly over TCP or through WebSocket or gRPC. The transport must match the server entry point; changing WebSocket to TCP won't make the client find a different entry point. Fields such as the path, service name, and request host each serve a purpose. They may look like optional notes, but often affect server-side routing. If your subscription already provides transport settings, leave them unchanged until you have a complete, verified alternative.

The security layer encrypts the connection and authenticates the peer. TLS is a common option; REALITY is a security-layer approach supported by specific cores. REALITY is not a complete proxy protocol that sits alongside VLESS; clients commonly use the two together. Just because an interface puts several options in the same editor doesn't mean they belong to the same technical layer. When reading a configuration, identify the proxy protocol, transport, and security layer separately, then check the authentication details. This is clearer than guessing each field's purpose from its position.

Clients, cores, and traffic routing each have distinct roles

A GUI client lets you edit, save, and import configurations, start a core, and integrate with the operating system. The core handles protocol handshakes, routing rules, and data forwarding. Seeing an option in the interface only means the client knows about that field; it doesn't guarantee that the active core supports it. If an import succeeds but the connection won't start, check the saved configuration, selected core, and the feature actually invoked in the logs. A successful import does not mean a successful connection.

System proxy, TUN, and Android VPN mode control how traffic is routed through the client; they are not remote protocols. A system proxy usually affects only apps that follow the system proxy settings. TUN can capture more traffic, but also involves permissions, routes, and DNS. An Android VPN status means the system authorized a local virtual network interface; it says nothing about which protocol is used remotely. Changing traffic routing may fix an app that bypasses the proxy, but won't fix an incorrect user ID or server port.

Troubleshoot one layer at a time

A connection typically involves several steps: local traffic routing, address resolution, establishing the transport connection, the security handshake, and proxy authentication. A “connection timed out” message and an “authentication failed” message point to different stages. The latter usually means the request reached a system capable of responding. First identify where the process stops, then change settings relevant to that layer. If you change DNS, protocol, and routing all at once, even a successful connection won't tell you what fixed the issue—and the problem may return after the next subscription update.

Follow the same order when choosing a protocol: check which complete combinations the server offers, which combinations your local core supports, and then compare device overhead and app requirements. A client is not a protocol converter; changing a dropdown can't turn an existing account into a different service. Keep a copy of the working configuration and test changes in a separate entry so you don't overwrite the subscription version. For routing rules, see the hands-on guide to routing rules.

VMess and VLESS: Authentication and Encryption Trade-offs

VMess: background and existing configurations

VMess is an important early proxy protocol in the Project V ecosystem. Its design combines user authentication, request details, and data protection. Because it has been widely used, many existing services and subscriptions still offer VMess. It makes sense to use VMess when your existing service fully supports it, the configuration comes from a trusted source, and your current client can run it correctly—not because the name includes a particular project label. If a configuration is already working reliably, there's no need to migrate just to change the protocol name.

VMess configurations have used different handshakes and security options over time. For modern deployments, check support for AEAD; don't copy parameters from old tutorials into a new configuration. Older shared links may include extra ID fields or names for different security algorithms. A client might still parse them for compatibility, but you need to verify whether the core accepts them. If an old subscription imports but won't start, ask for the current format and check the logs for details about the fields. Don't keep trying arbitrary values and expect the client to fill in what the server requires.

System time is another important VMess troubleshooting factor. Authentication depends on time, so a substantial device clock error can cause a connection to fail even when the user ID and port are correct. Let the operating system synchronize the date and time, and distinguish an incorrect clock from a different displayed time zone. A different time zone display doesn't necessarily cause authentication errors; changing time zones without checking the system clock usually won't help. If the security layer also uses TLS, certificate validity checks depend on the time as well.

What VLESS leaves out

VLESS focuses on streamlined authentication and request framing. Unlike VMess, it doesn't provide data encryption at the protocol layer. It is often paired with TLS or REALITY, which provide connection protection at the outer layer. Seeing “encryption: none” in a client doesn't automatically mean the combination is unencrypted; check whether a security layer is enabled. Conversely, without a suitable security layer, a newer protocol name doesn't mean authentication details and traffic are fully protected.

VLESS commonly uses a UUID as the user ID, but a similar-looking identifier does not make it interchangeable with a VMess account. The server's protocol, user configuration, and transport entry point must all match. Some setups also include a flow field to specify a particular processing mode, such as a compatible Vision configuration. This isn't a general-purpose speed boost and shouldn't be added to any VLESS node at random. It only applies when the server, transport, and security layer all support it.

How to compare them without drawing the wrong conclusion

VLESS avoids some encryption work at its own protocol layer, which may reduce processing overhead in certain setups. But a real connection also involves security handshakes, network round trips, server queues, and app requests—factors that often matter more than differences in protocol headers. Testing two entry points in different regions or from different providers measures the entire path, not the protocol difference alone. That's why there's no universal speed ranking for VMess and VLESS.

When comparing them in a client, start with complete configurations explicitly provided by the server. If both protocols are available, keep the destination service, transport path, and test app as consistent as possible. Compare initial loads, sustained transfers, and recovery after brief idle periods. Don't rely only on a one-off client connectivity check: it may not cover real web requests or reproduce an app's DNS and connection reuse behavior. Test whether everyday tasks improve, not just one isolated metric.

For desktop users managing many existing configurations, compatibility and traceability often matter more than migrating. For a new connection, consider a VLESS security setup supported by your current core, then check network switching, UDP apps, and routing needs. If only VMess is available, use a modern configuration supported by your client and keep the system clock synchronized. Either choice must match the actual deployment; a client cannot change what the server supports.

Trojan and Shadowsocks: Deployment and Configuration Limits

TLS is central to Trojan

Trojan uses TLS to protect the connection between client and server, then handles proxy authentication and forwarding within that connection. Unlike protocols that use a UUID, Trojan clients commonly use a password field. The password is only part of authentication: the server address, port, certificate verification name, and transport settings must also match. Trojan can fit deployments with a compatible TLS server and an existing certificate management setup, but that doesn't justify skipping certificate verification or assuming a password alone makes the connection trustworthy.

When connecting by domain name, the client usually sends a server name and verifies the certificate. The entry-point address and certificate name may match, or differ depending on the server deployment; don't assume one can replace the other. If the server provides a separate server name field, use the value from the original configuration. If it doesn't, don't borrow a domain from another node. On connection failure, check the system time, domain spelling, and certificate validity first. See the guide to TLS handshake and certificate errors.

Different Trojan transport combinations and extended implementations aren't interchangeable formats. A client recognizing the Trojan type doesn't mean it can run every extension based on it. After importing a share link, check that the transport, security layer, and extra fields were all preserved. If the current core doesn't support a feature required by the server, changing the password won't help. Use a compatible complete entry point or a client and core that explicitly support the combination.

Shadowsocks: simplicity and matching the method

Shadowsocks, often shortened to SS, uses a pre-shared secret and a specified cipher method for proxy traffic. Its configuration is usually compact, with server, port, password, and method as the core fields. Early designs differ from modern AEAD methods in security properties and compatibility requirements, so the label “SS” alone doesn't make configurations equivalent. For a new setup, choose a modern method supported by both the server and core. Don't fall back to an outdated method just to follow an old tutorial.

The method name must match exactly, and the password's encoding requirements must fit the method. Some modern methods require key material of a specific length; an arbitrary short password won't work. A share link may encode the method and password together or put them in separate fields, so don't guess the password by cutting text out of the link. Let the client parse the full link, then check the fields against the provider's instructions. If parsing fails, identify the link format first rather than deleting unfamiliar characters one by one.

Methods such as Shadowsocks 2022 have more specific compatibility requirements. “The core supports Shadowsocks” doesn't mean it supports every method. Some setups also depend on transport extensions or external components, and our three clients don't guarantee the same integrations on every platform. Choose an entry point the current client can run directly. If extra components are required, check the client documentation and server requirements first; don't assume a configuration file from another software ecosystem can be imported as a subscription.

Factor in UDP and maintenance

UDP support for Trojan and Shadowsocks depends on the protocol implementation, the client's traffic-routing mode, server settings, and network path. Opening a regular webpage only proves that some TCP requests work; it doesn't prove that calls, games, or other datagram-based apps will work. System proxy settings may not route traffic from those apps either. First check whether the app's traffic reaches the client, then look for the relevant forwarding in the logs. Otherwise, you may mistake a traffic-routing limitation for an inherent protocol limitation.

From a maintenance perspective, Trojan calls for checking TLS certificates and name matching, while Shadowsocks requires particular attention to the method and secret material. Each has distinct troubleshooting priorities. If the server already provides one option reliably and it works on all target devices, simplifying the setup and preserving its source is often more useful than switching protocols frequently. The goal is to meet authentication, compatibility, and app requirements—not to enable every type in the list or judge quality by how new a name sounds.

TLS and REALITY: Checking Security Layer Settings

TLS depends on verifying the connection endpoint

TLS does more than encrypt traffic: certificate and name checks help the client confirm the connection endpoint. The server certificate must be within its validity period, the certificate chain must be trusted by the device, and the verification name must match the certificate's coverage. A failed secure connection can result from any of these issues. Blaming every certificate error on “protocol incompatibility” can hide simpler causes such as an incorrect device clock, a mistyped entry point, or an incomplete certificate update on the server.

SNI is the server name sent during the handshake, often used by the server to select a certificate and entry point. The name the client uses for certificate verification is determined by the implementation and configuration. They are often the same, but serve different purposes. Replacing either with the domain of a public website that opens successfully won't give your service a matching certificate. If the address is an IP and the configuration provides a separate server name, keep those roles separate; don't copy the IP into every name field.

ALPN negotiates an application-layer protocol, while fingerprint settings affect the client's handshake characteristics. Neither is a password or a performance preset to rotate at will. If the server or an intermediate entry point requires specific values, the wrong combination can leave the connection unusable even after the handshake succeeds. Keep the original shared configuration unless you know what the deployment supports. When similarly named fields behave differently, check how the current client maps them rather than guessing from the label.

REALITY requires a complete set of matching parameters

REALITY is commonly used with VLESS in the Xray ecosystem. It changes how the security handshake and server authentication are organized; it isn't a standalone account type. The client uses the relevant public verification material and connection parameters. The server's private material must not be included in a client subscription. This distinction helps when checking shared configurations: the client needs to verify the server, not possess all of its secrets or import the server's entire configuration file.

Common fields include the server name, public verification material, short ID, and client fingerprint; some combinations also require a matching flow. Field names can change as clients and cores evolve, so map the current interface fields to the shared configuration rather than hunting for labels from an old screenshot. The public verification material and short ID must come from the same service configuration; don't combine values from two otherwise working nodes. Fields that all look like strings may have completely different formats and purposes.

REALITY doesn't remove the need for correct system time, network reachability, or transport settings. The client still needs to reach the right address and port, and the security handshake must meet the implementation's requirements. If a setup stops working after an update, first confirm that the active core supports the combination, then check whether subscription parsing dropped parameters, and finally verify whether the server configuration changed too. Switching the security layer to ordinary TLS usually won't help: the server isn't required to accept a different handshake on the same entry point.

Encryption boundaries and application security

The proxy's security layer protects the connection between the client and proxy server; it doesn't replace HTTPS or other end-to-end protection in the app itself. How data is handled after it reaches the server depends on the destination protocol and server behavior. A TLS label on the proxy entry doesn't mean you can ignore a browser certificate warning, and a successful core connection doesn't guarantee that all app traffic has the same security protections. When choosing a setup, understand where each layer starts and ends, and which endpoint it trusts.

To choose between standard TLS and REALITY, start with the complete server setup and device support, then consider maintenance needs. A deployment with managed certificates can continue using a compatible TLS entry; services designed for REALITY need all their parameters intact. Neither is an “upgrade” you can make with a single toggle. If devices share a subscription, confirm that each device's parser and core preserve the required fields. Otherwise, provide separate entry points for different compatibility groups.

Xray and V2Fly: Core Families and Configuration Compatibility

A shared history doesn't mean identical features

Project V provides useful context for the V2Ray ecosystem. V2Fly continues the development of V2Ray-related cores, while Xray has evolved from related code along its own independent path. They share many concepts, such as inbounds, outbounds, routing, and DNS, but feature sets, field semantics, and defaults are not guaranteed to stay the same. It's more accurate—and useful for assessing migration risk—to think of them as two implementations with shared background, not two names for the same program.

Support must be checked for the specific protocol, security layer, transport, and extended processing flow. Don't assume that REALITY or Vision features from the Xray ecosystem will work after switching to V2Fly; likewise, a feature added in V2Fly isn't guaranteed to behave the same in Xray just because the field names look alike. Both cores recognizing a top-level protocol is only the first compatibility check. Confirm actual support in the active core's documentation, the client's integration, and startup logs.

Cores can also differ in domain strategies, DNS handling, connection reuse, and routing-rule details. After migration, a remote connection might work while local traffic is routed differently than intended. An ignored field may not trigger an error but can still change DNS resolution or outbound selection. For complex, long-running configurations, treat “starts successfully,” “reaches the destination,” and “follows the intended rules” as three separate validation steps. Verify each before replacing the configuration you use every day.

Choosing among the three clients

v2rayN is our recommended desktop client and supports Windows, macOS, and Linux. It offers graphical management, but system features may vary by platform, distribution, and bundled version. If the client lets you choose a core, first check what your configuration requires and select a compatible option; don't switch just to display another core name in a menu. Whether the desktop interface can edit a field and whether the installed core files support it are separate questions.

For Android, v2rayNG is the primary choice, with a focus on Xray core capabilities; v2flyNG is an alternative for the V2Fly route. Similar names don't mean advanced settings or native configurations are interchangeable. If your server uses a specific Xray extension, check current v2rayNG support first. Consider v2flyNG when your configuration explicitly depends on V2Fly behavior. Don't let both clients route traffic through VPN mode at the same time while comparing protocols, or your test traffic may take a different path.

Checks before switching

Shared JSON syntax doesn't mean shared configuration semantics. Before giving a native configuration to a different core, check that it recognizes the protocol names, transport fields, security settings, routing references, and resource files. The simple rule object below can go in the appropriate routing rule list to send private address ranges to an outbound named direct. It isn't a complete configuration: the outbound must already be defined, and a usable GeoIP resource must be available.

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

Even this small object depends on its context: the outbound tag must exist, the rules file must be readable, and an earlier rule must not already match the same traffic. When migrating a complex configuration, start with a copy that retains the minimum working outbound, then add DNS, rules, and connection reuse options step by step. If startup fails, check the logs for unsupported fields, missing references, or a local port conflict. See the v2rayN core startup troubleshooting guide, and don't rewrite every parameter at once.

Connection Performance, Resource Use, and Mobile Battery Life

Compare connection setup and sustained transfers separately

“Fast” can mean a page opens quickly or a large file transfers quickly; different factors drive each. A first visit involves DNS, establishing the underlying connection, a security handshake, proxy authentication, and the destination's response. Sustained transfers depend more on link capacity, congestion, packet loss, server load, and device performance. Protocol overhead matters, but can't be assessed in isolation. An entry point with a smooth initial handshake may still fluctuate under sustained load.

Transport also affects performance. An extra encapsulation layer may add processing steps, but it can be necessary for the available server entry point. Connection reuse can reduce repeated handshakes, but sharing one underlying connection across multiple tasks can also make them affect one another. Some apps are more sensitive to brief packet loss, queueing, and recovery, so average throughput alone isn't enough to decide whether to enable reuse. Unless the server requires or explicitly supports it, don't treat Mux as an optimization that should always be enabled.

Control your test conditions. Keep the device, network, destination content, and time of day as consistent as possible. Test cold starts, repeated visits, recovery after idle periods, and network switching separately. A client connectivity check is useful but doesn't replace testing in the app; its request may use a particular destination or bypass the same routing path. If two candidate entry points differ in location and resources, record the results as a comparison of those entry points—not a general ranking of protocols.

CPU and memory use aren't determined by encryption alone

Encryption and decryption use processor resources. Actual overhead also depends on hardware acceleration, core implementation, and packet size. A newer protocol or algorithm isn't necessarily more efficient on every device, and a simpler protocol can lose its advantage to an additional transport layer. On low-power devices, check sustained CPU use, heat, and app responsiveness during real tasks instead of applying results from a different hardware architecture.

Memory use also depends on concurrent connections, buffers, DNS cache, rule-set size, and log volume. Keeping verbose debug logs enabled for long periods increases storage writes and processing work; switch back to an appropriate log level for everyday use. Large-scale speed tests or automatic checks may continually open connections in the background, skewing your comparison. Before measuring resource use, stop unnecessary tests and keep the rules and traffic-routing mode similar across configurations. Otherwise, the differences are hard to interpret.

On mobile, check wakeups and reconnects first

On Android, battery use is often affected by wireless network conditions. Frequent small requests, overly aggressive keepalives, retransmissions on poor networks, and repeated retries after failed connections can keep the radio active for longer. These behaviors increase power use even if the protocol itself has low processing overhead. If standby drain seems unusually high, first check the logs for repeated reconnects, then see whether background apps are making constant requests. Consider changing the protocol combination only after that.

VPN mode routes more traffic through local processing, so a larger client share in battery statistics doesn't necessarily mean the client caused all the extra drain; the system may attribute some forwarding work to it. Per-app proxying can limit the scope, but make sure the apps that need the proxy are included and understand the difference between allow and exclude lists. If battery optimization repeatedly kills background connections, the resulting recovery and reconnects can disrupt use and distort power measurements.

In practice, prioritize reliable recovery over peak performance. If you often switch between Wi-Fi and mobile data, check whether the connection comes back properly and whether calls, messages, and background tasks are affected. A connection dropping during a network switch isn't automatically a protocol defect; what matters is whether the client and apps recover promptly. Keep the combination that reliably handles everyday tasks, then use repeatable tests to decide whether changing transport, reuse, or security settings is worthwhile.

Subscriptions and Share Formats: Importing Doesn't Guarantee a Working Connection

Share links, subscriptions, and native JSON

A share link usually describes one connection, including its protocol, address, authentication details, and transport settings. A subscription is an endpoint the client checks for a list of configurations; its response might contain plain-text share links, Base64-encoded content, or structured data. Native JSON usually describes a core's runtime configuration and may include local inbounds, multiple outbounds, DNS, and routing. These formats serve different purposes. The fact that all three can be copied as text doesn't make them interchangeable in the same import field.

Base64 is an encoding, not encryption, and it doesn't determine which protocol the encoded content uses. An encoded subscription might contain several share links, and part of an individual link may also be encoded. Identify a format from its decoded structure and the client's requirements, not from its ending characters. Subscription URLs and share content often include credentials for a working service. Treat them like account details; don't submit them to an unfamiliar online tool just to identify the format.

Native JSON and configurations generated by a GUI client can also differ in what they manage. Importing native configuration may tell the core to run a complete set of rules rather than simply add one server to a list. It could change local listeners, logging, or routing behavior. Before importing, find out whether the client uses the file as a complete configuration or extracts only selected fields. Don't replace a working local setup with a complete configuration from elsewhere unless you understand what it does.

The parser and core are two separate compatibility checks

Subscription import first goes through the client parser. The parser needs to understand the share format and convert its parameters into an internal record; the client then generates a configuration the core can run. Import compatibility and runtime compatibility are two separate hurdles. The parser may accept a link but drop a new field it doesn't recognize. A core may support a feature that the current interface can't fully configure. Seeing an entry in the list is only an intermediate result; check it in the editor and verify that it actually starts.

Some settings have different names or encodings across clients, including server names, transport service names, fingerprints, and security-layer options. These fields are particularly prone to being lost or changing meaning when you export from one client and import into another. Compare them by purpose; the labels don't have to match exactly, but the values must not have become blank or reverted to defaults. If a connection works in the original client but fails after export and import, compare these advanced settings first. Don't immediately request a new account or change the server.

Subscription conversion means parsing the source format and rebuilding the content in a target format. If the target has no equivalent field, the converted result may not preserve the original meaning. Even if it imports successfully, important settings may be missing. For connections using a specific security layer or processing flow, prefer a format provided directly for your client. See a comparison of Base64 subscriptions, native JSON, and share links for details. Conversion can't add features to a core.

Managing subscription updates alongside manual edits

Subscriptions centralize connection updates, but that also means the list may be rebuilt. Clients differ in how they handle duplicates, notes, and manual changes, so don't assume local edits will last. Before experimenting with protocols, keep the original entry in its subscription group and put a test copy in a separate manual group. Add a note describing each change. This lets you keep receiving updates from the source and see whether your test configuration still matches the current entry point.

When an update fails, distinguish between “no response received” and “content received but not parsed.” The first may involve the subscription URL, connection method, or DNS; the second is more likely to mean the server returned a webpage, account notice, or unsupported format. Don't convert an error response as if it were a subscription, and don't share a complete URL containing credentials. For managing multiple sources, see practical tips for subscription groups and filtering. For basic issues, browse the installation, configuration, and troubleshooting sections in FAQs.

Choosing a Setup: From Supported Combinations to Reliable Configurations

Check compatibility before comparing performance

Start by listing the complete combinations your server actually offers; don't begin by picking a favorite protocol name. Each option should include at least the proxy protocol, transport, security layer, and any required extensions. Then check that your client and core can represent the entire combination. Eliminate options with missing fields, unsupported implementations, or unclear dependencies before testing the rest. This avoids wasting time on client-side toggles that need server support and reduces confusion when configuring multiple devices.

For everyday browsing and work on a desktop, start with v2rayN and keep the security settings provided by your subscription. If your apps follow the system proxy, test with that first; consider TUN only if some apps ignore the proxy settings. Don't change the protocol, DNS, and routing all at once just to capture more traffic. Once connected, test your usual websites, file transfers, and work apps, including after waking from sleep. Reliable everyday use is more meaningful than a single connectivity check.

For everyday Android use, start with v2rayNG. Check VPN permissions, per-app routing, background operation, and recovery after network changes—not just the protocol label. If a configuration explicitly depends on V2Fly behavior, test it separately with v2flyNG. Avoid switching between clients while both may route traffic, as that can make results hard to interpret. During testing, leave only one client routing traffic and record the configuration source and core family used each time.

Let your use case determine what to test

For calls, games, and other real-time apps, focus on UDP forwarding, traffic routing, and connection stability. If ordinary webpages work but real-time apps fail, first check whether their traffic reaches the client, then confirm that the server allows the required forwarding and that the network path supports it. A working TCP entry point doesn't prove that every datagram-based app will work. Different transport combinations may carry this traffic differently; verify that the app's requirements are met rather than relying on the protocol name.

When multiple devices share a subscription, prioritize a complete feature set they all support. If a desktop can run an extension but a mobile parser doesn't preserve its parameters, put it in a desktop-only group and keep a compatible entry for mobile devices. Don't force identical-looking lists by copying configurations that aren't equivalent. For a setup that needs long-term maintenance, clear groups, source records, and an update process are part of choosing a protocol—and can significantly reduce future troubleshooting.

On resource-constrained devices, start with less additional processing: keep only necessary routing rules, use an appropriate log level, set a clear traffic-routing scope, and pause unnecessary background checks. If resource use remains high, compare protocol and transport combinations. Don't disable authentication or security just because the device is older, and don't treat weaker security as a performance optimization. Keep a change only if repeatable tests show an improvement for the same tasks without compromising app requirements or verification of the connection endpoint.

Keep a rollback option and a record of minimal changes

Optimize a copy of the configuration, changing one category of settings at a time and stating what you expect to improve. To compare a connection reuse setting, keep the protocol, entry point, routing, and test app the same. To troubleshoot a security handshake, don't also replace DNS rules. If performance gets worse, you should be able to return immediately to the last working setup. For troubleshooting, check logs in this order: local traffic routing, name resolution, underlying connection, security handshake, proxy authentication, and destination access. That keeps you from repeatedly changing settings at the wrong layer.

You don't need to use every protocol or give every device the same advanced features. A setup is right for the current use case only when the server supports it, the client can represent it fully, the core can run it correctly, and the apps work reliably. For a first connection, start with the quick-start guide. Choose an installer on the downloads page. For persistent issues, narrow them down by category in FAQs. This protocol guide explains the trade-offs; it doesn't replace testing in your own environment.