Choosing a V2Ray protocol
and checking core compatibility

01 / Connection model

Protocol, transport, and security layers

A connection depends on several groups of settings

In v2rayN, the protocol type is only one part of a server entry. The address and port specify where to connect; a user ID or password handles authentication; transport settings define how data is carried; and TLS or REALITY handles the relevant security handshake. Routing rules decide which requests use the connection. Keeping these layers separate explains why two entries labeled VLESS may not work if you swap their other fields.

App requests typically enter through the client's local inbound, then the core selects an outbound based on routing rules. The outbound connects to the remote server, which then reaches the destination. The graphical client organizes settings, but the core establishes the connection. The system proxy or a virtual network interface directs app requests to the inbound. That means “the client is running,” “the local proxy port is listening,” “the remote handshake succeeded,” and “the destination is reachable” are separate stages. A single connection icon cannot verify them all.

Server address, server name, and request hostname

The server address may be a domain name or an address specified by your provider. The TLS server name is generally used for certificate name validation and server name indication (SNI). HTTP-based transports may also have a Host or request-host field. These values may be the same or differ depending on the server setup. Use the values supplied for each field rather than replacing every domain field in the editor with the server address. Do not copy unrelated names from someone else's screenshot.

Transport is not a speed setting you can change at will. Raw TCP, WebSocket, and gRPC each require a matching server endpoint; the path, service name, and forwarding rules on any reverse proxy must also agree. A WebSocket path is not just any website directory, and a gRPC service name is not a remark. If the remote server accepts only one transport, switching the local setting will usually make the handshake fail, not negotiate a different connection automatically.

Save the original settings before changing anything

After importing a complete connection, keep the original entry and make a copy for testing. Note each change in the remark. Change one category at a time—for example, routing rules or the server name. If you change the core, transport, and DNS together, even a successful connection will not tell you what fixed the issue, leaving you to guess again next time. Subscription updates may overwrite edits, so keep long-term local changes in a separately managed entry or configuration.

Use the same layer-by-layer approach when reading logs. For a name resolution failure, check address resolution first. For a refused connection, check the remote port and service status. For a certificate name mismatch, check the system clock and server name. If the handshake completes but access still fails, look at destination resolution and routing. Similar messages in the interface can point to entirely different stages. Match the first meaningful error in the log to the time of your last action; this narrows things down more effectively than flipping every switch.

02 / Authentication and encryption

VMess and VLESS: design trade-offs

VMess: authentication and encryption built into the protocol

VMess is an older proxy protocol in the Project V ecosystem. Its design includes user authentication and data protection within the protocol itself. The client needs the remote address and a matching user ID, and must format requests in a way the server accepts. Modern deployments typically use AEAD authentication; older entries may retain historical fields such as an additional ID count. Do not infer what these fields mean from their names or enter arbitrary values in an attempt to “improve compatibility.”

VMess authentication depends on time, so a significantly inaccurate system clock can cause the handshake to fail. To troubleshoot, enable automatic time synchronization in the operating system, check that the displayed time zone is correct, and try connecting again. Changing the client remark, restarting the browser, or switching routes will not fix an authentication time issue. If an old subscription continues to require outdated parameters, ask the provider which format is currently supported instead of relying on an old client indefinitely.

VMess security settings must match the core's capabilities and the server's requirements. Automatic selection is usually a better starting point than forcing a specific algorithm; hardware acceleration on the processor can also affect the actual cost of different algorithms. Built-in data protection does not mean outer TLS is never useful: some deployments use a TLS endpoint and reverse proxy to serve connections. Whether an additional security layer is needed depends on the full deployment.

VLESS: a lean protocol layer with security handled outside it

VLESS keeps the proxy protocol layer lean, retaining necessary information such as user identification while leaving transport security to an outer layer. In common configurations, the encryption field is none. This means VLESS itself does not provide that data encryption; it does not mean the entire connection is unprotected. To assess security, check whether the outer layer uses TLS or REALITY and whether the authentication and certificate settings are correct.

Conversely, a user ID is not a substitute for an encryption layer. If the deployment requires TLS, disabling the security layer to troubleshoot will usually make the server reject the connection. Even if another endpoint accepts plaintext, that does not give the connection the same security properties. Choose VLESS only when you understand the complete configuration provided by the server—not simply to get “fewer fields” or as a drop-in replacement for VMess.

In a VLESS configuration, flow refers to a specific flow-control method, not ordinary traffic routing. Some flow options require a particular core, transport, and security layer; do not copy a value from one connection to every VLESS entry. An input field in the client only means the interface can collect that value. Whether the current core and server support the combination is a separate question.

Choose a protocol based on what the server supports

If your existing VMess service works, there is no need to switch to VLESS just because the name seems newer. The two protocols use different server authentication, and changing the protocol type locally does not migrate a connection. A proper migration requires the server to provide a matching endpoint. Import the new connection details, test access to your destination and any required UDP apps, and only then decide whether to replace the old entry. Keeping a known-working configuration also helps distinguish server-side changes from local ones.

If the server provides complete configurations for both protocols, compare them on the same device and network, as close together in time as possible. Keep routing, destination, and test tasks consistent, then observe connection stability, sustained transfers, and reconnection after sleep. Do not attribute results to the protocol based on a single speed test: the exit route, server load, transport encapsulation, and local DNS can have a much greater effect.

03 / Different security models

Trojan, Shadowsocks, and REALITY

Trojan: proxy connections over TLS

Common Trojan deployments use a TLS connection, with password authentication and proxy requests handled inside the protected channel. Its configuration can be more straightforward than combinations with multiple encapsulation layers, but entering a password alone is not enough. The server address, port, server name, and certificate validation are all important. If the certificate's domain does not match the name you entered, the client should reject the connection; do not treat a validation failure as a harmless warning to ignore.

Trojan handshake performance depends on TLS negotiation, the remote server's response, and network quality. Using TLS does not automatically make it slower to connect. Session resumption can reduce the cost of repeat handshakes in some cases, depending on the implementation and connection lifecycle. When choosing a setup, consider certificate maintenance, password rotation, and client support. For certificate errors, see Troubleshooting TLS Handshake and Certificate Errors.

Shadowsocks: the method determines compatibility

Often abbreviated as SS, Shadowsocks uses a pre-shared key to establish an encrypted proxy channel. Over time, different methods have developed with different authentication, key handling, and data formats. Legacy methods, AEAD methods, and newer method families are not automatically compatible just because they are all SS. Preserve the exact method name and password format when importing. In particular, do not treat a configuration that requires a specific key length as an arbitrary password field.

SS has relatively few fields, making it a useful example for understanding encryption methods and client compatibility. If the connection details also include plugin parameters, that introduces another compatibility requirement. A core that supports the base SS protocol does not necessarily mean the graphical client can launch every plugin or that a subscription converter will preserve plugin options. If import succeeds but the handshake fails, check whether any extra requirements were lost, then confirm the current client can support them.

REALITY: a security-layer option, not a standalone proxy type

REALITY often appears with VLESS, but it does not replace all of VLESS's proxy functionality. Think of VLESS as the layer that defines proxy requests and REALITY as a specific security handshake. The client typically needs a server name, public key, and short ID; some implementations also offer fingerprint settings. These values are determined by the server configuration. They cannot be derived from the destination website's certificate or another connection.

The client stores the public key supplied by the server, while the server holds the corresponding private key. Do not confuse their roles. If the subscription already includes a public key, preserve it as provided; generating a new one locally will not make the remote server accept it. The short ID must also match a value allowed by the server, though whether it can be left blank depends on the configuration. Use the server name specified by the provider rather than substituting a domain you see in the address bar.

Check REALITY support against the core implementation. Do not assume v2rayN and v2flyNG offer identical options just because they belong to related ecosystems. For REALITY, specific flow settings, and associated transport combinations, first check the requirements of the Xray implementation, then confirm that the graphical client generates all required fields. Repeatedly importing the same link will not add underlying capabilities that the interface lacks.

These three names are not directly comparable options in the same category. Compare complete connection setups, then consider maintenance, device overhead, and availability on the remote server. If the configuration details are incomplete, get clear information before looking for a supposedly universal best setting. The client cannot infer the server's intent from missing fields.

04 / Implementations and configuration

How V2Fly, Xray, and clients fit together

The core handles connections; the client organizes settings

Project V provides useful context for understanding this ecosystem. V2Fly continues the maintenance and development of V2Ray-related cores, while Xray has developed its own feature roadmap from related technical foundations. They share concepts but also differ in implementation and fields. A core is not just another name for the graphical interface: one client may call different cores, and a core's low-level options may not all appear as interface toggles.

v2rayN is the recommended desktop client for Windows, macOS, and Linux. Find installation options on the client page. It handles server lists, subscription groups, system proxy settings, and configuration generation. Available cores and their features depend on the builds and settings the client actually provides. Do not assume every installer includes the same components, or rename an incompatible program to make it look like a different core.

For Android, v2rayNG is the primary choice and uses the Xray core. v2flyNG uses the V2Fly core and can be an alternative for configurations that need it. The apps may share similar concepts, but their fields and defaults can differ. Choose based on the requirements of your existing service, then consider which interface you prefer. For features such as REALITY, check the corresponding implementation rather than assuming compatibility based on similar app names.

Similar configuration structures do not mean fields are interchangeable

Both core families commonly use concepts such as inbounds, outbounds, routing, and DNS, and some of their basic structures look very similar. But transport names, accepted fields, flow-control methods, and support for new features are not guaranteed to match. If a JSON file passes syntax validation, that only confirms its formatting—such as brackets and strings—is valid. It does not prove the current core understands every field; some errors appear only at startup or when connecting.

A graphical client often reads a subscription, saves entries in its internal server model, then generates a configuration for the core. Compatibility problems can occur at any step: the link parser may not recognize a parameter, the internal model may not preserve an extension, or the core may reject the generated configuration. First check the values in the editor, then review startup errors; do not blame every problem on the remote server. For configuration sections, see Understanding JSON Configuration Structure.

What to verify when switching cores

Before switching, record the current protocol, transport, security layer, flow, DNS, and routing settings, and keep a known-working entry. After switching, run the client's configuration check or try starting it. Confirm there are no unknown fields, missing components, or port conflicts before testing the remote connection. If you rely only on whether a browser page loads, a local traffic-capture failure can easily be mistaken for an incompatible remote protocol.

Even for ordinary connections, check for changes in defaults during migration. Domain matching policies, sniffing, UDP forwarding, and connection multiplexing may not appear in the server editor, yet can affect requests. Do not enable every advanced option just to imitate an old setup. Start with the minimum required configuration, verify the basic connection, then restore only the rules you actually need. A clear separation of settings—not a longer list of toggles—is what makes a migration stable.

Updating a core and updating a subscription solve different problems. The first changes local implementation capabilities; the second changes remote connection details. If a connection works after an update, that does not mean the two updates are interchangeable. When a regression occurs, record whether the last change was to the client, core, or subscription, and note when the error happened. Before sharing troubleshooting details, remove authentication data and subscription URLs; keep only necessary field names and error types.

05 / Performance

Connection speed, resource use, and battery life

Measure connection setup and sustained transfers separately

“Speed” includes at least connection setup time, time to first response, sustained throughput, and long-term stability. DNS lookup, network round trips to the server, the security handshake, and the connection from the server to the destination all affect the first response. Sustained transfers depend more on link bandwidth, congestion control, server load, and device processing. A setup that opens a short page quickly is not necessarily faster for large downloads or more power-efficient when a connection stays active in the background.

A lean protocol layer can reduce some processing work, but cannot eliminate network distance or packet loss. Transports such as WebSocket and gRPC add encapsulation, but may also fit existing server infrastructure. Whether that extra overhead becomes a bottleneck depends on the environment. Do not declare a setup slow based only on the number of layers, or treat results from servers on different routes as a controlled protocol comparison.

The resource cost of encryption depends on the processor, system libraries, and core implementation. A device with the right hardware acceleration may handle one algorithm with less overhead than another device. Processor load may be more noticeable during sustained high-speed transfers; ordinary web browsing may mostly wait on the network. When comparing, monitor device heat and whether tasks complete as expected so you do not mistake normal short-term load for a client problem.

Connection multiplexing does not make every task faster

Connection multiplexing lets multiple logical requests share an underlying connection. It may reduce the cost of repeatedly establishing connections, but multiple requests can also be affected by congestion or interruptions on that connection. Its value depends on the workload, transport, and implementation. The best setting may differ for a few short requests versus sustained heavy traffic. If some apps stall after enabling it, disable multiplexing for a comparison instead of adding more advanced options.

Test UDP workloads separately. A working webpage only proves that the relevant TCP or HTTP requests completed; it does not show that voice, real-time interaction, or other UDP apps are being forwarded correctly. The client, protocol implementation, server, and routing can all impose limitations. Some networks also handle UDP differently from TCP, so test with the apps you actually need rather than treating a single web speed test as a complete compatibility check.

On mobile, battery use often depends more on traffic handling and reconnects

On Android, battery life is not determined by the protocol name alone. The traffic handled by the virtual network interface, background app activity, wireless signal strength, keepalives, and reconnect frequency all affect power use. When a device switches between mobile data and Wi-Fi, existing connections may need to be re-established. Continuous background requests can make retries keep the wireless radio active longer. There is rarely enough evidence to attribute all extra battery use to TLS or REALITY.

System battery optimization involves trade-offs. Restricting background activity too aggressively can pause the client and trigger repeated reconnects when it resumes. Allowing unrestricted background activity may let other apps send continuous traffic through the client. Start by reviewing the app's battery usage, then check whether disconnect times line up with screen-off or network changes. Disabling every system optimization to fix one disconnection makes it harder to find the cause and can affect battery life in other apps.

For a repeatable comparison, keep two configurations and alternate between them on the same device and network, using the same tasks. Avoid comparing device heat while charging. Record whether the first request succeeds, whether sustained tasks pause, whether the connection recovers after the screen turns off, and what the system battery log shows. Only a consistent trend across multiple tests is worth acting on. A one-off peak measured at a different time or through a different exit route is not a sound basis for ranking protocols.

06 / Sharing and migration

Subscription formats, share links, and migration

A subscription delivers configuration; it is not a protocol

A subscription URL usually returns a set of connection details. The client identifies the content, parses the entries, and adds them to a group. The response might contain share links, encoded text, or a structured configuration. The same URL may return different content depending on request details. So “the subscription opens in a browser” only means a response was received. It does not prove that the format suits the current client or that the core supports every protocol it contains.

Share links also follow their own conventions. VMess links commonly contain encoded structured data; VLESS, Trojan, and SS links usually use URIs to carry authentication details and query parameters. Providers may also use extension fields. Some characters in a link need percent-encoding, and remarks or query parameters may contain non-Latin text. Dropping the end of a link, adding a line break, or having a messaging app truncate it can make import fail.

Base64 is an encoding format, not encryption. Subscription and share-link content may contain usable authentication details even if it is not readable at a glance. Do not paste a full subscription URL into a public forum or send it to an unfamiliar conversion service. To troubleshoot formatting, check the content type locally and remove authentication fields before sharing. Hiding only the remark while leaving the complete connection details intact does not reduce the risk of exposure.

After import, verify that every field is present

Open the imported entry and check the protocol, address, port, user authentication, transport, path, and security settings one by one. For combinations such as REALITY, verify the public key and short ID; for VLESS, check any required flow. Seeing an entry in the list only means the parser created it, not that every extension parameter was preserved. A correct remark does not make an entry complete if key fields are missing.

When moving between clients, use a share format both explicitly support. Import a small number of entries first, verify them, then move the rest of the groups. Copying an app's data directory directly may carry over platform-specific paths, local ports, and settings, so it is not a universal migration method. Desktop system proxy settings do not automatically map to Android traffic handling. Connection details may transfer, but local traffic handling and permissions still need to be checked.

Subscription updates usually regenerate or merge entries from remote details; whether manual edits survive depends on how the client manages them. If you want to keep changes to remarks, routing associations, or connection fields, find out how updates handle existing entries first. Store test configurations in a separate group and give the original subscription a clear name. This helps prevent a future update from making it look as though the server changed every setting.

If the list is empty, check the response and parsing separately

If an update fails, first check that the URL is complete and still valid, and that the current network can reach it. If a response arrives, check whether it contains connection details, a login page, or plain error text. A successful request and a successful parse are two different things; repeatedly encoding webpage content will not turn it into a valid subscription. For a detailed checklist, see Troubleshooting Subscription Updates and Empty Server Lists.

Some services choose a subscription format based on the User-Agent or request parameters. Change these settings only when the provider specifically instructs you to; do not impersonate another client just to experiment. Also check whether updates go through an existing proxy. Trying to update a connection using the same connection before it is established can create a loop. First ensure at least one update path works, then verify the returned format, and finally troubleshoot compatibility for individual entries.

07 / Where requests go

How routing rules and DNS work together

Routing selects an outbound; it does not fix handshakes

Routing directs requests to an outbound based on domains, addresses, ports, or other conditions. It takes effect while the core handles a request; it cannot replace remote authentication or fix a certificate name error. If no requests work, first check local traffic handling and whether the proxy outbound is available. If only certain domains fail, inspect the matching rules and DNS results. Separating connection failures from routing failures helps avoid changes that cannot solve the problem.

Rules are commonly matched in order. A broad condition matched earlier can prevent a more specific rule later in the list from taking effect. The default outbound matters too: in common configuration models, requests that match no rule may use the default route, as defined in the generated configuration. Do not check only the rule names; make sure each referenced outbound tag exists and that its spelling and capitalization match exactly.

This routing snippet shows how to send private addresses directly. It is not a complete, standalone client configuration; merge it with the other sections and make sure a direct outbound tagged direct already exists, along with the required address-rule data. If the graphical client has already generated these settings, do not append the snippet again. Prefer to express the same intent through the routing settings in the interface.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Where resolution happens affects which rules can match

An app may pass a domain name to the proxy, or resolve it locally and submit only an address. In the first case, the core may be able to match a rule directly by domain; in the second, only the address may remain. System proxy settings, an app's own proxy, and traffic handled through a virtual network interface do not preserve request information in exactly the same way. So a domain rule working with one traffic-handling method but not another does not necessarily mean the rule is written incorrectly.

AsIs generally means not resolving a domain to an address just to match routing rules. It does not mean DNS is no longer needed anywhere in the connection. Other domain strategies may trigger resolution under certain conditions to try matching address rules. Changing the strategy affects both rule matching and resolution overhead; resolving more aggressively is not automatically more accurate. Decide whether you want to route by domain or by address first, then choose the behavior that fits.

Core DNS, operating system DNS, encrypted DNS in a browser, and resolution of remote destinations may all follow different paths. Changing one setting may not affect every request. If the browser behaves differently from other apps, check whether it resolves names independently and whether those apps actually use the client. A responding DNS server does not prove the traffic is routed correctly; even after a successful lookup, a request may use an unexpected outbound.

System proxy, sniffing, and local network access

Automatic system proxy configuration mainly affects apps that follow the system settings; it does not capture all traffic. Modes such as global proxy, bypass LAN, and direct may also be presets provided by the client, so check the rules they actually generate. For a local printer, shared folder, or admin page, first confirm how private addresses are handled. Then add explicit rules for internal domains if needed.

Traffic sniffing can try to extract domain names and other information from requests to help with routing, but it cannot identify every protocol or replace the full context available at the application layer. Some settings may also affect how destination addresses are handled, so enable them for a specific purpose. When troubleshooting one site, record whether the app submitted a domain or address, which rule matched, and which outbound was used. That is more informative than changing DNS and routing modes at the same time.

Include IPv6 in your routing checks. After the system receives address records, a connection may use a different address family; if your rules or support cover only one path, access may appear to work intermittently. Do not treat disabling an address family as a universal fix. First confirm that your local network, server, and destination all support the chosen path. For specific interface steps, see the DNS setup guide.

08 / Choosing and verifying a setup

Choose a client and protocol for your use case

Existing service: keep the full configuration and check compatibility first

If your existing service is stable, the best first step is usually to keep the complete protocol configuration it provides rather than switching protocols. For desktop, start with v2rayN and choose an installer for your operating system and processor architecture. For Windows Desktop and the classic WPF interface, see the Windows installation and setup guide. The interface is not a measure of remote protocol security; actual capabilities depend on the core in use and the configuration it generates.

For Android, start with v2rayNG. If your service relies on specific V2Fly capabilities, consider v2flyNG. For the initial test, import one connection with complete details, verify basic access, then enable the routing and traffic-handling scope you need. If you migrate all subscriptions, rules, and background settings at once, it will be difficult to tell whether a failure comes from parsing, core compatibility, or system permissions.

If you have several options, list your constraints before comparing

If the server offers VMess, VLESS, Trojan, or SS, list the requirements first: does the device support the required core, do you need UDP, does the setup depend on a particular transport endpoint, and can you maintain its certificates or keys? Once you know which options meet those requirements, compare connection stability and how they perform for your tasks. Evaluate REALITY as part of a complete security-layer setup, not as a standalone option in the protocol menu that can replace any connection.

When using multiple devices, do not assume every device needs the same configuration. A service can provide different connection details for different clients. Copying new desktop fields into a different core may break compatibility; removing necessary settings to standardize names may compromise security. Manage shared goals and routing intent, not identical text in every connection editor.

Long-running mobile and desktop use have different priorities

For long-running desktop use, check recovery from system sleep, network changes, port conflicts, and whether apps follow the system proxy. On Android, also check background restrictions, which apps are handled by the client, and battery usage. If macOS blocks the app or requests permissions during first-time setup, see Installation and Network Permission Troubleshooting. Handle platform permission issues at the system level; changing a user ID or protocol type will not fix them.

For short web sessions, connection setup and first response matter most. For sustained transfers, watch for pauses, reconnects, and device load while the task runs. Real-time apps also need a separate UDP test. Different tasks have different priorities, so this guide does not offer a fixed speed ranking without regard to network conditions. Results you can explain and reproduce are more useful for long-term decisions than a recommendation with no test details.

When something fails, go back to the relevant stage instead of changing settings at random

If the client will not start, check configuration validation, the runtime environment, and local ports. If it starts but cannot complete a handshake, check the remote address, authentication, transport, and security layer. If the handshake succeeds but some apps fail, check traffic handling, UDP, DNS, and routing. If the problem began after a subscription update, compare key fields before and after. If it happens only after the screen turns off, check background restrictions and reconnect logs first.

Keep some conditions fixed during every troubleshooting attempt: use the same device, network, destination, or connection for at least part of the test, and change only one variable at a time. Collect logs around one specific action so old errors are not confused with a current successful connection. You can share the error category and a sanitized view of the fields, but never share complete authentication details. This makes the findings useful for reproducing the issue rather than just a lucky fix.

The final configuration should make four things clear: which protocol combination it uses, why the current core supports it, which apps route through the client, and where to look for evidence if something goes wrong. For your first setup, follow the getting started guide. This page explains the boundaries behind that process so you can make informed changes when needed.