V2Ray Protocol Guide: Protocols, Transports and Core Selection

1. Separate the protocol, transport, security layer and core

“Protocol” in a client is not a single switch

In the server editor for v2rayN, v2rayNG or v2flyNG, a connection usually combines a protocol type, address, port, user credentials, transport, security layer and routing outbound. The protocol type defines how the client authenticates with the server and structures data frames; the transport determines whether those frames travel over TCP, WebSocket, gRPC or another carrier; TLS or REALITY handles the handshake, server authentication and link encryption; and the core turns these fields into an executable configuration. Mixing these concepts together can lead to incorrect conclusions such as “this protocol is always faster” or “changing the type alone will make it connect.”

For example, VLESS can run over plain TCP, WebSocket or gRPC, and can be combined with TLS or REALITY. Two nodes both labeled VLESS may behave completely differently if their transport, congestion, certificate handshake or server implementation differs. REALITY is not a proxy protocol on the same level as VLESS; it is closer to a transport-security scheme implemented by Xray. A common combination is VLESS, TCP, REALITY and XTLS Vision. When choosing a server, treat the full combination as one configuration rather than looking only at the vless:// prefix.

Confirm these four constraints first

First, confirm what the server already provides. A client cannot unilaterally change VMess to VLESS, nor can it enable REALITY when the server has not configured it. Second, check whether the core recognizes the relevant fields. v2rayNG primarily runs on the Xray core, while v2flyNG targets the V2Fly core; v2rayN is a desktop GUI client whose common configurations run on the Xray core. Basic VMess, VLESS, Trojan and Shadowsocks fields have broad ecosystem coverage, but extensions such as XTLS Vision and REALITY require a compatible core.

Third, identify the configuration source. A subscription link carries the protocol, address, port and transport parameters together, so it should normally be imported in full instead of copying only the address and port and re-entering the rest. Fourth, consider the environment. Desktop clients can more readily handle TUN, complex routing and multiple connection processes; mobile clients place more emphasis on idle power use, reconnection after network changes and background behavior. Differences between platforms often come from the system network stack, TUN implementation and connection-keepalive strategy—not the protocol name itself.

Do not replace the full diagnosis with a single label

The sensible order is to confirm that the server combination matches the client core, then check that the share link or subscription is complete, and only afterward compare performance and resource use. If the connection succeeds but webpages remain inaccessible, continue with the system proxy, TUN, DNS and routing rules. If fields disappear during import, fix the subscription format first instead of repeatedly toggling the system proxy. Desktop v2rayN packages and Android packages for v2rayNG and v2flyNG can be selected by platform on the download packages page; the Getting Started guide covers the basic steps after installation.

2. VMess: A full-session protocol and compatibility baseline

Background and design priorities

VMess is one of the core protocols that emerged early in the Project V ecosystem. It organizes user identity, time information, request targets and data transfer in its own protocol structure, with the server identifying connections by user ID. Older configurations often include alterId, which was once used for an additional identity mechanism; modern implementations generally use AEAD, so alterId is normally zero in current configurations. When importing an older subscription, do not mechanically carry a large alterId into a new server; follow the server’s actual configuration.

VMess’s strength is not one extreme performance metric, but its long ecosystem history, mature field definitions and broad support across clients and subscription converters. If an existing VMess configuration is stable, there is no need to migrate merely because a newer protocol name appears. It remains a useful compatibility baseline for moving between clients, especially when the connection uses common combinations such as TCP, WebSocket and TLS. V2Fly and Xray generally handle its basic configuration.

Authentication, time and encryption fields

VMess requests contain time-dependent authentication data. If the client and server clocks differ too much, authentication may fail even when the address, port and user ID are all correct. During troubleshooting, first confirm that the device uses automatic system time and the correct time zone, then check the server clock. This concerns clock drift, not network latency. Reimporting the same link, switching to global proxy mode or reinstalling the client cannot fix a significant time mismatch.

A client may display VMess security options such as auto, aes-128-gcm, chacha20-poly1305 or none. These fields describe processing at the VMess data layer and do not replace outer TLS. With auto, the core selects an appropriate method based on its implementation and the device’s capabilities; manually pin an algorithm only when the server requires it or when diagnosing compatibility. When outer TLS is enabled, the server name, certificate domain and transport path must still match independently.

Common VMess configuration mistakes

The first mistake is treating the user ID like an ordinary password. A VMess ID is usually a UUID; missing characters, leading or trailing spaces, or pasting it into the wrong user field will cause authentication failure. The second is confusing the WebSocket path with Host: the path is the HTTP request path, while Host belongs to the request headers or the TLS server-name context. They may be identical or different and must follow the original configuration. The third is keeping only the prominent fields from a share link and losing transport parameters. A client-recognized vmess:// link does not guarantee that the current converter parsed every field correctly.

The fourth mistake concerns the TLS toggle. If the server requires TLS, disabling it on the client usually prevents a correct handshake; if the server is not configured for TLS, enabling it on the client does not create a secure connection automatically. The fifth is continuing to use obsolete fields after upgrading the core. The core may warn about deprecated fields or refuse to load them, while the GUI may show only “startup failed.” Check field paths such as outbound, streamSettings or security in the logs instead of relying only on the tray status.

When to keep it and when to migrate

When an existing VMess connection is stable, the server is clearly maintained and subscription updates work normally, keeping it is usually easier than migrating without a clear goal. Reasons to migrate generally include a server-side configuration change, a required core feature or an explicit protocol change by the subscription provider. To use REALITY or XTLS Vision, import the complete new VLESS configuration; do not copy the VMess node’s address and ID, change only the protocol dropdown and expect it to work. Keep the old node for a while after migration so you can distinguish protocol configuration issues from local DNS or routing problems.

3. VLESS and REALITY: A lightweight authentication and modern security-layer combination

Why VLESS uses a lean design

VLESS focuses on lightweight identity authentication and request forwarding rather than duplicating content encryption inside the protocol. The encryption value commonly shown in clients is none. This does not mean the complete link is necessarily unencrypted; it means that TLS, REALITY or another outer layer provides the security. This approach avoids redundant processing between the protocol and transport-security layers and makes VLESS easier to combine with XTLS flow control. Be precise: VLESS over TCP with no security layer has very different link properties from VLESS with TLS or REALITY.

VLESS credentials are also usually UUIDs. Unlike VMess, VLESS does not rely on VMess’s time-based authentication structure and has no alterId. A server may assign extensions such as flow, which the client must match exactly. xtls-rprx-vision is a common XTLS Vision flow-control value from the Xray ecosystem; not every core using the VLESS name supports it. If flow is empty after import but the original link clearly includes Vision, check the client core and the subscription parsing process first.

The configuration problem REALITY addresses

REALITY is Xray’s transport-security implementation. It commonly uses information related to a target site during the handshake and establishes a corresponding relationship through the server’s private key and the client’s public key. Common client fields include the server name, fingerprint, public key, Short ID and SpiderX; the server stores the matching private key and permitted server names. The client needs only the public key; the server’s private key must never be placed in a subscription or share link. A mismatch in the public key, Short ID or server name can cause the connection to close quickly.

The server name is often shown in a client as SNI or serverName and participates in handshake selection and validation. Fingerprint fields commonly contain browser-fingerprint identifiers such as chrome, which specify handshake characteristics; they are not the device’s browser version and do not require that browser to be running. Short ID is one of the values permitted by the server, and its length and content must match the server settings. SpiderX commonly defaults to a slash and controls REALITY-related behavior; unless the server specifies otherwise, do not add a complex path based on guesswork.

XTLS Vision and the forwarding path

One goal of XTLS Vision is to identify data paths suitable for direct forwarding, reducing unnecessary re-wrapping and memory copies. When the payload already has its own security layer, suitable flow control can lower additional processing costs, especially for sustained throughput. Vision’s benefits still depend on the core, server, transport combination and actual data type. Short-lived page loads are driven mainly by handshakes, DNS and round-trip time, so enabling flow alone cannot eliminate every wait.

Vision is usually paired with TCP. Combining it arbitrarily with unsupported transports may prevent the configuration from loading or cause the server to reject it. If the client editor offers separate protocol, transport, security and flow options, enter the complete server-provided combination. The correct sequence is to confirm protocol = vless, then the transport, then security = reality, and finally flow, public key, server name, fingerprint and Short ID.

{
  "protocol": "vless",
  "user": {
    "id": "00000000-0000-4000-8000-000000000000",
    "encryption": "none",
    "flow": "xtls-rprx-vision"
  },
  "transport": {
    "network": "tcp",
    "security": "reality",
    "serverName": "www.example.com",
    "fingerprint": "chrome"
  }
}

The snippet above illustrates field hierarchy and uses a reserved example domain and sample user ID; it cannot connect to a real server. A working configuration must also include the server address, port, REALITY public key and Short ID. Its purpose is to show whether fields remain in the correct places after subscription conversion: VLESS user fields, TCP transport fields and REALITY security fields cannot substitute for one another.

What to check when import fails

First confirm that the current client is actually using an Xray core that supports REALITY and Vision. Then verify that security=reality and flow=xtls-rprx-vision were not lost during subscription conversion. Next check pbk or publicKey, sid or shortId, sni and fp. Different share-link formats may use abbreviations, but the imported editor should restore the corresponding configuration fields. If the client saves the node but reports an unknown field at startup, the core likely lacks the required capability. If the core starts normally but the handshake fails, check the public key, server name and Short ID first.

4. Trojan and Shadowsocks: Two different lean approaches

Trojan’s TLS requirement

Trojan uses a password for user authentication and treats standard TLS as a core part of its connection design. A typical client configuration includes the server address, port, password, server name and certificate-validation options. Its field set is relatively straightforward, but fewer fields does not mean TLS can be ignored. The server name must correspond to the deployment, because certificate-name validation depends on it; changing the server name directly to an IP may cause a hostname mismatch. Unless you are working in a controlled diagnostic environment, do not disable certificate verification as a long-term fix.

The main difference between Trojan and VLESS is not limited to their credentials. Trojan uses a password, while VLESS commonly uses a UUID; ordinary Trojan connections depend closely on TLS, whereas VLESS can be combined with different security layers. Both can work with some transports, but the exact support range depends on the server and core. When you receive a trojan:// link, preserve the password, SNI, transport type, Host and path in full rather than extracting only the most visible server address.

Common Trojan failure boundaries

If failure occurs during the TLS handshake, first check the device time, server name, certificate validity and whether the network can reach the target port. If TLS succeeds but authentication fails, verify the password. Passwords are case-sensitive, and special characters in the link must be URL-encoded correctly. Manual copying can turn plus signs, percent signs or hash marks into URL syntax, making the imported password differ from the original. The safest approach is to import the complete share link directly in the client and then verify each field in the editor.

Transports such as WebSocket or gRPC add parameters including a path, service name and Host. In this case, “Trojan connects” means that Trojan authentication, the TLS handshake and the transport parameters are all correct. An HTTP status error in the log points to the transport path; a certificate-name error points to the server name; an authentication rejection points to the password. Checking each stage is more effective than repeatedly changing several switches.

Shadowsocks encryption methods and passwords

Shadowsocks uses a lean encrypted-proxy structure, so the client and server must use exactly the same encryption method and password. Common AEAD methods include aes-128-gcm, aes-256-gcm and chacha20-poly1305. Results may vary between desktop processors with hardware acceleration and mobile processors, but on modern devices the difference is often outweighed by network quality, connection count and server load. Follow the server configuration first; do not change the algorithm unilaterally on the client.

The Shadowsocks 2022 family improves key and session handling, but its password or key format differs from legacy AEAD methods, and not every core or subscription parser supports it fully. When a method name contains 2022, confirm core support first, then verify that the imported key is complete. Changing a 2022 method to a traditional AEAD name will not create a compatible connection because the server is using different protocol details.

When to choose either protocol

When the server offers a standard Trojan configuration and manages its certificate and server name clearly, Trojan’s configuration model is easy to understand and troubleshoot in two stages: TLS and authentication. When the server offers a simple Shadowsocks configuration and the client explicitly supports the encryption method, Shadowsocks has fewer fields and suits scenarios that do not need advanced flow-control extensions. Neither has an absolute advantage outside its environment. Consider server maintenance, the client core, whether the subscription can express every field, and whether the device needs TUN or complex routing.

v2rayN, v2rayNG and v2flyNG may all display these protocol options, but a visible option does not prove that the current core supports every extension combination. Pay particular attention to Shadowsocks plugin parameters, 2022 methods and special Trojan transports; the executed core’s configuration result is authoritative. For subscription nodes, inspect the original type after the subscription update and do not overwrite fields with a similarly named node used as a template.

5. Connection speed, resource use and mobile power consumption

Speed is determined by multiple links

The “speed” users perceive includes DNS lookup, client-to-server connection setup, the TLS or REALITY handshake, the server’s connection to the destination, time to first byte and sustained throughput. The protocol affects only part of this chain. Short web requests are more sensitive to DNS, handshake round trips and connection reuse; large transfers reveal more about encryption, memory copying, congestion control and the server’s egress capacity. A single node speed test cannot reliably attribute differences to VMess, VLESS or Trojan.

For protocol comparisons, use the same device, network entry point, a similar time, the same server and destination content, and keep the transport consistent where possible. If one node uses WebSocket over TLS and another uses TCP over REALITY, the result reflects the difference between the complete combinations. Distinguish cold connections from established ones: cold connections include DNS and handshake costs, while repeated requests may reuse a connection. They answer different questions.

CPU, memory and connection multiplexing

Hardware acceleration for the encryption algorithm, the number of encapsulation layers, concurrent connection count and log level all affect CPU usage. AES-GCM is generally efficient on desktop processors with AES instructions; ChaCha20-Poly1305 may suit devices without comparable AES acceleration, but device category alone cannot determine the outcome. VLESS with suitable flow control can reduce some duplicate processing, but the actual benefit still requires support from the server and transport combination.

Mux multiplexes several logical connections over fewer underlying connections. This can reduce repeated handshake costs, but congestion or packet loss on one underlying connection can also affect several requests. For pages with many short requests, Mux may reduce connection-setup overhead; for sustained downloads, real-time connections or visibly unstable networks, disabling Mux may be more reliable. The client default is usually a reasonable starting point; fewer connections do not automatically mean higher speed.

Memory use also depends on routing rules, domain databases, DNS cache, TUN buffers and concurrent connections. Differences in protocol framing are rarely the only major source of a GUI client’s total memory use. When investigating high usage, first compare the effects of disabling verbose logs, reducing oversized rule sets, stopping repeated speed tests and closing unnecessary concurrent tasks before considering a protocol change.

Why TUN mode uses more resources

The system proxy mainly handles traffic from applications that honor system proxy settings, so its path is relatively direct. TUN creates a virtual network interface that can cover more applications, including those that ignore system proxy settings, but it must process IP packets, DNS, route matching and protocol-stack conversion. On mobile devices, leaving TUN enabled for long periods can affect battery life through wakeups, background keepalives, DNS requests and rebuilds after network changes. The main cost comes from system-level traffic interception, not simply from the selected proxy protocol.

If you only need a browser and desktop programs that follow system proxy settings, the system proxy is usually more resource-efficient. Enable TUN when you need per-process routing or full application coverage. After enabling it, avoid running another tool that occupies a virtual network interface, and check LAN bypass, DNS mode and routing rules. TUN expands coverage; it is not a “stronger protocol” and cannot fix a wrong user ID, public key or server name.

Practical controls for mobile battery use

Mobile battery life is affected more by network conditions and background behavior than by the protocol name. Weak signal requires more energy simply to maintain the wireless connection; repeated node failures trigger reconnections, DNS retries and connection rebuilds; automatic speed tests and overly short subscription intervals also wake the network. Choose a stable node, avoid continuous batch testing, set subscription updates only as needed and reduce TUN usage when full traffic interception is unnecessary.

At the protocol level, favor combinations natively supported by the client core, with complete fields and stable connections. A node with theoretically lower processing overhead but frequent handshake failures may use more power in practice than a stable traditional configuration. v2rayNG uses the Xray core and suits configurations requiring Xray features such as REALITY and Vision; v2flyNG follows the V2Fly route and suits configurations aligned with that core. Choose an app by considering protocol features and background stability together, not just the package name.

6. V2Fly and Xray core families and compatibility boundaries

Shared foundations and evolution

V2Fly and Xray both continue the Project V ecosystem’s modular configuration model: inbounds receive local traffic, outbounds connect to destinations or proxy servers, routing assigns traffic to an outbound, the DNS module provides resolution policies, and transport settings describe carriers such as TCP, WebSocket and gRPC. They share many concepts across VMess, some VLESS configurations, Trojan, Shadowsocks and basic routing structures, which is why many subscriptions can be recognized by different clients.

Similar concepts do not make configuration files fully interchangeable. Xray has developed its own extensions around VLESS, XTLS Vision and REALITY and may add specific transport or routing fields; V2Fly maintains capabilities through its own versions and module system. A JSON file readable by one core may still contain fields rejected by another. A GUI’s “import succeeded” message only means the link was parsed into a server record; actual compatibility is determined by core startup and connection logs.

How the three clients and cores fit

v2rayN is this site’s primary desktop client recommendation. It supports Windows, macOS and Linux and provides GUI entry points for server lists, subscription groups, system proxy, TUN, routing and core management. It suits desktop users handling multiple subscriptions, complex routing and protocol tests. Common configurations center on Xray capabilities, so when importing REALITY or XTLS Vision, confirm which core is actually enabled instead of checking only the client name.

v2rayNG targets Android and primarily uses the Xray core, making it suitable for VLESS, REALITY, Vision and common VMess, Trojan and Shadowsocks configurations. v2flyNG also targets Android but follows a different core path and suits scenarios requiring V2Fly configuration semantics. The two apps may show similar fields, but execution is determined by the core. When the server explicitly requires Xray extension fields, prefer v2rayNG; when the configuration is explicitly designed for V2Fly, v2flyNG may be the better fit.

Three layers of configuration compatibility

The first layer is syntax compatibility: whether JSON field names and data types can be parsed. The second is feature compatibility: whether the core implements the protocol, transport or security layer. The third is behavioral compatibility: even if both sides accept the fields, do their defaults, DNS policies and routing-match details behave the same? During migration, “configuration loaded successfully” is not enough; verify domain resolution, direct routes, proxy routes and UDP traffic as well.

Share-link compatibility also has layers. A client may recognize vless:// but not a newer query parameter, or it may preserve the node body while dropping flow, fingerprint or Short ID. A subscription converter may also rewrite core-specific fields into its own intermediate format. Compare the original share link with the imported editor and inspect the client’s exported full configuration instead of broadly labeling the problem “unsupported protocol.”

Checks before and after switching cores

Before switching the execution core in v2rayN, record the current node’s protocol, transport, security layer and routing settings. Restart the client after switching so the full configuration loads, then check the startup log for unknown fields, invalid enum values or missing resource files. Configurations using only basic VMess, TCP and TLS usually migrate smoothly; REALITY, Vision, special DNS and core-specific routing require field-by-field verification.

On mobile, avoid repeatedly rebuilding complex nodes by hand in different clients just for testing. A more reliable method is to keep the original subscription, import it again in the target client and verify the node type and key fields. If the subscription was generated for a single core, choose the corresponding client. See the Android client list for installation options. Do not keep both clients’ connections active at the same time, as their virtual interfaces and system routes may override each other.

7. Compatibility of subscriptions, share links and native JSON

Three common configuration carriers

A single share link usually begins with vmess://, vless://, trojan:// or ss:// and describes one server. A subscription link points to an updateable collection of nodes; the client requests the subscription and parses multiple records. Native JSON configuration contains the full inbound, outbound, DNS, routing and policy structure, so it expresses the most, but it may not be suitable for a subscription screen that accepts only server records. These formats serve different purposes and cannot replace one another merely because they are all text.

A common Base64 subscription format places multiple share links on separate lines and then encodes them. Base64 is encoding, not protocol conversion. If a VLESS link contains REALITY fields, the client still needs to understand those query parameters. Native JSON subscriptions may use a client-specific structure whose field names do not exactly match the core configuration. To assess compatibility, first determine whether the response is a collection of share links, client-specific JSON or a complete core configuration.

Key fields in each protocol link

VMess links commonly contain an encoded JSON object with the address, port, user ID, network type, Host, path, TLS and server name. Because historical formats use several field conventions, converters may handle host, sni and the path differently. VLESS links usually place the UUID in the user-info section and express encryption, security, type, flow, sni, fp, pbk and sid through query parameters. REALITY configurations depend especially on preserving those query parameters in full.

Trojan links use the password as user information, while query parameters may carry SNI, transport type, Host and path. Special characters in the password must be URL-encoded; otherwise content after a hash may be treated as a node remark and content after a question mark as query parameters. Shadowsocks links may encode the encryption method and password together or express them separately as user information; some also include plugin parameters. Recognizing the ss:// prefix does not guarantee support for every plugin or 2022 method inside it.

The subscription imports with no nodes

First manually update the subscription group in the client and check whether the result says the request failed, the content was empty or zero nodes were parsed. Request failures usually involve the subscription URL, network path or URL validity; a response with content but zero nodes is more likely an unsupported format. Second, confirm that you copied the subscription URL rather than a webpage URL or a single-node remark. Third, check for spaces, line breaks or non-ASCII punctuation accidentally added before or after the URL.

If only some nodes are missing, check them by protocol. If traditional VMess imports but REALITY nodes disappear, the parser may not preserve newer fields or the core may lack support. If ordinary Shadowsocks imports but 2022 methods are missing, support may differ by method. If Trojan nodes appear but cannot connect, continue with the password, SNI and transport parameters. For a fuller explanation of formats and conversion, see Base64, native JSON and share links.

Conflicts between subscription updates and local edits

Subscription nodes are normally managed by the remote source. Manual edits made in the client may be overwritten at the next update. For lasting changes to routing, DNS or the system proxy, modify the client’s global settings or routing configuration instead of editing subscription nodes one by one. If you need a persistent copy, duplicate the node into a local group and clearly distinguish it from the updateable subscription.

Subscription groups can separate configuration sources and use different update intervals. Updates should not run too frequently: server lists rarely need minute-by-minute refreshes, and frequent mobile updates increase background network activity. Node remarks help identify purpose but do not participate in protocol authentication. Renaming a node does not change its server address, public key or password, and cannot repair missing underlying fields.

QR codes, clipboard import and manual entry

A QR code is simply a graphical carrier for a share link. After scanning succeeds, the client still parses the original URI, so QR clarity affects readability but cannot solve field incompatibility. Clipboard import is convenient for one or more complete links; manual entry is useful for checking a small number of fields. Because REALITY, WebSocket and gRPC configurations contain many fields, full import followed by an editor review is usually more reliable than entering everything from scratch.

For the exact entry points, manual update timing and node-list checks when importing subscriptions in v2rayN and v2rayNG, read the subscription link import tutorial. If you received only a vmess:// or vless:// link, see share links vs. subscriptions so you do not paste a single link into the subscription URL field.

8. Choose a protocol by scenario and validate the migration

Everyday desktop use

For Windows, macOS and Linux desktops, v2rayN is the preferred choice. If you already have a stable subscription, import it in full and use the protocol combinations it provides; there is no need to convert every node to one type in advance. For normal browsing and applications that follow system proxy settings, start with the system proxy. Consider TUN only when an application does not read the system proxy. Choose nodes by stable connectivity first, then compare sustained access rather than replacing long-term judgment with a single speed-test ranking.

If a subscription offers VMess, VLESS REALITY, Trojan and Shadowsocks together, keep multiple types for comparison. With the Xray core, server-provided VLESS, REALITY and Vision combinations usually offer broad feature compatibility; stable VMess or Trojan connections can continue to be used; for Shadowsocks, focus on the encryption method. Protocol names are not quality grades. Server maintenance and complete configuration matter more than how new the name sounds.

Persistent mobile connections

On Android, choose v2rayNG when you need Xray extensions and v2flyNG when you need V2Fly core semantics. On mobile, prioritize stability, background reconnection and battery life instead of enabling every available feature. Choose a stable node, disable unnecessary batch speed tests and schedule subscription updates sensibly. If application traffic can be covered by the system proxy path, there is no need to keep the heavier TUN mode enabled; when TUN is required, simplify routing rules and check that DNS is not being processed twice.

When switching between mobile data and Wi-Fi, existing TCP connections normally need to be rebuilt. A brief interruption is not necessarily a protocol failure. If recovery consistently fails after every switch, check background permissions, system network status and node reconnection logs. Changing the protocol can solve protocol or handshake issues, but it cannot fix suspended background networking, missing subscription fields or an unreachable server.

Migrating an old configuration to a modern combination

When migrating from VMess to VLESS REALITY, have the server generate a complete new configuration and import it as a new node. Do not change the protocol dropdown on the old VMess node while keeping its TLS, WebSocket or user fields. Verify the UUID, transport type, REALITY public key, Short ID, server name, fingerprint and flow together. Keep the old node temporarily for comparison on the same network.

Migrating from a traditional Shadowsocks method to a 2022 method likewise requires changing both the server and client; the old password format cannot be reused directly. After changing a Trojan certificate or domain, update the server name and any related transport Host. For every migration, verify the basic connection first, then restore complex routing, TUN and custom DNS. Changing too much at once makes the logs difficult to interpret.

Priority checks by symptom

A repeatable validation workflow

First, record the original protocol, transport, security layer and execution core. Second, import the new configuration without deleting the original node. Third, disable complex routing and extra DNS rewrites, and verify only that the core starts, the server connects and basic domains load. Fourth, restore the system proxy, routing, DNS and TUN in sequence, running a simple access test after each change. Fifth, observe recovery after network changes and device sleep. Sixth, compare cold connections, continuous access and sustained transfers under real use.

Read logs by layer as well. A configuration parsing error occurs during startup, so check fields and the core. A handshake error occurs during connection, so check credentials and the security layer. A domain-resolution error calls for a DNS check. Only when a specific application cannot connect should you investigate the system proxy, TUN and routing. Mapping the log stage to the configuration layer prevents every problem from being reduced to “the node is unavailable.”

If your goal is to complete the first connection quickly, follow the main workflow in Getting Started. If you have not installed a client for your platform, visit the download packages page to choose v2rayN, v2rayNG or v2flyNG. For differences between the Windows desktop installer and WPF edition, see the complete v2rayN Windows installation and setup guide. After connecting, return to this guide to verify protocol fields; this is usually easier to reason about than changing the core, routing and transport parameters all at once.