V2Ray Protocol and Core Selection Guide

The Four Layers of a Connection

Start with the Client, Core, and Remote Server

Before choosing a protocol in your client, identify three separate components. v2rayN, v2rayNG, and v2flyNG are graphical clients: they save configurations, display settings, start connections, and manage subscriptions. The core interprets the configuration, establishes connections, applies routing, and handles data. The remote server accepts connections using the agreed protocol. These are distinct software layers. A setting saved in the interface only shows that the client accepted the input; it does not mean the core understands every field or that the server uses matching parameters. On desktop, choose an installer through the v2rayN platform page. On Android, choose a client based on the core your configuration requires.

A connection can usually be described in four groups of settings: server address, proxy protocol, transport, and security layer. The address specifies where to connect; the proxy protocol defines authentication and how the destination is represented; the transport carries protocol data; and the security layer provides confidentiality and identity verification. Calling all of these “the protocol” makes troubleshooting harder. For example, VLESS is a proxy protocol, WebSocket is a transport, and TLS is a security layer; all three can be part of one configuration rather than mutually exclusive choices. A port is simply where the remote server listens—it does not identify the protocol by itself.

Client Fields Have Specific Roles

In a client, “Address” generally establishes the underlying connection, while “Server Name” or SNI supplies the name used in the TLS handshake. They may match, or the server configuration may require different values. WebSocket Host and path are separate application-layer parameters; similar labels do not mean you should copy the SNI into every field. Even when connecting directly to an IP address, certificate verification may still require a domain name. Follow the field assignments provided by the service. Do not treat Address, Host, and SNI as interchangeable, and do not disable certificate verification to hide a configuration error.

Routing rules do not change the remote protocol

Routing determines which outbound handles a request after it reaches the core: direct, proxied, or blocked. It does not automatically turn VMess into VLESS or supply missing TLS parameters. Android VPN mode and the desktop system proxy are local access methods. VPN mode receives selected traffic through the system's virtual network interface; the system proxy tells apps that honor proxy settings to connect to a local listening port. If the client says it is running but an app is not proxied, check the access method before changing the remote protocol. For more on these layers, see System Proxy and Routing Modes.

When reviewing a shared link, make a field checklist in the same order: confirm the address and port, identify the authentication fields and protocol, check for a transport-specific path, verify whether a security layer is enabled, then review routing and DNS. This makes it clear which settings are required by the remote connection and which are local preferences, even when changing clients. Do not judge a configuration by link length, its label, or whether the protocol name sounds newer. A label is just a label; the core's final configuration determines how the connection behaves.

VMess and VLESS: Design Trade-offs

VMess Builds Authentication and Data Protection into the Protocol

VMess is an early proxy protocol in the Project V ecosystem, designed around user identifiers, request authentication, and data protection. The UUID commonly shown in clients identifies a user; it is not a server domain or subscription address. Encryption and security options must match the methods supported by the core. Do not change them just because an imported configuration works. VMess can use different transports and can be combined with TLS. Protocol-level encryption and outer TLS serve different purposes, so neither field alone describes the security of the entire connection.

Modern VMess deployments typically use AEAD authentication. Extra IDs, legacy authentication modes, and historical compatibility options found in older guides should not be treated as general recommendations for current configurations. Whether an existing setup still works depends on both ends supporting the same mechanism. For an old subscription, confirm the authentication method actually used by the server, get updated connection parameters, then check client and core support. Repeatedly changing the extra ID or trying values found online usually creates more mismatches.

Check the system clock separately. Some protocol authentication flows rely on a time window, so a significantly incorrect device clock can cause authentication to fail even when the underlying TCP connection succeeds. Enable automatic date, time, and time zone before trying again; this is more useful than reinstalling the client. A correct clock does not guarantee valid authentication: the UUID, port, and remote settings still need to match. If logs stop at authentication, check those details first rather than changing DNS or routing—the request may not have reached the forwarding stage.

VLESS Relies on an Outer Security Mechanism for Data Protection

VLESS is designed to reduce the encryption work handled by the protocol itself, leaving data protection to an outer mechanism such as TLS or REALITY. It still requires authentication and a way to specify the destination; that does not mean the protocol has no overhead. The none value commonly used in VLESS configurations is the meaning of that specific field—it does not mean all data travels across the network in plaintext. Assess the security layer as part of the complete connection. Conversely, the name VLESS alone does not imply confidentiality if no outer protection is configured.

A VLESS configuration may include a flow field, such as xtls-rprx-vision. This is not a universal speed boost to copy into every connection; it depends on a specific processing flow, transport combination, and core capabilities. Both client and server must meet the relevant requirements. Adding it to an unsupported transport combination may cause the configuration to be rejected or the handshake to fail. If the service provider did not supply a flow, do not invent one based on its name. If a flow was supplied, do not assume it can be omitted just because another client's interface has no field for it.

Keep Every Parameter When Migrating an Existing Configuration

VMess and VLESS are not interchangeable by changing a dropdown. Even if two entries use the same server address and user identifier, the server must be configured for the corresponding inbound protocol. When migrating, get a new link from the server provider, check the security layer, server name, transport, path, and flow, then create a separate entry to test. Keep the existing working configuration so you can quickly distinguish migration errors from local network changes. Avoid overwriting subscription-managed entries; a later update may undo manual edits.

If an existing VMess connection is stable and the remote service has no migration plans, there is no need to replace the entire setup just for a different protocol name. For a new deployment that specifies VLESS and a particular security layer, choose a client and core that can represent those fields. In either case, prioritize end-to-end compatibility before considering overhead. If a provider only says “supports VLESS” without specifying transport and security layer, the details are incomplete. Get the missing parameters before importing rather than mistaking a compatibility issue for an unreachable server.

Trojan, Shadowsocks, and REALITY

Trojan Requires a Correct TLS Connection

Trojan is built on TLS, with password authentication and destination requests carried over a protected connection. A typical configuration needs a server address, port, password, and the relevant parameters for name verification. The password is a remote connection credential; do not post it in public logs or discussion forums. A successful TLS handshake and successful proxy authentication are separate stages. If the certificate name does not match, check the server name and certificate deployment. If the handshake completes but access is denied, check the password and remote service settings. Treating both stages as simply “can't connect” makes troubleshooting unnecessarily broad.

Certificate verification is not a switch to turn off casually. It confirms the identity of the service you are connecting to; disabling it changes the original security assumptions, even if the connection then works. An incorrect device clock, incomplete certificate chain, or mismatched name can all cause verification failures, and each needs to be fixed separately. Trojan extensions also depend on the implementation: a client that imports a basic password configuration may not understand every option added by another implementation. Check additional fields in a shared link rather than assuming they are decorative.

Shadowsocks Requires Matching Methods and Key Semantics

Shadowsocks usually appears as Shadowsocks or SS in a client. It combines a pre-shared secret with an encryption method. Although the configuration may look simple, the method is part of the connection protocol and must match on both ends. Do not change it to a more familiar-looking option in the client. Traditional AEAD methods and the Shadowsocks 2022 series are not interchangeable by renaming them. The latter requires key material in a specific format and length; an arbitrary everyday password is not a valid key, and the client cannot be expected to convert it automatically into the value the server needs.

When using Shadowsocks, check whether the subscription includes plugin parameters. Basic protocol support and plugin support are separate capabilities; without the plugin implementation, a correct address, port, method, and password may still not work. Methods and plugins can vary by core, so check what the core on your device actually accepts. Apps that need UDP also require UDP forwarding on the remote server, a local access path that carries it, and routing that does not block it. A webpage loading successfully does not prove these conditions are met.

REALITY Is a Security Mechanism, Not a Standalone Proxy Protocol

REALITY commonly appears with VLESS, so a shared entry may be labeled “VLESS + REALITY.” It provides security-layer functionality; it is not another account type on the same level as VLESS. Common client fields include server name, public key, short ID, and fingerprint. The public key corresponds to the server's key configuration, the short ID must match an identifier allowed by the server, and the fingerprint relates to client handshake characteristics. Required fields and formats depend on the configuration. Do not borrow them from another connection or mistake the public key for a UUID.

The server provider must design and supply the REALITY parameter combination. Being able to reach the remote address does not mean the public key, short ID, and server name are correct. If a connection fails, first check that the link was copied in full, especially query parameters containing special characters. Then confirm that the core in use recognizes those fields. Do not try random fingerprints, short IDs, or unrelated domain names. An empty field in the interface may mean the importer failed to parse it, not that the server does not require it; check the original shared link.

These three cannot be arranged as a simple old-to-new replacement chain. Existing TLS infrastructure, subscription format, server implementation, and mobile support all affect the choice. For client-only users, the most reliable approach is to keep the parameter combination provided by the service, confirm that the local client supports it in full, and compare options using the same network and workload. More names for protocols and security layers do not automatically make a configuration better. Fewer unnecessary layers are usually easier to understand and maintain.

Connection Speed, Throughput, and Resource Use

Evaluate Initial Connections Separately from Sustained Transfers

“Fast” can describe at least three different experiences: time to the first response after clicking, sustained throughput over a long transfer, and stability under concurrent requests. First response time depends on local DNS, remote address resolution, the underlying connection, and the security handshake. Sustained throughput is more affected by path bandwidth, packet loss, congestion control, remote server load, and device performance. A configuration that takes longer to load a page initially may still perform well during a large file transfer. Do not compare a single page load with a single speed test on another configuration; decide which metric you want to compare first.

The proxy protocol's own processing overhead is only part of the full connection path. Whether encryption can use processor instructions, whether TLS is layered on top, and whether traffic passes through a reverse proxy can all affect CPU use and connection setup costs. Differences that are noticeable on a low-power device may be small on a capable desktop. No protocol is always the most resource-efficient regardless of hardware, and low throughput caused by remote congestion should not be blamed on local encryption. Check the network and server load before drawing conclusions about protocol overhead.

Transport Encapsulation and Connection Reuse Have Trade-offs

Direct TCP, WebSocket, and gRPC differ mainly in how they carry data, their compatibility with intermediate infrastructure, and how they manage connections. WebSocket may require an HTTP upgrade and the correct path. gRPC typically depends on HTTP/2 and a matching service name. Intermediate forwarding must support the chosen transport too. These mechanisms add deployment flexibility but also add settings to maintain. Use them when the server requires them, not because more encapsulation layers are assumed to improve performance. A wrong path or service name can leave the underlying port reachable while preventing the proxy session from being established.

The client's “Enable Mux” option attempts to let multiple logical requests share fewer underlying connections. This may reduce the cost of opening connections frequently, but it can also expose requests to the same congestion or failure on a shared connection. Combining it with transport-level multiplexing does not guarantee additional gains; some protocol, flow, and core combinations also have specific limitations. Keep the default unless the server explicitly supports Mux and your workload has many short-lived connections worth testing. Mux is not a general fix to enable whenever a connection feels slow.

Use Repeatable Tests Instead of a One-Time Ranking

Start with an ordinary webpage to assess first response, then use a stable resource you are permitted to test for sustained transfer, and finally check concurrency and long-lived connections with a real workload. When repeating tests, distinguish a new connection from a reused one—caching and session resumption can change results. Pause other high-traffic tasks, and note any network switches or sleep events during the test. Do not keep only the best result or treat the connection test time shown by an app as end-to-end download speed; different tests can measure entirely different things.

CPU and memory observations need context too. Rule databases, connection counts, log level, and DNS cache can all increase resource use; do not attribute every change to the protocol. If the client is idle normally but uses more resources after many pages are opened, check concurrent connections and rule processing first. If a single sustained transfer makes the device noticeably hot, compare encryption and encapsulation settings. Turn off unnecessary verbose logging after troubleshooting and keep a record of the original settings, so you can identify which change caused a later difference rather than relying on memory.

Real-time communication needs extra checks for the UDP path and jitter. A working webpage only proves that some TCP requests succeed; it does not guarantee UDP works for calls, games, or name resolution. If a workload stutters intermittently, check the access method, server forwarding, and packet loss instead of just switching protocol names. For long-term use, reliable performance in the actual workload matters more than a one-time peak throughput result. Include recovery from failures and ease of maintenance in your decision.

Android Background Activity, Network Switching, and Battery Use

Battery Use Comes from the Entire Processing Path

Android battery use cannot be categorized by VMess, VLESS, or Trojan alone. Wireless wake-ups, connection keepalives, DNS lookups, background app requests, encryption, and verbose logs can all affect battery life. Sustained high throughput keeps the wireless module and processor active longer; frequent, small background requests can wake the device repeatedly and have a noticeable impact even with low total data use. For a fair protocol comparison, keep the proxied apps, remote service, network type, and screen state consistent. Otherwise, you may be measuring differences in usage rather than protocol design.

v2rayNG VPN mode receives traffic through the system VPN interface and passes it to the core. Per-app proxying can limit which apps enter that processing path, but whether “select apps” means proxy only those apps or bypass them depends on the current mode and the interface instructions. Reconnect after changing this setting and test by opening a target app. Proxy-only mode requires an app to use the local proxy endpoint explicitly; it does not automatically route every app through the client. A mismatch in usage mode is often mistaken for an unstable connection.

Adjust Background Restrictions to Match the Symptoms

If the connection stops as soon as you switch apps or turn off the screen, first check whether the system is stopping the client service, whether background activity is allowed, and whether another VPN app has replaced the current connection. Battery management settings and labels vary across Android devices; start with the app's battery and background permissions in its system settings. Do not disable every power-saving feature at once. First confirm whether the issue follows screen-off, lock-screen cleanup, or a specific power-saving mode, then make only the necessary client adjustments. If the network remains connected but one app stops receiving messages, check that app's own background restrictions too.

If the client is still running but the connection fails only after switching from Wi-Fi to mobile data, the underlying connection has probably been interrupted. An old connection cannot automatically continue across networks just because the protocol name is unchanged; the core and apps need to establish new sessions. Stop and restart the connection, then see if it recovers. If it does, check automatic reconnection, system network status, and how the remote server handles connections. Streaming or calling apps may also keep an old session, so reopen the relevant screen rather than relying only on the status-bar icon to confirm recovery.

Do Not Overdo Multiplexing, Keepalives, or DNS Changes

Keepalives can help detect dead connections or maintain sessions through some network equipment, but more frequent checks may also trigger additional wireless wake-ups. Unless idle connections are clearly dropping, there is no need to use an extremely short interval. Mux also depends on the protocol combination; a phone's sensitivity to power use does not mean shared connections will necessarily save battery. During sustained data transfer, avoiding a few handshakes may not change the main source of battery use. Repeated retries after connection failures can add further overhead. After making a change, observe real-world use instead of judging by whether the toggle is enabled.

Incorrect DNS settings can cause repeated lookups, timeouts, and connection retries, making the client appear busy without sending useful requests. First distinguish address resolution failures from security handshake failures. Then check whether the resolver is reachable, routing creates a loop, or domain rules trigger extra lookups. Enabling local DNS does not mean every app uses the same resolution path; an app's own encrypted DNS can affect the result too. For related issues, see the FAQ Troubleshooting section. Avoid changing DNS, the security layer, and routing all at once.

Compare battery use under the same conditions in two windows. First, check background stability with the screen off and little or no active traffic. Then observe heat and battery trends during a consistent workload. Record whether the connection is re-established, the network changes, or an app continues downloading; there is no need to claim a fixed battery percentage independent of the device. If idle use is unusually high, check wake-ups, retries, and logs. If the issue appears only under heavy load, focus on throughput, encryption, and device cooling. This produces findings that can guide practical settings.

Compatibility Across V2Fly, Xray, and Clients

Shared Origins Do Not Mean Identical Features

Project V is a useful starting point for understanding this ecosystem. V2Fly and Xray are distinct development paths within related core families. They share some concepts and historical foundations, such as inbound, outbound, routing, and DNS configuration, but evolve protocol support, transport implementations, and configuration fields independently. Do not assume everything is interchangeable just because both belong to the V2Ray ecosystem. A field supported by one core may be absent, named differently, or subject to different constraints in another. Check each field rather than copying an entire configuration.

v2rayNG primarily uses the Xray core for connections, while v2flyNG follows the V2Fly core path. v2rayN provides desktop graphical management and configuration for running the relevant cores. Consider the graphical client and the core actually selected together. An import option in the client does not guarantee that the active core can execute the imported configuration. For more on the ecosystem, see Project V, V2Fly, and Xray: Core Families Explained. A client name is not a complete list of its protocol capabilities.

Protocol, Configuration, and Interface Are Three Kinds of Compatibility

Protocol compatibility means both ends can exchange data using the same protocol. Configuration compatibility means the core can understand the configuration structure and fields. Interface compatibility means the client can enter, save, and pass those fields along. A failure in any one can prevent a connection. For example, the core may support a feature, but if the graphical importer drops a new parameter, the resulting configuration is incomplete. Conversely, retaining a raw string in the interface does not give the active core a feature it does not support. Troubleshooting should identify the stage where the failure occurs.

REALITY and the common VLESS Vision combination require particular attention to Xray capabilities and complete fields. Do not assume another core has an implementation with the same name and meaning that can be substituted directly. Protocols and transports on the V2Fly path should also be assessed based on their actual implementation; neither family should be treated as a complete subset of the other. Choosing a core is not an abstract contest over which is more advanced. The question is whether it can correctly run the combination required by the server and whether the client can maintain that configuration.

Short Configurations Still Depend on Runtime Context

The following Xray-style routing snippet illustrates what rules do; it is not a complete, standalone configuration. To use it, merge it into the appropriate full configuration, ensure outbounds tagged direct and block exist, and configure the corresponding rule resources. The first rule blocks a specified set of ad domains; the next two send private addresses and a specified domain set through the direct outbound. Rules are checked in order, and later rules cannot override an earlier match, so changing the order can change the result.

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

IPIfNonMatch means routing may try to resolve a domain and then check IP conditions if no domain rule matches. It does not mean “route every domain by IP first.” Missing rule resources, incorrect outbound tags, or unreachable DNS can all prevent the snippet from working as expected. Configuration compatibility depends on context—including resources, tags, and the resolution path—not just matching field names. For ordinary use, manage rules through the routing interface provided by the client. Use custom snippets only when you understand the generated structure.

Subscriptions, Shared Links, and Import Compatibility

A Subscription URL and Connection Credentials Are Different Things

A subscription link usually points to a collection of configurations; an individual shared link describes one connection. Pasting an individual shared link into a subscription URL field, or importing a subscription URL as a connection entry, can result in a failed fetch or no usable entries. Subscriptions may also contain access tokens whose permissions cover the entire collection, so treat them as sensitive. Do not post the original subscription URL while troubleshooting. Hide authentication query parameters, account identifiers, and remote passwords in logs and screenshots to avoid exposing access to all the connections.

Base64 is an encoding method, not an encryption protocol, and it does not protect subscription contents. A common subscription format combines multiple shared links into text and then encodes that text; the client must decode it before parsing each link. Some endpoints return a plain-text list of links or a structured configuration instead. If a server returns a webpage, login prompt, or error message, the client may not recognize it as a valid subscription. When an update fails, distinguish a request failure from an incompatible content format rather than assuming the Base64 encoding is broken.

The Same Protocol Can Use Different Sharing Formats

VMess shared links commonly contain encoded structured data; VLESS and Trojan often use URIs with query parameters; Shadowsocks links may use a different encoding for user information. These are client-to-client sharing conventions, not necessarily the same as core configuration formats. Even if the underlying protocol is supported, an importer may not fully recognize a link because its encoding, parameter names, or extension fields differ. Do not check only whether the link prefix is recognized. Verify that transport, security, and authentication fields appear in the correct places after import.

Paths, remarks, and query values in links may be percent-encoded. Manual copying can alter the original value through line breaks, spaces, automatic truncation by chat apps, or repeated decoding. Characters such as question marks, hash signs, and ampersands have structural meaning in URIs, particularly in paths; do not paste them all as ordinary text. Prefer the client's clipboard import or scan feature, and avoid repeated conversions in a text editor. After importing, compare what each field means rather than just checking whether the remark matches.

Update from the Subscription Group, Then Check the Result

In v2rayNG, add a group remark and subscription URL under “Subscription Group Settings,” save, then update the subscription. In v2rayN, manage the URL and update it through the subscription group menu. Menu names may change between client versions, but distinguish “save the subscription URL” from “fetch the subscription contents.” Saving successfully does not mean the remote contents have been downloaded. For detailed steps, see Subscription Import and Base64 Formats. For a first setup, follow the Getting Started guide from beginning to end.

After an update, check the entry's group, protocol, and key security parameters before connecting. If an entry worked before the update but fails afterward, check whether the remote service changed authentication, transport, or security settings instead of resetting the entire client. Updating a group may replace the entries it manages, and manual changes to subscription entries may be overwritten next time. To test a field temporarily, create a separate copy and label its purpose. Once verified, update the subscription source rather than maintaining two conflicting configurations indefinitely.

Format converters can only convert the fields they understand. If the source subscription includes a plugin, flow, REALITY parameters, or special transport settings that the target format cannot represent, the result may import while losing critical capabilities. Adding a conversion step also gives more parties access to sensitive configuration. Prefer a native compatible format from the service provider. If conversion is necessary, compare every field before and after; “conversion successful” does not prove end-to-end compatibility. A subscription distributes configuration; it cannot fix differences between server and core capabilities.

Choose by Use Case and Locate the Failure Stage

Check Requirements First, Then Compare the Experience

When you already have a server configuration, the server sets the initial options. If you receive VMess, start with a client that supports its authentication and transport combination. If you receive VLESS with REALITY, first confirm Xray support and all required fields. Compare configurations only when the server provides multiple complete options. For desktop, start with v2rayN and choose an installer for your operating system and processor architecture. For Android, start with v2rayNG; check v2flyNG when the configuration requires the V2Fly path. Installer details are on the download page; this guide does not replace choosing the right package.

Everyday browsing and office work place more emphasis on first response, certificate verification, and long-term stability. Complex encapsulation is usually unnecessary just to reduce theoretical overhead. For developer tools and terminals, first check whether the app follows the system proxy or needs proxy environment variables set separately. If a browser works but a terminal does not, the difference is often local access, not an unsuitable remote protocol. See How to Troubleshoot Browsers and Terminals Separately to narrow it down without repeatedly changing authentication or security settings on a working remote configuration.

For real-time communication, interactive apps, or workloads that rely on UDP, treat UDP support as a hard requirement. Check the client access method, then the core, remote forwarding, and routing, and finally test the actual workload. If the mobile network changes often, prioritize reconnection, background operation, and session recovery over peak short-term throughput. For long transfers, focus on sustained speed, processor load, and stability while keeping the remote location and test resource consistent. Otherwise, network and protocol differences cannot be separated.

Narrow Down the Problem One Stage at a Time

Stage one: check whether the configuration loads. If the log reports an unknown field, invalid method, or missing parameter, check client import and core compatibility before changing routing. Stage two: check whether the remote address resolves and the underlying connection can be established. For resolution failures, check DNS. For timeouts, check the address, port, network path, and remote listener. A reachable port only proves that something responded at the underlying endpoint; it does not mean proxy authentication succeeded. Fix the current stage before moving on to avoid masking the issue with unrelated changes.

Stage three: check the security handshake and authentication. For certificate errors, check the clock, server name, and certificate chain. For REALITY failures, check the public key, short ID, fingerprint, and name parameters. For authentication rejections, verify the UUID, password, or protocol-specific fields. Stage four: check whether requests reach the intended outbound. If the handshake completes but the destination does not load, check the routing match, DNS result, outbound tag, and destination service. If only certain apps fail, check the system proxy, per-app proxy settings, and the apps' own proxy configuration. Do not classify a local app issue as a failure of the entire connection.

Turn Test Results into Maintenance Notes

For each candidate configuration, record its purpose, required fields, client and core, test network, and observations. There is no need to record publicly visible account secrets. Be specific about whether the use case is browsing, developer tools, or real-time communication; note whether the first response is slow, the connection drops in the background, or only UDP fails. This is more useful than saying “this protocol doesn't work,” and makes it easier to rebuild a correct setup on another device. After updating the client or subscription, retest the baseline workload and compare changes one layer at a time instead of using a full reset as a substitute for troubleshooting.

A good choice meets three conditions: the server's configuration is fully supported, security verification remains correct, and the actual workload runs reliably on the target device. Once those requirements are met, weigh resource use, maintenance effort, and performance during network changes. Protocol names cannot replace these checks, and there is no single winner for every device and workload. For quick answers to common symptoms, see the FAQ. To repeat the import, connection, and verification process, return to Getting Started and follow the steps.