V2Ray Protocols and Cores

Connection layers: clients, cores, and protocols

Know what each layer does

A GUI client manages configurations, imports subscriptions, switches outbound routes, and displays logs. The core handles connections, parses protocols, applies routing, and establishes the actual data channel. These are not two names for the same software. A client may bundle a core or launch one as a separate process. So when the interface saves a configuration successfully, that only means the management layer accepted its fields; it does not prove the running core supports every option. Check both whether the client can represent the configuration and whether its current core can run it.

Think of a connection in terms of three parts: proxy protocol, transport, and security layer. The proxy protocol defines authentication, destination details, and how data is structured. The transport determines how that data is carried, such as over a direct stream connection or inside another application-layer transport. The security layer handles the relevant encryption and authentication. VMess, VLESS, Trojan, and Shadowsocks are proxy protocols, but each handles encryption differently. REALITY is a security mechanism, not a generic protocol you can swap in for any of them during import.

A configuration name does not prove compatibility

A provider might label a configuration “fast,” “mobile,” or “backup,” but those are just notes. The connection depends on the address, port, authentication details, transport type, and security settings. Even if two configurations both say VLESS, one may require a different core capability because it uses another security mechanism or transport. Likewise, similar labels in an interface do not mean two projects use identical configuration fields. Check the actual parameters instead of guessing from a label.

Start by noting the combination required by the server, then check the client against it. The address tells the client where to connect; the port identifies the listening service; a user ID or password authenticates the connection; the server name usually participates in the security handshake; and the transport path and host name may be conditions for application-layer forwarding. These settings can appear together, but they do different jobs. Putting the server name in the address field or the web path in the host field may let the underlying connection open while preventing the next handshake from completing.

From application traffic to the remote exit

Applications also need a way to send traffic to the client. A system proxy provides a proxy address to apps that honor those settings, but it does not guarantee that every program will use it. TUN receives traffic through a virtual network interface and also involves system routes, permissions, and DNS resolution. Both are traffic entry points, not remote protocols. Enabling TUN does not convert VMess to VLESS or supply security parameters missing from the server. When troubleshooting, first confirm whether traffic reaches the client, then check the outbound connection.

Keep a parameter checklist that excludes sensitive authentication values, and note where each setting came from and what it is for. For the first connection, use only the essentials. Add routing rules, multiplexing, or a virtual interface after verifying the basic setup. This makes it easier to tell whether a problem comes from the entry point, rules, or remote handshake. For quick definitions, see the quick glossary; to troubleshoot by symptom, see frequently asked questions. Always start with the complete combination supplied by the server, not a protocol label to which you plan to add parameters later.

VMess: authentication, encryption, and time requirements

Background and intended use

VMess is a proxy protocol adopted early in the Project V ecosystem. Its design incorporates user authentication, request details, and data protection, and it has long appeared in client configurations and subscriptions. It is commonly used to connect to an existing service, rather than to assemble a new security setup from scratch. When assessing it, distinguish the protocol’s own data protection from any additional security layer: a VMess configuration does not mean every transport must use the same extra security mechanism, nor does it let you omit settings required by the server.

The user ID is a key authentication field and is commonly represented as a UUID. It is not a subscription label or a machine ID for the remote server. Copy it in full without adding quotation marks, spaces, or line breaks. The connection address can be a domain name or a literal address; resolving it and authenticating the user are separate checks. If a connection fails, first verify DNS resolution and port reachability, then check authentication and the security handshake. This is more useful than repeatedly changing the user ID.

Legacy fields and modern authentication

Older VMess configurations often include an extra ID count field, shown as aid in some share formats. Modern AEAD usage generally no longer follows the legacy extra-ID workflow, and the common value is zero. But changing this field is not a universal fix. Compatibility can vary between older servers, legacy importers, and current cores. If your source still provides legacy parameters, ask the configuration provider what the server actually supports instead of editing fields based on screenshots from different software generations.

Time synchronization deserves a separate check when troubleshooting VMess. Its authentication mechanism involves time requirements, so a significantly incorrect system clock can cause authentication to fail. Check the actual time and automatic synchronization status; the displayed time zone alone is not enough. A different time zone does not necessarily mean the clock is wrong, and manually changing the displayed hour to match another region can make an accurate clock incorrect. Recheck the time after a desktop resumes from sleep, a virtual machine unpauses, or automatic time is disabled on a mobile device.

Encryption options and transport settings

A client may offer automatic or specific data-encryption options, but what works depends on both implementations and core support. Hardware acceleration, processor architecture, and connection load all affect the real cost, so an algorithm’s name alone cannot predict throughput. For an existing configuration, keep the provider’s parameters. To compare algorithms, hold the server, transport, and test workload constant, then measure processor use and sustained transfer performance instead of changing several fields at once.

VMess works with different transports, but the address, path, host name, and security name must still match the server deployment. For example, with a reverse-proxied connection, reaching the underlying port does not mean the application-layer path is correct. A mismatch in path capitalization, leading slash, or forwarding conditions can cause rejection later in the connection. Do not assume the security-layer server name should match the configuration label. If the client shows a different transport type after import, check whether it parsed the share format completely before connecting.

VMess is a reasonable choice when an existing service explicitly supports it, its parameters are known, and the current client and core can run it fully. Its earlier introduction does not make it obsolete, and broad compatibility does not make it the right fit for every device. If the connection is stable, upgrade or migrate only to meet a specific need, such as using a newer security mechanism or reducing maintenance complexity. Keep the original entry, add the new configuration separately, and verify it on its own so you have a baseline for comparison. For common authentication failures and log-reading tips, see the troubleshooting FAQ.

VLESS and REALITY: combining a protocol and security layer

A lean protocol still needs a security design

One goal of VLESS is to reduce the work handled by the protocol layer and leave data protection to an appropriate external security mechanism. It handles authentication and proxy requests, but the protocol name alone does not protect the connection. The none encryption option shown in an interface usually describes the VLESS layer; it does not mean the entire connection is necessarily unencrypted. Actual security also depends on the external configuration, such as correctly using TLS or REALITY and completing authentication as required.

This layered design makes it easier to explain each setting by its role, but demands more careful checks of the combination. The user ID belongs to protocol authentication; the server name and related public key parameters belong to the security handshake; the transport type determines how data is carried; and some flow-control options depend on the protocol, security layer, and core implementation together. An interface that lets you fill in every field does not mean those fields can be combined arbitrarily. For unfamiliar options, check their requirements instead of copying values from another configuration to fill in the blanks.

REALITY parameter requirements

REALITY is a security mechanism that depends on specific implementation capabilities and is commonly used with VLESS configurations in Xray. A client typically needs the connection address, port, user ID, and related parameters such as the server name, public key, and short ID. Field labels may differ across interfaces, but their roles do not change. The public key is used for the corresponding handshake verification; it is not a subscription address. A short ID is not a user note. If parameters are missing, get the complete configuration from a trusted source. Generating a random value will not fix remote authentication.

The server name must meet the conditions allowed by the server configuration; do not replace it with a popular website domain at random. The connection address and server name can differ: the former establishes the network connection, while the latter participates in the security handshake. Making them identical is not necessarily correct. The public key, short ID, and server name are not interchangeable alternatives. Check them as a set and make sure the importer has not omitted or mis-mapped any fields. Do not stop at seeing VLESS in the protocol field.

Flow control, fingerprints, and transport compatibility

Some configurations use a specific flow-control mode, such as a Vision option in the interface. This is not a universal speed switch that every VLESS connection needs; whether it applies depends on the server, transport, and security combination. Do not copy it into configurations that do not provide the field. Similarly, a client fingerprint affects security-handshake behavior, but changing it does not increase bandwidth. Start with the combination required by the server or explicitly supported by the client, then decide whether any adjustment is needed. This helps avoid mistaking compatibility problems for performance issues.

If a client imports a configuration but immediately reports an unsupported security type or unknown field at startup, check the running core first. The GUI may recognize REALITY link parameters even when the selected core does not support them. After switching cores, the entry may retain its original fields while the generated runtime configuration changes. Back up the configuration before switching, then check startup output and logs to make sure the parameters actually reach the core. Do not rely only on the protocol label shown on the configuration card.

This combination is suitable only if the server explicitly supports it, the client can save all required fields, and the core can run the relevant implementation. It does not automatically outperform other combinations or replace other operational checks beyond certificate management. On mobile devices, also consider network switching, persistent connections, and background behavior. For everyday use with an existing subscription, importing it fully and keeping its parameters intact is usually more reliable than manually chasing options. For more on how protocols and cores differ, see Xray vs. V2Fly core differences.

Trojan and Shadowsocks: security boundaries and method identifiers

How Trojan works with TLS

Trojan carries proxy authentication and requests inside a TLS connection. Common configurations use a password for authentication. Its design differs from VLESS, and comparing field counts alone does not tell you which implementation is lighter. The address, port, and password are only part of the setup; the server name, certificate verification, and transport must also match the server. Seeing a password after import does not mean the certificate chain is trusted. A reachable port does not prove that the security handshake and proxy authentication have both succeeded.

Certificate verification confirms the identity of the peer. If the name does not match, the certificate has expired, or the trust chain is invalid, first check the configured server name, system time, and server-side certificate deployment. Disabling verification changes the connection’s security boundary and is not a long-term fix. Custom trust environments in enterprise networks should be handled according to their actual policies, not by skipping verification everywhere. The goal is to find why verification fails, not merely to dismiss the warning.

For Shadowsocks, the cipher method is a compatibility requirement

Shadowsocks typically provides a connection through a compact proxy-and-encryption combination. Its key settings are the address, port, encryption method, and password. The encryption method is not a local preference that can be changed at will; it must match on both sides. Methods from different generations can differ significantly in key requirements, session handling, and implementation support. A client listing more methods than the server supports does not mean you can choose any of them locally.

Newer methods may enforce strict key-format requirements, so a short, human-readable passphrase is not always a valid key. Legacy share links may also encode credentials differently: some encode the method and password together, while others represent the authentication part and address separately. Even after successful parsing, check that the method name and password are intact, especially that special characters were decoded correctly. For a subscription from a known source, use the client importer rather than repeatedly decoding, concatenating, and re-encoding the link yourself.

Extensions and datagram support

Some Shadowsocks configurations depend on additional extensions that certain GUI clients or their current cores do not implement. The basic protocol may be recognized while the connection still fails. A matching protocol name does not prove full compatibility; check whether an extension is required, which component handles it, and whether the software actually supports it. This guide covers the choice among three clients on this site. It does not recommend installing add-ons from unknown sources just to follow a particular share link.

For voice, gaming, or other datagram-based applications, check UDP support across the entire connection. The client entry point must accept datagrams, the protocol implementation must carry them, the server must allow forwarding, and the application traffic must actually reach that entry point. Missing any one of these can leave web browsing working while a particular app fails. Do not assume this means the protocol is “too slow.” Use logs and application behavior to identify the traffic type, then check the client entry mode and server capabilities.

Choosing either protocol still depends on how the existing service is deployed. An existing Trojan service with properly managed certificates can be used as configured; a Shadowsocks service with a supported method and clear parameters also has a valid use case. Do not force an incompatible setup into an “importable” one by disabling identity checks, changing the encryption method, or removing extension fields. For migration, have the server provide a new, complete connection entry and verify it separately, keeping the original as a fallback.

Core families: Xray, V2Fly, and client compatibility

A shared origin does not guarantee ongoing interoperability

Project V provides the background for this ecosystem. V2Fly maintains V2Ray-related implementations, while Xray has developed its own features along a forked path. Their shared origins mean some concepts and configuration structures are similar, but the two projects are not the same program with different skins. Since the fork, features, security mechanisms, transport implementations, and field definitions may have evolved separately. Support for a protocol does not prove support for every extension built on it. Compare cores against your specific configuration needs, not by treating project names as performance ratings.

If you need REALITY or a specific flow-control feature, confirm that the Xray implementation and client support it. If you already have a V2Fly service and configuration, check what the corresponding core actually supports. Common basic protocols may work with both, but parameters, defaults, and constraints under the same name still need verification. For newer transports in particular, do not rely on an old tutorial to determine whether another core supports them. The useful question is “Can this runtime fully handle these fields in this configuration?”—not “Which core is more advanced?”

What the three clients do

For desktop, start with v2rayN. It manages configurations on Windows, macOS, and Linux, but specific capabilities vary by interface, system integration, and distribution package. On Android, consider v2rayNG with an Xray core first; if you need the V2Fly route, evaluate v2flyNG. These three clients are not simply platform editions of the same app. Their importers, routing editors, and settings may differ. When migrating, transfer what the configuration means rather than looking for identical menu labels.

Core switching in a client also has limits. Being able to select a core does not mean every configuration will automatically convert into an equivalent one. Some fields may work only with one core, while the client may generate different structures for other settings depending on the selected core. Custom configurations make the difference especially clear: a complete configuration file that one core can read should not be passed unchanged to another with the assumption that it will behave the same. Preserve the original file and runtime logs before migrating.

Checks before switching cores

First back up the subscription source, manual entries, and custom routes, then choose a configuration with clear parameters as a baseline. Temporarily disable multiplexing and complex routing that are not needed for verification. Start the new core and check for errors. Unknown fields at startup point to the configuration structure; authentication or security errors during the handshake point to remote parameters; a working website with app-specific failures calls for checking the traffic entry point, DNS resolution, and datagram support. Different stages have different causes, so repeatedly “switching cores” is not a useful universal fix.

Check routing rules separately as well. Domain lists, address lists, and resource file formats and locations can depend on both the client and the core. If the connection works after switching but traffic that should bypass the proxy goes through it, check the generated rule order and default outbound first, not protocol authentication. Missing rule files, different category names, or changes in DNS strategy can all affect matching. Core migration involves checking routing behavior as well as connection compatibility.

For long-term maintenance, note which configurations depend on a specific core, which rules the client generates, and which settings were changed manually. Keep a restorable configuration copy before updating. Afterward, verify a small number of connections before restoring your usual routing. Downloads are available from the client downloads page; this overview of core families is not an instruction to obtain a separate program. For more on the ecosystem, see Project V ecosystem overview; for platform and interface choices, see comparison of three clients.

Performance and battery use: distinguish handshakes, throughput, and background activity

“Speed” covers at least three different things

A common source of confusion in protocol comparisons is the difference between connection setup time, request response time, and sustained throughput. Connection setup involves DNS resolution, the underlying connection, the security handshake, and authentication. Response time also depends on the remote destination and network round-trip time. Sustained throughput depends on bandwidth, congestion, server load, and local processing capacity. A combination that loads a page faster the first time will not necessarily deliver more data over a long transfer. A protocol name explains only part of the overhead; it cannot replace observing the actual connection.

Handshake overhead matters more when many short requests repeatedly establish connections. For long-lived transfers, steady throughput and encryption cost matter more. Additional encapsulation can add processing steps and data overhead, but server deployment, forwarding paths, and connection reuse also affect the result. There is no fixed speed ranking for VMess, VLESS, Trojan, and Shadowsocks that holds across all conditions. Differences between devices, transports, and servers using the same protocol may outweigh differences between protocols.

Resource use depends on the workload

CPU usage depends on the encryption algorithm, hardware acceleration, data copying, and number of concurrent connections. Memory use is also affected by routing data, caches, buffers, and the client interface. Total usage shown with the full GUI open cannot all be attributed to the protocol. For a fair comparison, use similar rules and traffic entry points in both setups, then compare idle and loaded behavior. If one setup uses complex rules and a virtual interface while the other uses only a simple system proxy, the results are not a clean protocol performance comparison.

Multiplexing can reduce some connection setup overhead, but it does not help every use case. Packet loss, server limits, or interference between different types of traffic can make a shared connection slower to recover or cause additional waiting. Some flow-control and multiplexing combinations also have implementation constraints, so both sides must support them. Increasing the number of multiplexed streams or connections is not a universal way to speed things up. Keep the default or provider-specified settings first; if a problem can be reproduced, change only one variable at a time.

On mobile, battery use depends largely on how the client runs

Mobile power use comes not only from encryption, but also from wireless wake-ups, background keepalives, frequent reconnects, DNS resolution, and forwarding traffic. A setup that keeps communicating while idle may use more power than one with slightly heavier processing but a stable connection. Switching between Wi-Fi and mobile data also affects recovery after old connections fail. Screen brightness, signal strength, and other background apps can mask protocol differences, so one battery drain episode is not enough to conclude that a core is more efficient.

When testing v2rayNG or v2flyNG, use similar network conditions and app workloads. Observe foreground use, idle time with the screen locked, and behavior after switching networks. System battery management may restrict background activity, causing disconnections or slower recovery after the screen locks. Adjust those restrictions based on actual needs and power use, rather than disabling all battery-saving measures by default. Also check for frequent subscription updates, automatic tests, or repeated retries; these background tasks are often more likely to cause extra drain than small differences between protocols.

When choosing a setup, first eliminate clear incompatibilities and repeated reconnects, then compare performance. Recording test conditions, configuration combinations, and the stage where a problem occurs is more useful than saving a single latency number. Results apply only to the tested device and network; they are not a permanent protocol ranking. If regular browsing and sustained transfers are stable but one app has a problem, check its traffic entry point and routing first. If every configuration slows down at once, check shared network conditions instead of repeatedly changing protocol settings.

Subscription compatibility: share links, encoding, and field preservation

A link’s appearance does not tell you its content format

A single share link describes one connection configuration; a subscription URL retrieves a set of configurations that may be updated. Both can be copied to the clipboard, but they are managed differently. Share links usually have a protocol prefix. A subscription URL is generally a network address that returns a list of links, encoded text, or another structure. A URL beginning with a secure web protocol only tells you how the request is made; it does not guarantee that the current client can recognize the response. Before importing, confirm how the provider intends the address to be used.

VMess share links commonly contain encoded structured data. VLESS and Trojan links often combine authentication, an address, and query parameters; Shadowsocks has several ways to encode authentication. These formats are widely used in the ecosystem, but not every importer supports every variation. A parsing failure may mean the link was truncated or its encoding was damaged, or that the source uses fields the client has not adapted to. Determine whether the error is at the format or runtime stage before making changes.

Check the configuration after import, too

A client usually converts a link into an internal record, then generates a runtime configuration for the core. The process may drop fields it does not recognize or add defaults for missing ones. So “import successful” is only the first step. Check the protocol, address, port, authentication, transport, security layer, and any extra parameters—especially REALITY settings, flow control, server name, and transport path. If a setting in the original link is missing from the interface, find out whether it was preserved before changing the remote server.

Special characters are a common source of errors. Separators in passwords, query strings in paths, and non-Latin notes may need correct percent-encoding. Forwarding a link repeatedly through chat or treating the whole string as an ordinary web address can truncate it or alter how it is decoded. Do not repeatedly decode the entire link if you are unsure of its encoding layers. Recopy the original content, use the appropriate import option in the client, and make sure the pasted text does not include extra instructions, spaces, or line breaks.

Subscription updates and local edits

Subscription updates generally use the content returned by the remote source. Each client has its own rules for matching duplicates, keeping labels, and overwriting settings. Manual edits to subscription entries may be reverted or replaced on update. If you need to keep a test configuration, copy it to a separate entry if the client supports that, and label its purpose clearly. A separate copy will not automatically receive updated addresses or authentication details from the source, so check it regularly. Subscriptions and manual configurations each have trade-offs; avoid mixing them into a group of entries with no clear source.

A subscription URL may contain access credentials and should be treated as sensitive. Hide the full URL, user ID, password, and related private parameters in screenshots, logs, and bug reports. For a download failure, the connection error, response type, and parsing message are usually enough; do not publish the entire subscription. If the response is actually a login page, error page, or empty text, the client may report a parsing failure. That does not necessarily mean the protocol is unsupported; the request may simply have returned something other than the expected configuration list.

When migrating clients, use a subscription format the provider explicitly supports and cross-check a representative configuration. Comparing entry counts alone cannot prove the migration is complete: the same number of entries may still be missing key fields. After a bulk import, verify one entry first, then check representative entries for each protocol and transport. For copying, adding subscriptions, and updating, see the Getting Started guide. For format differences and import methods, see share links vs. subscription URLs. Performance and stability comparisons only make sense after the fields are preserved correctly.

Choosing a setup: start with a minimal configuration and verification sequence

Narrow down options based on your constraints

With an existing service, do not start by ranking protocols. First list the combinations the server offers, the device platforms, and the actual workload. For desktop, start with v2rayN, then check which core and transport the configuration requires. On Android, start with v2rayNG; if you need the V2Fly route, consider v2flyNG. If the server offers just one complete, supported combination, configure the client to match it rather than changing authentication or security settings to chase another protocol label. If you can choose the server setup yourself, factor in maintenance capacity and upgrade costs.

For mobile use with frequent network changes, focus on reconnects and background behavior. For long desktop transfers, focus on throughput stability and CPU load. For routing different apps through different exits, check routing options and traffic entry points. For datagram workloads, first confirm support across the full connection. Protocols only handle part of the picture. Asking only “Which protocol is fastest?” can hide the real constraint—for example, an app may not use the system proxy, or DNS may not enter the routing logic as expected.

Start with one minimal, verifiable connection

For the first test, enable just one remote configuration with clear parameters, keep routing simple, and direct one known app through the client. Confirm that the core starts normally, then request a regular website and check the logs for the connection and outbound route. A working website proves only that this request path works; it does not verify every app, domain, or traffic type. Restore routing rules, a virtual interface, and other features gradually, so you can compare results after each change.

To check routing, start with a small rule set that makes the behavior easy to verify. The snippet below is a routing fragment for an Xray- or V2Ray-style configuration. The complete configuration must already contain a direct outbound tagged direct; this is not a standalone file you can run. The example sends only an exact match for a reserved example domain through that outbound. Other requests follow the remaining rules or default outbound in the complete configuration. A client’s GUI routing editor may express this differently; do not paste the fragment into a share-link field.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

Troubleshoot by failure stage

If the core will not start, check the fields, configuration structure, and core support first; there is no need to test remote bandwidth yet. If DNS resolution fails, check the address spelling and resolution path. If the connection times out, check network reachability, the port, and the server listener. If the security handshake fails, check the system time, server name, certificate, or public key parameters. If authentication fails, check the user ID, password, and protocol on both sides. If the connection succeeds but some apps fail, check the entry mode, routing, and datagram support. This sequence gives each change a clear purpose.

When restoring complex routing, remember that rules are usually checked in order, so a broad rule near the top can shadow more specific rules below it. Whether domain and address rules match also depends on the DNS strategy and data sets. Do not treat geographic categories as a permanently accurate way to classify traffic; an app may use multiple domains and address ranges. First decide which outbound should handle the traffic, then check which conditions actually match. For more on the concepts and rule-conflict checks, see geosite and geoip routing strategies.

Keep a fallback before making lasting changes

Change one layer at a time: switch the remote entry, change the traffic entry point, or switch the core—but do not change the protocol, routing, and DNS at once. Record the original configuration source, why you changed it, and what happened; do not record authentication values that could be exposed. Once the new combination is stable, replace the everyday entry and keep the old one until the new path is verified. If an update causes problems, review what changed first rather than reimporting every subscription. For routine setup, return to the Getting Started guide; for a specific issue, see frequently asked questions. This handbook provides guidance for evaluating configurations; it does not prescribe one set of parameters for every server.