V2Ray Protocols and Cores
A Guide to Choosing

Configuration Layers: A Protocol Is Only Part of the Connection

Break a configuration into four layers

Protocol names in a client describe only part of the connection. An app sends a request to a local proxy, and the core uses routing rules to choose an outbound. The proxy protocol then wraps the destination address and authentication details, and the selected transport connects to the remote server. A security layer protects that transport. That is why VLESS, TCP, and TLS can all appear in one configuration: they do not conflict, and they cannot replace one another. To check compatibility, look at all these layers together, not just the protocol label in a list.

Keep the local entry point separate from the remote protocol. A browser connecting to a local HTTP or SOCKS port does not mean the remote server uses the same protocol. System proxy settings usually direct apps that honor them to the local entry point; they do not automatically capture traffic from every program. TUN mode intercepts traffic closer to the network layer, with different coverage, permissions, and DNS handling. If an app cannot connect, first check whether its traffic reaches the core, then check the remote protocol. This can save a lot of guesswork.

What the transport and security layers do

TCP provides a reliable byte stream. WebSocket adds an HTTP upgrade during connection setup, while gRPC uses HTTP/2 to structure transport. These options affect how connections are established and what intermediate infrastructure they can work with; they do not replace user authentication. Paths, service names, and request headers are usually transport settings, not passwords. If the client uses WebSocket but the server expects plain TCP, retries will not fix the mismatch—even if the address, port, and user ID are correct. Make sure both ends use the same transport first.

TLS authenticates the server and protects the connection. Certificate names, Server Name Indication, and the certificate trust chain all matter. REALITY is a different security-layer mechanism, and support depends on the core. The two are not interchangeable across every field. A service name containing “TLS” does not prove that the correct security layer is enabled; check the client settings, exported fields, and runtime logs. The proxy address can be an IP while the name used for verification is a domain. Those fields serve different purposes, so do not force them to match.

Troubleshoot one layer at a time

When you receive a configuration, record its details in a consistent order: server address and port, protocol and authentication, transport, security layer, and any flow-control settings. Then check routing, DNS, and the local proxy mode. The first group determines whether the remote connection can be established; the second determines which requests use it and where domains are resolved. Changing everything at once might restore access by chance, but you will not know what fixed it—and the problem may return after the next subscription update. Change one layer at a time and keep the original configuration so you can reproduce the result.

Read logs by layer, too. For a refused connection, start with the address, port, and server listener. For a handshake failure, check the security layer and transport. For an authentication failure, verify the user details. “Start with” does not mean the cause is certain: a server closing the connection can also look like an interruption. Match the error to the configuration and timestamp so you do not mistake an unrelated background request for evidence about this connection. For more error-term explanations, see the Xray core log troubleshooting notes.

VMess and VLESS: Authentication and Encryption Trade-offs

Why VMess includes more protocol features

VMess is an early Project V protocol that incorporates user authentication and data protection into its design, allowing proxy connections to work across different transport environments. It is more than a password field added to a request: its handshake and data encapsulation follow their own rules. Both client and server must implement the same protocol. VMess overhead depends on the encryption implementation, processor, outer transport, and connection reuse. Its age alone does not mean it is slower, and the protocol name says nothing about a connection’s available bandwidth.

Modern VMess configurations typically use AEAD authentication. The extra ID parameter found in older tutorials is a legacy compatibility detail, not a tuning control to reach for today. If an imported legacy link triggers an outdated-format warning or authentication failure, ask the configuration provider which format is current instead of experimenting with the extra ID. VMess also depends on accurate system time. Distinguish the device’s actual clock from its displayed date and time zone: authentication depends on the clock being correct. Fix the system time and check the logs before changing encryption options.

What VLESS leaves to the outer layers

VLESS is designed with a lightweight protocol structure and does not handle data encryption within the protocol in the same way as VMess; it is used with an external security layer. The user ID authenticates the user, but does not by itself provide complete protection for the connection. That is why common configurations pair VLESS with TLS or REALITY. Choosing VLESS does not mean you can skip security settings. If a protocol field says “unencrypted,” understand that it refers to this layer—not that the entire connection should travel in plaintext over an untrusted network.

A UUID is a common way to represent a user ID. Preserve it exactly when importing; do not add spaces, line breaks, or full-width characters. A client can generate a new ID, but doing so locally does not update the server. The user credentials must match the server’s record. Flow control is another field that is easy to misunderstand: it is not a universal speed boost, nor is it required for every VLESS combination. Use it only when the server explicitly provides the setting and the current core and transport support it. If unsure, keep the imported value; do not invent a flow-control name.

How to choose between them in practice

If your VMess configuration is stable, migrate only for a clear compatibility need, a server-side maintenance plan, or a problem confirmed by testing—not because another protocol gets more attention. Client support means it can handle that kind of configuration; it does not mean the provider has deployed the corresponding server. Likewise, when you receive a VLESS configuration, do not look for every VMess field. Different protocols use different authentication and encapsulation structures, so a missing field does not necessarily mean the import failed. Check the documentation for that protocol rather than filling in fields from another interface.

In v2rayN, open the server editor and check the protocol type first, then the transport, security layer, and flow control. Check v2rayNG in the same order. Interface labels may change between client updates; rely on what each field means. If the connection stops working after a core change, note the old and new core names and the error instead of deleting and recreating the UUID. To roll back, restore the full known-good configuration. A clear before-and-after comparison is easier to troubleshoot than repeated edits to one record.

Compare resource use only after the security layer and transport are set up correctly. A short web request may depend mostly on DNS resolution and the handshake; a sustained download is more affected by bandwidth, congestion, and encryption throughput. The two workloads can produce different results. For most users, choose a combination that the provider maintains, the client recognizes fully, and that does not require manual field edits. Protocol choice should reduce configuration ambiguity, not find the shortest-looking or newest name for every record.

Trojan and SS: More Than Just a Password

Trojan depends on a complete TLS setup

Trojan’s typical design puts authentication and proxy requests inside a TLS connection, relying on a mature TLS implementation to protect the transport. Clients usually need the server address, port, password, and server name—but fewer fields do not mean simpler verification. The certificate must cover the name, be within its validity period, and be served with a complete certificate chain. If the password is correct but certificate verification fails, the problem is not at the password layer. First determine whether the secure connection failed to establish or whether authentication failed afterward, then check the relevant setting.

The server address and Server Name Indication can differ. The address determines where to connect; the name is used during the TLS handshake and certificate verification. If your provider gives you an IP address and a domain name, a missing or unfamiliar webpage at that IP in a browser does not mean the proxy configuration is wrong. Proxy listeners do not necessarily respond like regular websites. Keep the original fields, check the handshake result in the client logs, and ask the provider which server name is required. Do not fill in a random popular domain.

Do not treat disabling certificate verification as a routine fix. It weakens server identity checks and can hide a wrong system clock, an incorrect name, or an incomplete server certificate setup. If only one device fails, compare its clock and trust store; if every device fails, check the server configuration first. Application-layer protocol negotiation may also be part of the handshake. If the client and server require a specific value, use it as provided. Adding every available option “for compatibility” is not a sound approach.

Shadowsocks: Match the method to the key

Shadowsocks is often shortened to SS in client interfaces. Its compact encrypted proxy design handles traffic, but compatibility depends on more than the password: encryption method generations can differ in key format, identity handling, and core support. Selecting a method with a familiar name and entering arbitrary text does not guarantee a valid configuration. Treat the provider’s encryption method and key as a single set of parameters. Do not copy only the password and change the method to suit your preference.

Some newer methods require a key with a specific length and encoding, not a regular password. The client’s “Password” label is a generic interface term; it does not guarantee that any string is accepted underneath. If import fails, check whether a chat app truncated the value, special characters were escaped, or the current core supports the method. Removing trailing symbols, replacing characters, or re-encoding the key can corrupt a value that was originally correct. A client saving the record does not mean the core accepts it; startup validation is a more useful signal.

Keep plugins, transports, and protocol support separate

If an SS share link includes plugin parameters, check whether the client can recognize and run that plugin. Native core support for an encryption method is different from the client’s ability to invoke an external plugin. This guide does not recommend cycling through plugins by trial and error. First confirm whether the provider requires a native protocol connection or a combination with a specific wrapper. If the client does not support it, choose a configuration both sides can use; do not put a plugin name in a transport path field. Similar field names do not mean they do the same thing.

The two protocols also have different practical limits. A website working over TCP does not prove that UDP apps will work; UDP forwarding also depends on server support, routing, and the local entry point. Test a common website for basic connectivity, then test any apps that need UDP separately. For routine access, keep a configuration with a clear source for its settings. If a particular app’s network behavior matters, check UDP, DNS resolution, and the scope of system-level traffic capture. Do not attribute every difference to protocol speed.

REALITY: Matching Security Layers to Parameters

REALITY is not another proxy protocol option

REALITY often appears alongside VLESS, but they do different jobs. VLESS handles proxy authentication and requests; REALITY handles the outer security handshake. It uses TLS-related mechanisms with its own authentication and handshake processing, which is not the same as deploying a regular website certificate. With that distinction in mind, “VLESS” as the server protocol and “REALITY” as the security layer are not duplicate settings. You cannot switch the security option to REALITY for another protocol and expect the server to accept it; both ends must support the combination.

A typical REALITY client configuration includes the connection address, server name, public key parameter, short ID, and client fingerprint. It may also include a flow-control requirement. Each value corresponds to a server-side setting. The public key parameter is used for client-side authentication calculations; it is not a place to enter the server’s private key. Never put the server private key in a subscription or share link. Interface labels can change between versions, so check what each field does and follow the provider’s instructions. Do not paste a value into every box labeled “key.”

Server name, public key, and short ID

The server name is used in the handshake and must match the server’s allowed configuration. It is not a free-form note and may differ from the connection address. The server also configures the handshake target; the client cannot change these server-side details on its own. With a complete configuration, make sure the client preserves the required fields. Do not guess the target from the name and replace it with another domain. Even if that domain opens successfully, it does not mean it matches the REALITY server.

The short ID is usually represented as hexadecimal text and must meet the format requirements of the server and implementation. Whether an empty value is allowed depends on the server configuration; it is not always a missing field. When entering it manually, check the allowed characters and required length, and avoid spaces or full-width characters. Import the public key exactly as provided; do not let an editor insert line breaks that end up in the saved value. If the connection worked before a subscription update but fails afterward, compare these authentication fields first, then check whether an old local override is still applied.

Fingerprints, flow control, and troubleshooting order

Client fingerprints take effect through the handshake implementation provided by the core. A long list of options in the interface does not mean the active core supports them all. If you see an unsupported fingerprint warning or a related initialization error, check which core is actually running and where the configuration came from. Flow control must also be checked separately: it is not another name for REALITY, and enabling REALITY does not mean you can fill in any flow-control value. Common combinations have specific limits. When changing transport, verify that the flow-control setting still applies; do not copy every advanced option from another configuration.

Troubleshoot in three stages. First, check that the network can reach the given address and port. Second, check whether the security handshake completes; verify the server name, public key, short ID, and fingerprint. Third, check user authentication, flow control, and the proxy request itself. The same handshake error in a log can have several causes, so do not conclude from one message alone that the public key is wrong. Make sure the client is not using a same-named record from another subscription group, confirm the core reloaded the configuration after your change, and match the error timestamp to the connection attempt.

Use REALITY only when the provider maintains the configuration and your client can import it completely. You do not need to copy every regular TLS certificate option, and you should still verify where the parameters came from. In v2rayN or v2rayNG, keep the parsed values unchanged whenever possible. If an import tool does not recognize the security layer, do not switch to regular TLS just to fill the interface. Check client and core compatibility first, then consider a different configuration that both sides support.

V2Fly and Xray: What the Client Core Actually Does

The graphical client and proxy core are separate projects

Project V is the starting point for understanding this ecosystem. The V2Fly community continued development and maintenance of the V2Ray core, while Xray evolved from related code and developed its own features and configuration details. Their shared origins mean that many basic concepts and configuration structures are similar, but new features are not always kept in sync. They are not simply identical programs with different download links. And a client labeled “V2Ray” does not prove which core is actually running; runtime status and the core identifier in logs are more reliable.

v2rayN is the recommended desktop graphical client. It manages server records, subscriptions, proxy modes, and core selection; the selected core handles the protocol connection. v2rayNG is a commonly used Android client with the Xray core, while v2flyNG is intended for V2Fly core use. These are three clients, not three proxy protocols. On mobile, you generally cannot drop in another core binary as you might change a desktop program path and expect the same features. Choose based on each client’s build and supported capabilities.

Shared structure does not make configurations interchangeable

Both cores use concepts such as inbound, outbound, routing, and DNS, and some basic fields are similar, so simple configurations may be portable. For REALITY, specific flow-control settings, newer transport implementations, or extension parameters, check support in the current core. Being able to parse JSON does not mean a core understands every option in it. Some differences cause an immediate startup error; others are transformed by the client or only appear when you connect. Saving successfully is just the first step, not proof of compatibility.

Client-side conversion matters, too. Graphical clients often save their own internal records and generate a core configuration at startup; subscription fields shown in the interface may not pass through unchanged. Custom configuration modes may bypass some of the client’s routing and DNS generation logic. If changing an interface option has no effect, first check whether the record uses a custom configuration and whether that mode honors global settings. Do not keep stacking similar toggles; that just adds settings that may never take effect.

Keep a baseline for comparison when switching

Before switching cores, save the known-good client settings and note the protocol, transport, security layer, DNS, and routing mode. On the new core’s first launch, start with a simple configuration that both sides explicitly support. Confirm basic connectivity before restoring custom routing. Migrating complex rules, experimental transports, and multiple advanced fields all at once makes failures hard to diagnose. Do not mistake a core startup failure for a remote server issue: invalid syntax or unsupported parameters can prevent the core from starting its listener at all.

Check feature support against the environment you actually have installed; there is no need to invent a support table that will quickly go stale. Client, core, and subscription-format updates follow separate timelines. A newer core may support an option that the client cannot yet import; conversely, the client may show a field before the bundled core implements it. When you hit a compatibility issue, include the client name, active core, protocol combination, and a summary of the error. That is more useful than saying only that “the latest version doesn’t work.”

Keep routine choices simple: use v2rayN on desktop, and choose v2rayNG or v2flyNG on Android to match the configuration. Do not move advanced settings across cores just because their names look similar. Open source makes code and maintenance available for review; it does not mean every fork behaves identically. For more on how the projects relate, read A guide to the Project V, V2Fly, and Xray ecosystem. To compare platform-specific workflows, see the comparison of three clients.

Connection Speed, Resource Use, and Android Battery Life

Break “speed” into separate stages

Connection speed covers several things: DNS lookup time, connection setup time, security handshake time, time to first response, and sustained throughput. A protocol affects only some of these; the network route and server often matter more. A webpage loading quickly does not mean a download will be fast, and high download throughput does not mean every short connection responds quickly. Before comparing protocols, specify which stage you measured. Do not collapse different metrics into a single “latency” number and draw an oversimplified conclusion.

For results you can interpret, keep the device, network, server location, destination, and test period as consistent as possible. Before testing, pause automatic subscription updates, large background transfers, and frequent health checks. Keep the routing mode and DNS policy the same. Then alternate between the two configurations instead of testing one in the morning and the other at night. Compare the first request with later ones: connection reuse, DNS caching, and TLS session resumption can change subsequent results. Record the overall trend; decimals that cannot be reproduced are not useful.

Lower CPU, memory, and connection reuse are not always better

Encryption, data copying, transport encapsulation, and the number of connections all consume resources. Hardware acceleration on the processor may matter more than a protocol’s header size. If the outer layer already uses TLS, additional inner-layer encryption affects workload, but that is no reason to disable protection required by the protocol. Memory use can grow with active connections, buffers, DNS cache, and rule sets. If process usage spikes briefly, check whether it falls after connections end. Do not mistake normal caching for a leak or judge cores from idle screenshots alone.

Connection reuse can reduce the cost of repeatedly establishing connections, but it can also expose multiple requests to congestion or failures on a shared connection. Whether it makes things faster depends on the implementation, transport, and app workload; there is no setting that is best for every configuration. Some flow-control or transport combinations also limit how reuse can work. For a stable configuration, keep the defaults unless you can reproduce a short-connection problem and test one change at a time. Do not increase reuse, concurrency, and buffer sizes together, then credit one setting for a temporary improvement.

Android battery use usually depends on more than the protocol

Mobile battery use is strongly affected by how long the radio stays active. Frequent keepalives, repeated reconnects, continuous probes, and small background requests can keep waking the network, even when each transfer is tiny. After the screen turns off, system background limits may put the process to sleep, causing a reconnect when it resumes. So a protocol that uses less power during one long download may not use less during an overnight standby. Compare screen-on use and screen-off standby separately, with similar app habits and network types; do not attribute differences between scenarios to the protocol.

TUN coverage, per-app routing, and DNS queries also affect mobile workload. Full-device capture can send more background traffic through the core; per-app or rule-based routing changes traffic paths and the number of lookups. Overly broad rules or repeated DNS failures can trigger extra requests and retries. If battery use seems unusually high, check for repeated errors, frequent network switching, and overly frequent connectivity checks before changing protocols. Do not disable all background activity just to save power; the system may keep the proxy entry enabled after the connection has stopped.

A practical order is: stabilize the configuration, stop unnecessary frequent tests, check background permissions, then compare protocol combinations. Include a period of normal use and a period of standby, and watch for disconnects and retries. If only one app drains the battery, check its own background behavior before changing cores. If connected but webpages will not load, follow the checklist for connected but unable to browse. Repeated retries caused by an unreachable service can distort battery comparisons.

Subscription Formats: What to Check After Import

Share links, subscription lists, and full configurations

A single share link usually describes one server record; a subscription URL generally returns a list of records or other client-readable content. A full core configuration is a different format and may define local inbounds, multiple outbounds, DNS, and routing. These are not interchangeable files that only differ by extension. “Import from clipboard” and “Add subscription URL” also handle different inputs. Treating a subscription URL as a single server link may produce an unrecognized-format message; pasting a full core JSON configuration into the subscription field will not turn it into an online subscription.

Share links encode fields differently across protocols, and some have legacy format variations. Notes containing non-ASCII characters, symbols, or spaces usually need correct encoding. Some content uses Base64, but that is encoding—not protection for subscription data. A link that copies and pastes correctly may still be altered when forwarded through a chat app. If the import count is unexpected, copy again from the original source and check for added explanatory text, line breaks, or trailing punctuation. Then review the client’s parsing message; do not hand the content to an unfamiliar conversion tool.

The same record count does not guarantee every field was imported

Newer security-layer, flow-control, or transport parameters may be ignored by older import logic. The client can show the server name, address, and port, making the list look fine while omitting a critical field. For combinations such as REALITY, inspect at least one imported record: check the protocol, security layer, server name, public key parameter, short ID, and flow control against the original. For WebSocket or gRPC, check the path, request headers, or service name. The number of records in the list is not proof that the subscription format is fully supported.

Clients can also handle subscription updates, duplicate records, and manual edits differently. Some manual changes are overwritten at the next update; other overrides continue to affect new records. Keep subscription groups separate from local test configurations, and copy a record before experimenting with individual settings. Do not treat a subscription record as a permanent hand-edited configuration. If the provider changes server parameters, local overrides can mix with the updated data, making it difficult to tell where each field came from.

Routing settings do not automatically transfer with server records

When moving from one client to another, importing server records does not necessarily transfer DNS, routing, per-app rules, or proxy mode. After confirming basic connectivity, check the default outbound and domain handling again. The snippet below illustrates a common routing structure in a core configuration: it sends only loopback addresses to an outbound named direct. It is not a complete configuration and cannot run on its own; the full file must already define the matching outbound tag. A short example like this explains how fields relate, but should not replace the entire configuration generated by the client.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "::1/128"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs means routing does not actively convert a domain to an IP address for the purpose of that rule. It does not mean the client stops all DNS lookups or that requests are never resolved. Other domain strategies may resolve domains under different conditions and affect IP-based rule matching; understand their behavior in the context of the core and DNS configuration. If routing changes after migration, first check whether the request reaches the core as a domain or an IP address, then check domain rules, IP rules, and the final default outbound. Do not infer the actual path from an option’s name alone.

Distinguish a failed subscription update from an unavailable server. The first happens while fetching or parsing configuration; the second happens when connecting. If existing records still work, do not delete the whole group because of one failed update. Check whether the update request succeeded, whether its response is a valid subscription, and then verify the format. For common issues such as an empty list, see the FAQ. For DNS and routing interactions, read V2Ray DNS split-routing and resolution setup. Randomly changing protocols will not fix a problem with the configuration source.

Choose by Use Case: Match Requirements to Configuration

Check shared capabilities across desktop and mobile

On desktop, start with v2rayN, then choose the appropriate download for your operating system and processor architecture. After installing the client, use a protocol combination explicitly supported by the provider; you do not need every advanced setting enabled for the sake of completeness. Keep a stable VMess, Trojan, or SS configuration if it already works. For a VLESS and REALITY combination, first confirm the active core and imported fields. The first priority is finding the overlap between client, core, and server capabilities; optimize resource use for a particular workload only after that.

On Android, check v2rayNG first if the configuration depends on Xray-specific capabilities. Consider v2flyNG if the configuration and maintenance path explicitly use V2Fly. Do not enable both apps at once to compare them: system VPN capture can cause interference, mixing the results with app switching and connection recovery. For background use, first ensure system permissions and battery settings allow the intended behavior, then compare protocols. For per-app routing, check the selected apps separately and confirm that browser tests and target-app traffic actually take the same path.

Test your workload instead of ranking protocol names

Everyday browsing and messaging rely mostly on short requests, so check DNS resolution, connection setup, and recovery after sleep. Sustained downloads depend more on stable throughput, device heat, and long-lived connections. Apps that need UDP must have their path tested separately. Establish a baseline with a known-working configuration for each use case, then compare another combination. If the configurations use different servers, the results describe those two services overall; they do not prove that one protocol is inherently better. If the provider cannot offer comparable conditions, prioritize compatibility and maintenance quality over speed rankings.

With multiple devices, “syncing configurations” usually means subscribing to the same source from different clients—not copying the entire desktop configuration to a phone. Each device still needs its own local ports, system-level traffic capture, per-app routing, and background permissions. You can standardize the server source and group names, but do not sync system proxy settings that do not suit the device. After migration, check web requests, any necessary UDP apps, and DNS behavior on each device. The same subscription does not mean every device will have the same network behavior.

Use a troubleshooting process you can roll back

Use four steps for routine checks. First, verify the source and fields: confirm the link is complete, authentication parameters match, and the transport and security layer are compatible. Second, confirm the client is using the right core, check that it starts successfully, and verify the local entry point. Third, test basic access with simple routing; do not change DNS and proxy mode at the same time. Only in the fourth step should you restore per-app routing, custom rules, and optional optimizations. Keep a known-good state at each step and roll back to the previous one if something breaks. This helps distinguish problems caused by later changes from protocol limitations.

When something fails, determine whether the error is local or remote. Core startup errors, port conflicts, and leftover system proxy settings belong to the local environment. Then investigate timeouts, handshake failures, and authentication rejections along the network and server path. If webpages load but DNS resolution does not behave as expected, the issue may be routing or DNS rather than protocol authentication. See DNS leak testing and configuration to understand query paths. Interpret test results in the context of the current network and client mode; one page alone cannot give a complete answer.

Keep a brief maintenance record: client and core names, protocol and transport combination, whether required security fields are present, routing mode, and the last environment known to work. Hide authentication details when reporting an issue; include only the structure and error summary needed to investigate. When the provider changes parameters, update the subscription and inspect a record before dealing with local overrides. This protocol guide explains what to check. To repeat the import and connection steps, return to the quick-start guide and follow one straightforward path instead of cycling through every advanced setting.