V2Ray Protocols and
Core Technologies

01 / CONFIGURATION LAYERS

Protocols, transports, and security layers

A node name is not a complete configuration

Each node in a client is a set of parameters that work together, not just a protocol name. The protocol defines how authentication and proxy requests are represented; the transport carries that data to the server; and the security layer handles connection authentication and protection. The address, port, and user ID are connection requirements, while the path, request headers, and server name may belong to different layers. Start by reviewing the full configuration, not by judging speed or compatibility from an abbreviation. The server determines which combinations are available, and the client can only reproduce them accurately if it supports them.

Take VLESS as an example: the same protocol can use different transport and security settings. A configuration using plain TCP cannot be switched to WebSocket and expected to work; the server must also be set up to listen for it and handle the path. TLS is not a switch you can turn on for any node: the server must support the handshake, the certificate name must match, and the client must trust the issuing chain. Even with the same protocol, changing other fields can completely change how the connection works.

Keep the address, server name, and request target separate

The server address tells the client which host to connect to. It can be a domain name or an IP address. The TLS server name is usually sent as SNI and used to verify the certificate name; the WebSocket Host is an application-layer request header. These values may match, or the deployment may specify different ones. Don’t copy them between fields just because they all look like domain names. Troubleshoot in order: check address resolution, confirm the port is reachable, then check the handshake and authentication, and only then test access to the destination site. This helps avoid mistaking a DNS issue for a protocol problem.

Ingress mode and outbound protocol are separate things

A system proxy provides a local proxy endpoint to the operating system or apps. Only programs configured to use that endpoint will send traffic through it. TUN captures traffic through a virtual network interface and usually covers more apps, but still depends on routing, permissions, and exclusions. Neither mode changes the remote protocol. If a node imports successfully but some apps cannot connect, first check whether their traffic actually reaches the client, then review outbound logs. Switching from VLESS to VMess will not fix an app that bypasses the system proxy.

Routing and DNS are two separate layers. Routing selects an outbound for traffic, such as direct, proxied, or blocked. DNS handles name resolution and related policies. A site going direct does not mean node authentication failed; a domain failing to resolve does not by itself indicate a TLS problem. When reporting an issue, include the client, core, protocol, transport, security layer, and ingress mode. Before sharing logs, remove subscription URLs, user IDs, and authentication fields. The error category and sequence of events are usually enough.

A successful import usually means the text was parsed and added to the list, not that the server accepted a connection. Verification should cover at least three steps: starting the core, establishing a session, and accessing a destination. See the v2rayN setup guide for the full workflow; the following sections explain the limits and trade-offs of each layer.

02 / VMESS & VLESS

VMess and VLESS: design trade-offs

VMess: authentication and encryption built into the protocol

VMess is an earlier proxy protocol in the Project V ecosystem. Its design includes user authentication, request protection, and data encryption within the protocol itself. The client needs the correct user ID and security settings to match the server. Modern configurations typically use AEAD-based authentication. Extra ID fields found in older guides are part of legacy compatibility; don’t follow outdated instructions by entering arbitrary values. Match the server’s configuration, and prefer modern settings explicitly provided by the maintainer.

Built-in protocol protection does not make outer TLS irrelevant. The outer connection and the proxy protocol address different concerns, and a deployment may also use WebSocket or another transport. Evaluate the entire connection chain: local ingress, protocol encapsulation, outer transport, and remote outbound all use resources. You can’t estimate overhead from the protocol name alone, and an extra layer of encryption doesn’t automatically mean noticeably slower everyday use.

VLESS: less responsibility for data encryption in the protocol

VLESS simplifies the proxy protocol and leaves more of the data security to its accompanying security layer. In common client configurations, the encryption field is none. This means VLESS itself does not provide that data encryption; it does not mean the entire connection is unprotected. To assess security, check whether TLS or REALITY is correctly enabled, whether the server’s identity is verified, and where the trust boundaries lie locally and remotely. Changing this field to an encryption method from another protocol will usually make the configuration invalid.

Flow control and security features often appear together in the VLESS and Xray ecosystem, but they are not default features of every VLESS implementation. For example, Vision flow control requires a compatible core and connection setup. A share link containing only basic VLESS fields does not automatically include it. If the server does not require flow control, don’t add it manually in pursuit of a supposed performance boost. More parameters are not necessarily better; accurately reproducing the server’s configuration comes first.

Time, user IDs, and migration limits

VMess depends on accurate system time; a significant clock offset can interfere with authentication. Check the device’s date, time, and automatic synchronization instead of repeatedly generating user IDs. VLESS is not a fix for every time-related issue, since system time also affects outer certificate validation. Both protocols may use UUIDs for user IDs, but the same ID format does not make them interchangeable. Changing a dropdown in the client does not change the server.

Migrating an existing VMess setup to VLESS requires a new server entry or clear change instructions. Confirm the transport, security layer, and flow control requirements as well. Keep the working configuration, test the new entry in a separate group, and switch only after confirming that your target apps and UDP use cases work. Don’t overwrite multiple fields on your only working node; if it fails, you won’t know which change caused the problem. For a side-by-side look at authentication and protection, read VMess vs. VLESS: the differences.

After importing, check the protocol, user ID, address, port, transport, security layer, and flow control individually—not just the node label. Labels are set by whoever shared the node and have no technical significance. For a configuration parsing error, check the fields and core compatibility first. For an authentication failure, check the server account and parameters. Only compare throughput and latency after the connection is stable.

03 / TROJAN & SHADOWSOCKS

Trojan and Shadowsocks: configuration limits

Trojan: TLS as a common connection foundation

Trojan combines password authentication with a TLS connection. Common client fields include the address, port, password, and server name. Its authentication format differs from protocols that use UUIDs, but the client and server still need matching configurations. A correct password does not guarantee a connection: certificate names, the issuing chain, system time, or the outer transport can cause the connection to fail before authentication. First determine whether the failure occurs during the TLS handshake or protocol authentication.

On a trusted network with proper verification, TLS encrypts the connection and verifies the server’s identity. Don’t treat skipping certificate verification as the default for Trojan, or dismiss an unknown-certificate error as a client limitation. The certificate domain and the address used to connect to the server may differ, but the server name must follow the deployment requirements. When connecting to an IP address, check the name field carefully; don’t expect the client to guess the domain on the certificate.

Shadowsocks: the encryption method is part of compatibility

Shadowsocks often appears as SS in clients. Its main parameters are the server, port, password, and encryption method. The design focuses on a relatively simple encrypted proxy channel, but “supports SS” is not a complete compatibility statement. Legacy AEAD methods and later extensions may differ in key requirements, implementation support, and link parsing. Match the method name exactly; don’t replace it just because another option in the client looks newer.

A password field does not always take an ordinary short password. Some methods require a key with a specific length and encoding. Removing a trailing character, changing letter case, or decoding it a second time can invalidate authentication. Keep the entire content when copying a share link; if entering it manually, follow the server’s instructions. Don’t put another protocol’s UUID in the SS password field and expect it to convert automatically, or assume that an encoded authentication string in a link is the final password.

Don’t overlook plugins, UDP, and transport extensions

Some SS share links also include plugin parameters. A graphical client recognizing the link does not mean the required plugin is installed, and the core may not implement the same feature natively. Refer to the download page for the client support list. If a service requires a plugin, first check whether it offers an alternative supported by your current client. Don’t mistake a missing-plugin error for a wrong password, and don’t install extra components based on instructions from an unknown source; confirm the connection method with the service maintainer first.

UDP support depends on the protocol implementation, server forwarding, client ingress mode, and target app. A working web page does not prove that voice or real-time communication will work; those apps may use different traffic types. A system proxy usually cannot capture UDP traffic from every program automatically, and TUN cannot add capabilities the server does not provide. When comparing Trojan and SS, test them on the same network with the same tasks instead of treating one page load as a full compatibility test.

For an existing service that provides standard Trojan or SS parameters, use a client configuration that represents them fully. There’s no need to add transport options that the service doesn’t require. On desktop, create a separate test entry in v2rayN; on Android, check the encryption method and security options in v2rayNG. If you use v2flyNG, also verify that its included core supports the method and extensions. A matching protocol name in the interface is not proof that the configuration works.

Neither protocol inherently corresponds to a fixed speed tier. Server load, network path, encryption implementation, and connection reuse often explain performance better than the protocol name. Choose a configuration that meets authentication, feature, and maintenance requirements first, then compare resource use under real workloads. If a node won’t work after import, check the installation, configuration, and Troubleshooting sections in the Help Center.

04 / TLS & REALITY

TLS, REALITY, and Vision flow control

REALITY is not a node protocol on the same level as VLESS

Clients often list VLESS, REALITY, and Vision together in a node description, which can make them look like the same kind of setting. In practice, VLESS is a proxy protocol, REALITY is a security mechanism in the Xray ecosystem, and Vision is flow control used with specific connection setups. They work together but have different roles. Choosing REALITY does not remove the need for protocol authentication, and Vision does not replace the security layer. Set each field to match the combination provided by the server.

Standard TLS typically relies on a certificate, its name, and the issuing chain to establish trust. The client uses these details to verify the remote server, and system time affects certificate validity checks. REALITY uses a different authentication and handshake mechanism, with associated parameters such as a public key, short ID, and server name. The fields are not interchangeable: a standard TLS certificate cannot replace a REALITY public key, and adding a short ID does not turn a standard TLS node into a REALITY node.

Check the public key, short ID, and fingerprint separately

The REALITY public key must come from the client configuration provided by the service maintainer. Don’t use a randomly generated value or enter the server’s private key in the client. The short ID must also match a value allowed by the server. First check that the values were copied in full, without extra spaces or line breaks, then confirm that the current core supports the field format. Field names and parsing may change between core versions, so consult the documentation for the core in use and the client’s exported configuration rather than blindly copying an old snippet.

Use a server name explicitly allowed by the service, not an arbitrary popular website domain. The fingerprint setting affects the client’s handshake characteristics and is required in some security combinations, but it is not a speed setting. Changing it won’t fix an unreachable address, mismatched key, or authentication error. If the server provides a recommended value, keep it. To test compatibility, change one setting at a time and note the failure stage in the core logs.

Vision requires a compatible connection setup

xtls-rprx-vision is a common flow-control identifier, not a general-purpose optimization switch for any transport. The server must configure the corresponding user flow control, and the client core must support that combination. Changing a transport configuration that requires a specific path to TCP, or adding Vision to an existing WebSocket configuration, can make the setup incompatible. For a flow-control error, verify the complete configuration first; don’t cycle through every security option and hope one works.

If a service offers both standard TLS and REALITY endpoints, create separate nodes and test each with its own authentication and transport settings. Choose based on client support, service maintenance, certificate management, and real-world network performance—not because one is a universal replacement for the other. You don’t need to memorize handshake details, but you do need to know which parameters must stay together and which errors can’t be fixed by skipping verification.

When logs show a handshake failure, distinguish a name mismatch, an untrusted certificate, a closed connection, and an authentication mismatch. Confirm that the client is connecting to the expected address and port, then check the security settings. Repeatedly changing routing rules usually won’t fix the handshake itself. For a more detailed checklist, see troubleshooting TLS handshake failures, including common pitfalls with system time and server names.

When asking for help, say whether REALITY and Vision are enabled, which client and core you use, and where the error occurs. Don’t share a full link, secret fields beyond the public key, or server configuration. There’s no need to publish every non-secret parameter either; enough technical context to locate the issue is more useful than pasting the entire configuration.

05 / PERFORMANCE & BATTERY

Connection speed, resource use, and mobile battery life

Measure connection setup and sustained transfers separately

“Fast” might mean a short wait before a page opens or high throughput during a large download. Different factors affect each. Setting up a connection involves name resolution, network connection, a security handshake, and proxy authentication. Sustained transfers depend more on available bandwidth, congestion, server forwarding, and processing capacity. A protocol that reduces some encapsulation does not guarantee a faster first response over a long-distance network; a single large download also says little about interactive app performance.

When comparing protocols, keep the server location, network ingress, test target, and connection mode as consistent as possible. Differences between servers often matter more than differences between protocols. Don’t change the protocol, DNS, routing, and transport at the same time and then blame one of them. Use the same app for several short requests and sustained transfers, check whether the results are repeatable, then review logs and system resources. A client’s connection test can help with initial checks, but its test destination may not follow the same path as your actual traffic.

Encapsulation, connection reuse, and device capabilities all affect overhead

Encryption uses CPU resources, but its cost on modern devices depends on the algorithm implementation and hardware. There’s no fixed performance ranking for VMess, VLESS, Trojan, and SS. Outer transport, connection count, logging level, and traffic copying also affect resource use. Extra transport encapsulation may be worthwhile for deployment or compatibility. Meet the service requirements first, then decide whether the overhead is a noticeable bottleneck on your device.

Connection reuse can reduce the cost of setting up connections repeatedly, but it can also affect how concurrent traffic interacts. Enable it only if the server and core support it, and test it with your actual apps. Putting all traffic into fewer connections doesn’t make every use case smoother. Frequent short requests differ from long, high-volume transfers. If you see jitter, check for congestion on shared connections before blaming the protocol.

On Android, start with wakeups and traffic scope when checking battery use

Mobile battery use isn’t just about encryption. Frequent wireless wakeups, ongoing background requests, reconnects after network changes, and overly frequent connection checks can all increase drain. When VPN ingress covers more apps, the system may attribute more network activity to the proxy client, so its share of battery use is not a direct measure of protocol processing costs. Compare the same usage period, similar network conditions, and the same background apps before deciding whether drain is abnormal.

v2rayNG per-app proxying can limit which apps use the connection, but first check whether the list is an allowlist or a bypass list, and whether you need to reconnect after saving. Distinguish system battery optimization from manufacturer background restrictions. Settings that are too strict can kill the process, leading to repeated restarts or dropped connections; disabling all restrictions may let background tasks run continuously when they shouldn’t. The goal is reliable operation for the apps you need, not removing every limit for every app.

TUN mode also involves a virtual interface, routing, and DNS interception, so its battery impact is not simply additive compared with a system proxy. If an app supports proxy settings, a system proxy may be enough. If you need to capture traffic from apps that ignore proxy settings, the extra work of TUN may be necessary. When comparing desktop setups, check whether other virtual networking software is running, so routing conflicts or duplicate traffic processing aren’t mistaken for a core performance issue.

Restore the normal logging level after testing to avoid continuously recording large amounts of connection data. Judge performance by whether tasks complete reliably, not by a one-time peak. If only one domain is noticeably slow, check DNS, routing rules, and the remote network path. If all apps are affected, check local load, network quality, and server status. Protocol choice is one part of optimization, not a universal explanation for every bottleneck.

06 / CORE COMPATIBILITY

How V2Fly, Xray, and clients fit together

The GUI manages settings; the core runs the connection

Project V provides context for the V2Ray ecosystem. V2Fly and Xray are core families that have evolved along related paths. Graphical clients manage nodes, edit settings, start processes, and handle system ingress. v2rayN, v2rayNG, and v2flyNG are not protocols; the core called by the client actually handles the connection. A field in the interface only shows that the client can represent that parameter—it does not prove the current core can run it.

Xray has added capabilities such as REALITY and Vision over its development. V2Fly has its own maintenance roadmap and configuration extensions. The two share some history and concepts, but their field names are not always identical. Supported features, defaults, and transport implementations can vary between core versions. For a specific feature, check the documentation for the core you’re using; don’t treat one branch’s parameter list as a permanent compatibility guide for the other.

Each client has a distinct role

For desktop, start with v2rayN. Install it on Windows, macOS, or Linux using the architecture and package listed on the download page. Menu locations may differ across desktop interfaces, but the selected core still has to implement the protocol settings. On Android, start with v2rayNG, which uses Xray as its core. If you need alignment with a V2Fly setup, consider v2flyNG. The similar names of these mobile clients do not mean they support identical settings or core extensions.

Similar configurations are not necessarily interchangeable

The same outer structure in native configurations can hide differences in internal fields. Check transport names, DNS options, flow control, and security-layer settings especially carefully. Before running an Xray configuration with V2Fly, or vice versa, check the feature boundaries. An unknown field during parsing usually means the configuration model is incompatible. If startup succeeds but the connection fails, also check whether fields were ignored, defaults changed, or the server rejected the settings.

Back up nodes, subscription groups, and custom rules before switching cores. Prefer a standard configuration generated by the client, verify it with one known-good node, then restore custom settings gradually. Migrating an entire native configuration at once may bring along old paths, references to outdated rule files, and options supported only by the original core. If startup fails, remove nonessential extensions and work back from a minimal working connection instead of adding more compatibility options.

In v2rayN, choose a Core type that matches the node configuration; the exact menu location depends on the current interface. If the client selects a core automatically for a feature, check the startup log to see which process actually ran instead of relying on the node label. Client updates may also change how the interface works with the core. Keep a backup of your working configuration and test notes to help distinguish an update-related behavior change from a server-side change.

Don’t keep switching between cores just because a connection failed. First identify whether the problem occurs during parsing, startup, the handshake, authentication, or access to the destination; then check whether core support is relevant. A basic DNS resolution error, incorrect system time, or conflict on the local proxy port usually isn’t a reason to switch cores. To install or replace a client, choose the right version from the client download page so platform issues don’t get mixed up with protocol troubleshooting.

07 / SUBSCRIPTION FORMATS

Share links, subscriptions, and native JSON

Each format carries different information

A share link usually describes one connection, a subscription URL retrieves a set of connection profiles that can be updated, and native JSON can describe a core’s runtime configuration. They are not the same content with different file extensions. Share links are convenient for passing nodes around but may not include all routing, DNS, or custom outbound settings. Native JSON can express more, but may depend on a specific core and local files. Before importing, confirm which format the provider supplied.

Common text subscriptions encode share links, one per line, as Base64. This is a common format, not a universal definition of subscriptions. Some URLs return configuration documents or formats for other clients; repeatedly decoding them won’t turn them into a format supported by this site’s clients. A successful subscription download also doesn’t guarantee successful parsing: the server may return a login page, error page, or empty response. Check the client’s error category to tell a fetch failure from an unsupported format or node parameter.

Decoding cannot restore missing parameters

Base64 is an encoding, not a way to protect secrets. User IDs, passwords, and server details remain sensitive after decoding. Percent-encoding in links follows separate rules; don’t repeatedly decode the entire string. Extra conversions can change the meaning of special characters in passwords, labels, or paths. Prefer the client’s share or export feature when copying, and avoid rich-text editors that may insert line breaks, full-width characters, or invisible spaces.

Converting a share link to native configuration requires knowing how its protocol, transport, and security fields map. If the source link doesn’t include an extension parameter, a conversion tool can’t reliably infer its value. Converting a complex native configuration to a single share link can also discard custom DNS, multiple outbounds, and routing rules. Check the key fields after conversion and verify the connection; a successful conversion alone does not prove the result is equivalent.

Understand the limits of native JSON with a small example

The following is a routing snippet from a core configuration, not a complete configuration that can run on its own. It routes traffic matching the advertising domain category to the outbound named block. The full configuration must define that outbound, and the runtime environment must be able to read the required rule data. This example shows how fields reference each other; don’t paste the entire snippet into a client’s share-link import box.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  }
}

The domain strategy here determines when routing attempts name resolution; it is not a DNS server address and does not guarantee that all DNS requests go through a proxy. The outbound name in the rule must match the full configuration. Otherwise, even valid JSON may behave unexpectedly. Available rule data, valid category names, and core support for the fields are all runtime requirements. For field definitions, see the glossary.

Manage subscription updates separately from local edits

Nodes in a subscription group may be replaced or regenerated during an update. Direct edits to these nodes may be lost the next time the subscription refreshes. For local changes you need to keep, use a separate configuration or management method supported by the client, and document how it differs from the subscription. Don’t delete the old group before an update; first check that new nodes connect, then remove duplicates and expired entries so you can roll back if something goes wrong.

Subscription URLs often contain access tokens and should be treated like account credentials. Don’t submit them to unknown online conversion services or include the full token-bearing URL in a public support request. Prefer built-in client features when migrating, and confirm the destination client supports the format before importing. For more on format differences and conversion failures, see subscription formats and conversion. Compatibility ultimately comes down to whether the parameters are preserved, the core accepts them, and the connection works.

08 / SCENARIO SELECTION

Choose and verify a setup for your use case

For existing services, confirm full compatibility before comparing protocols

If you already have a working subscription, choose a client based first on the server’s protocol combination and your device platform. For desktop, start with v2rayN; on Android, consider v2rayNG. Choose v2flyNG if you need V2Fly-specific capabilities. Don’t rewrite a node just because another protocol sounds simpler in a description. Keep the original subscription, confirm that the client imports all required parameters, test one node, and only then expand to groups, routing, and multiple apps.

If a service offers several endpoints, put them in a separate test group and compare web browsing, sustained transfers, and your actual apps. Keep the ingress mode, DNS, and destination fixed; test one variable at a time. If the existing setup is stable and meets your needs, a migration should have a clear benefit, such as a compatibility requirement, easier maintenance, or a repeatable improvement. Don’t switch just because a protocol is newer. If results vary, check the server path and network fluctuations before drawing conclusions.

Use different checks for desktop work and mobile background use

For desktop browsers and tools that follow system proxy settings, start with the system proxy and check that the local listening port matches the app settings. Consider TUN and its permission requirements only if you need to capture additional traffic. After enabling TUN, verify local network access, name resolution, and other virtual networking software. Don’t attribute every change after expanding coverage to the remote protocol; some apps may simply be going through the client for the first time.

On mobile, focus on network changes, background operation, and traffic scope. Start with one stable node. Check whether essential tasks continue after the screen locks, then see whether the connection recovers when switching from Wi-Fi to mobile data. Use per-app proxying to exclude unnecessary background traffic, and adjust battery restrictions based on actual behavior. If abnormal drain starts only when one app opens, investigate that app’s network activity instead of immediately replacing the entire protocol setup.

Include DNS and routing in end-to-end checks

After connecting, confirm that apps actually use the intended outbound. Domain strategies, routing rule order, direct-connection rules, and DNS paths can make different sites behave very differently. An exit-IP check does not cover all traffic, and testing one web page doesn’t represent every app. To troubleshoot DNS, consider client logs, whether the app uses its own name resolution, and the system ingress scope. Don’t generalize from a single test page to every use case.

For example, if a routing rule sends traffic direct when you expect it to be proxied, changing the protocol won’t change rule priority. If an app uses encrypted DNS, the client’s regular DNS settings may not capture those requests. See DNS testing and configuration steps. Save your current settings before making changes. Decide which traffic should use which path, then verify the result rather than enabling every option that mentions DNS.

Choose the next step based on where the failure occurs

If import fails, check the format and encoding. If the core won’t start, check the configuration structure and supported features. For a handshake failure, check the security layer; for an authentication failure, check the user credentials. Once connected, if the destination is unreachable, check routing, DNS, and the remote outbound. This order reduces guesswork. Change one setting at a time, restart the necessary process, retest, and keep a brief record. A change in error category means the connection has reached a different stage, so adjust your troubleshooting accordingly.

When planning a new service, first list client coverage, transport environment, authentication method, and maintenance requirements, then choose a protocol combination. For certificate-based setups, plan to maintain the certificate name and renewals. For REALITY, define how keys and allowed parameters will be managed. Every setup depends on keeping its configuration consistent; it isn’t something you can install once and never check again. After updating the client or core, repeat the same tests rather than relying only on a successful startup.

Keep a verified configuration as your baseline and test experimental settings in separate entries. For a fresh setup, return to the quick start; for a specific error, visit the Help Center; to switch platforms or install a client, go to the download page. Protocol and core choices should make your configuration easier to understand and issues easier to diagnose—not add options you can’t explain.