V2Ray Protocol and Core
Technology Guide

Separate the protocol, transport, and security layers

A node is more than a protocol name

Seeing “VLESS” or “VMess” in a client list represents only part of the connection structure. A complete node includes at least the server address, port, user identity, proxy protocol, underlying transport, and security parameters. VLESS, for example, can run directly over TCP or be carried by transports such as WebSocket and gRPC; the outer layer can use standard TLS or be combined with REALITY. Two nodes both labeled VLESS can differ in handshake count, first-packet size, connection reuse, and failure patterns when their transport and security layers differ.

The value of a layered view is that it narrows the troubleshooting scope. When a client reports a “connection timeout,” the issue may be DNS resolution, TCP connection setup, the TLS handshake, REALITY parameter matching, or proxy protocol authentication. Repeatedly switching between VMess and VLESS will not fix an incorrect server name, port, or transport path. The correct order is to confirm network reachability, then verify that the security layer completes its handshake, and finally check protocol identity and routing rules.

How common connection stacks fit together

VMess includes a user identifier and time-based authentication; common combinations include VMess over TCP and VMess over WebSocket with TLS. VLESS keeps the protocol layer lighter and usually delegates confidentiality and server identity verification to TLS or REALITY. Trojan commonly runs as Trojan over TLS, carrying authentication data inside the protected connection. Shadowsocks directly protects the data stream with a configured AEAD cipher and has relatively compact settings. REALITY is not a proxy protocol on the same level as VMess or VLESS; it is a transport security solution in the Xray ecosystem and is most often combined with VLESS.

WebSocket, gRPC, HTTPUpgrade, and native TCP are not authentication protocols either. They determine how data is carried inside the underlying connection. WebSocket works well with established HTTP infrastructure but adds frame encapsulation. gRPC is based on HTTP/2 and suits multiplexing and streaming, but the client, server, and intermediary links must agree. Native TCP has a shorter path and fewer parameters, so problems are usually easier to isolate. QUIC-style transports run over UDP; their performance depends on UDP quality and timeout behavior on the network, not just on theoretical features.

Keep all other variables consistent when comparing

Protocol tests require controlled variables. Keep the server hardware, route, cipher, transport, concurrency, and test target as consistent as possible. Comparing a nearby VLESS node directly with a distant VMess node only describes the two complete paths; it does not prove that one protocol is faster. Download tests are also affected by server egress bandwidth and target-site throttling. Short-connection tests emphasize handshake overhead, while long, high-volume transfers better reveal sustained throughput and CPU usage.

“Latency” in a client also needs to be broken down. ICMP ping, TCP connection time, the actual proxy handshake, and a request to a test address through the proxy are different metrics. See Latency testing explained for the details. When choosing, prioritize stable real connections, normal behavior in frequently used apps, and resource changes during extended use—not just the smallest number in the list.

Background and trade-offs of five approaches

VMess: full authentication and broad, mature compatibility

VMess is one of the core protocols that emerged early in the Project V ecosystem. It incorporates user identity, request metadata, and dynamic authentication into its protocol structure; UUID is the identity field most commonly seen in configurations. VMess’s strength is not having the fewest parameters, but the extensive client support and configuration experience built up over time. Many existing subscriptions, panel outputs, and legacy configurations still use VMess, making it a practical choice when compatibility with an established environment matters.

VMess authentication is tied to system time. If a device clock is significantly off, authentication may fail even when the address, port, and UUID are correct. So when the same node works on one device but fails immediately on another, automatic time synchronization belongs on the checklist. VMess also has different cipher or security options. The client’s automatic setting is generally intended to match core capabilities; when specifying one manually, verify that the server supports it instead of applying a fixed value from an old tutorial to every configuration.

VLESS: a lighter protocol layer that relies on external security

VLESS is designed to reduce the encryption and authentication burden handled by the protocol itself. It keeps lightweight identity and proxy-request semantics while leaving transport confidentiality mainly to security layers such as TLS or REALITY. This reduces duplicate encryption and clarifies the roles of the protocol and security layers. The trade-off is that configuration cannot stop at the UUID: flow control, transport, security type, server name, and public key all affect the final connection.

VLESS does not by itself mean “encrypted.” If a subscription shows VLESS, check the security field next. With TLS, verify the relationship between the server name and certificate. With REALITY, also verify the public key, short ID, fingerprint, and server name. When the client scatters these fields across different sections, users may copy only the address and UUID, leaving a saved node that cannot connect.

Trojan: TLS as a fundamental component

A typical Trojan configuration authenticates with a password and relies on TLS to protect the connection. The model is straightforward: complete the TLS handshake correctly, then handle authentication and proxy requests inside the protected data stream. The key fields are usually the server address, port, password, server name, and certificate verification settings. If the domain does not match the certificate, the connection terminates at the TLS layer before protocol authentication begins.

Trojan’s real-world performance depends heavily on the TLS session, network round-trip time, and the underlying implementation. Its simple name does not guarantee lower resource use than VMess or VLESS. With long-lived connections, handshake cost is amortized by ongoing traffic; with many short connections, TLS session reuse and the client connection pool matter more. When comparing Trojan, check the client log to see whether failures occur during TLS or authentication.

Shadowsocks: a compact encrypted proxy design

Shadowsocks is often abbreviated as SS. It uses a password and cipher method to derive the information required for a session, and modern configurations should use an AEAD method supported by the current core. Its small set of fields and direct data path suit environments that want less configuration complexity. The cipher name must match exactly. Confusing similar names or selecting a method not implemented by the client core will cause connection failures.

Shadowsocks subscriptions have appeared in several historical formats. Some links carry the method, password, host, and port directly; others add plugin parameters. A client that recognizes basic SS does not necessarily recognize every plugin combination. After importing, check that the “encryption method” and “plugin” fields are complete. Do not assume parsing succeeded merely because the node name appears in the list.

REALITY: a security solution, not a standalone proxy protocol

REALITY belongs to the Xray feature set and is typically combined with VLESS. “VLESS REALITY” in a client means that VLESS handles proxy semantics while REALITY handles transport security. Its key parameters include the server public key, short ID, server name, and client fingerprint. The public key is not a certificate file, and the short ID is not the user UUID; they serve different roles, and swapping them cannot produce a working connection.

REALITY requires precise configuration, but that does not make everyday use complicated. When the subscription is complete, the client core supports it, and no fields are lost in transit, the node can usually connect immediately after import. Problems mainly arise when an older client cannot recognize the fields, a subscription converter removes newer parameters, or manual entry puts publicKey, shortId, and serverName in the wrong places. With a V2Fly-based client, first confirm that the target setup is within its supported range; do not assume every Xray extension runs directly.

Connection speed, throughput, and resource use

First-packet speed is driven mainly by the handshake path

The perceived “load speed” usually combines DNS lookup, the underlying connection, transport handshake, security handshake, protocol authentication, and the target site’s response. The protocol layer accounts for only part of it. On high-latency paths, each extra handshake that waits for a peer response can noticeably increase first-packet time; on a low-latency local network, the difference may barely be perceptible. TLS session resumption, HTTP/2 connection reuse, and the core’s connection pool can change the result further.

VMess, VLESS, Trojan, and Shadowsocks can all maintain long-lived connections, but clients and applications do not reuse them in exactly the same way. Browsers may reuse HTTP/2 or HTTP/3 sessions, command-line tools may create connections frequently, and messaging apps may keep a small number of persistent connections. Testing one webpage does not represent every application. At minimum, cover short page loads, sustained downloads, and persistent app traffic.

Sustained throughput is usually dominated by the route and cipher performance

Once transmission is stable, packet loss, congestion control, server egress, device single-core performance, and the encryption implementation often matter more than protocol header size. VLESS has a lighter protocol layer, but extra copying or head-of-line blocking in the outer transport can still limit throughput. Shadowsocks has a compact data path, but whether the selected cipher benefits from hardware acceleration directly affects CPU use on low-power devices.

Desktop processors usually have ample single-core performance, so differences among common approaches during ordinary browsing and video playback are often masked by network variation. Routers, low-power hosts, and older Android devices are more sensitive. In those cases, watch for sustained CPU saturation, thermal throttling, and recovery after network interruptions rather than a single peak speed test. For router hardware requirements, see an overview of deploying the V2Ray core on routers and secondary gateways.

Encapsulation adds bandwidth and processing costs

Native TCP usually has the shortest encapsulation path. WebSocket adds frame headers and an HTTP upgrade, but its compatibility is mature and the overhead is often small relative to application data. gRPC is based on HTTP/2 and can use multiplexing, though flow-control windows, connection reuse, and intermediary handling of HTTP/2 affect real-world performance. The more complex the transport, the more parameters must be checked and the more important layered log analysis becomes when failures occur.

Applications with many small packets are more affected by encapsulation and scheduling. Voice, gaming, and real-time control traffic are sensitive to jitter and packet loss, so average download speed does not represent the experience. For UDP through a proxy, also check protocol support, the client’s UDP capability, how often the network reclaims UDP mappings, and whether routing sends the relevant domains and IPs through the same egress. Any mismatch can appear as successful login with broken real-time features.

Build a reproducible comparison method

Keep the device, network, server location, and target file fixed, and disable other proxy tools that could change the path. Run several real connection tests and record the median rather than the minimum; then download for long enough to observe stable throughput; finally check CPU and memory changes in the client and core processes. If the two protocols use different servers, you can assess only overall node quality, not attribute the result to protocol design.

Also distinguish cold starts from warm connections. The first launch includes core loading, DNS cache creation, and security session setup; later requests may reuse an existing connection. If the use case involves frequent network changes, cold-start and reconnection behavior matter more. If the device stays online, stability and background resource use matter more. No protocol leads on all of these metrics in every situation.

Android battery use and background behavior

Battery drain is not caused by encryption alone

Proxy battery use on mobile devices comes from wireless-radio wakeups, CPU work, virtual network-interface forwarding, DNS queries, keepalive traffic, and background app traffic. Protocol encryption is only one factor. After the screen turns off, if many apps keep opening short connections, the cellular radio may repeatedly leave its low-power state, consuming more energy than the protocol itself. Conversely, a small number of stable long-lived connections can maintain relatively steady power use even with TLS.

v2rayNG uses the Xray core and suits subscriptions that require Xray features such as VLESS and REALITY; v2flyNG uses the v2fly core and can serve configurations intended for V2Fly. Both may take over traffic through Android’s VPN interface. Actual battery use depends on routing scope, app count, DNS policy, and connection state, not simply the client or protocol name.

Virtual network interface mode versus system proxy

Android clients typically forward app traffic through the VPN interface provided by the system. Each packet passes through user-space processing, routing decisions, and an outbound connection; the more complex the rules and the more concurrent connections there are, the greater the scheduling load. On the desktop, v2rayN can set only a system proxy or use TUN mode to capture programs that do not follow system proxy settings. See the guide to configuring TUN mode for full-traffic capture for its principles and permission requirements.

Mobile devices do not need every app to use the proxy all the time. If the client supports per-app routing, select only the apps that actually need it to reduce unrelated background traffic. Routing rules should also remain understandable: define LAN and necessary direct connections first, then proxy rules, and finally the default outbound. Large numbers of duplicate or overlapping rules are difficult to maintain and make troubleshooting harder.

Keepalives, reconnection, and network switching

When switching between Wi-Fi and cellular data, existing TCP connections usually need to be rebuilt. If the client keeps dead connections for too long, apps experience a long wait; if it probes and reconnects too often, wakeups increase. The protocol does not determine this behavior alone: core connection management, Android background limits, and the app’s retry policy all contribute. For stable use, avoid enabling several connectivity tests with very short intervals at the same time.

WebSocket, gRPC, and native TCP recover differently after a network change, but the result still depends on whether the app sends a new request. QUIC and other UDP-based transports have different connection semantics, while mobile networks may reclaim UDP mappings more aggressively. If recovery is slow after the screen locks, first confirm that the system has not restricted the client in the background, then check whether the log shows unreachable networking, a DNS timeout, or a remote connection close.

DNS policy affects wakeups and retry failures

Inconsistent DNS settings can cause duplicate queries, timeouts, and fallback behavior. When the client simultaneously uses local DNS, remote DNS, system DNS, and an app’s built-in encrypted DNS, the request path may be more complicated than expected. A safer approach is to define which domains resolve locally and which resolve through the proxy egress, while avoiding multiple rules taking over the same query class. If the node server uses a domain, ensure that resolving the server address does not loop through the proxy chain itself.

When a browser works but some apps keep draining the battery, check whether those apps repeatedly request failing domains or use a network interface not handled by the current proxy mode. Repeated timeout lines in the core log are usually more useful for diagnosis than a single percentage in battery statistics. If the log shows rapid retries to the same target, fix routing or DNS first rather than immediately changing protocols.

How to make a meaningful battery comparison

Compare two configurations on the same device and network with similar application traffic. Charging state, screen brightness, signal strength, and background sync can all distort the result. Observe at least one full everyday-use cycle and combine system battery statistics, client logs, and device temperature. Checking battery change after briefly opening a page provides too little data to separate wireless communication from protocol computation.

To reduce resource use, first eliminate unnecessary connections, narrow the set of proxied apps, fix DNS timeouts, and choose an encryption implementation that the device handles well. Keep compatibility and stability as the priorities at the protocol layer. A setup with theoretically smaller headers but constant errors and reconnects in the current client will not use less power in practice.

The V2Fly and Xray core families

Shared origins and different directions of development

V2Fly and Xray both originate from the Project V ecosystem and retain many similar configuration concepts: inbound, outbound, routing, DNS, policies, and transport settings. Both can handle common configurations such as VMess and Shadowsocks, and both use structured descriptions of connection relationships. Similarity does not mean complete equivalence. As they evolve independently, protocol features, transport options, field names, and defaults can diverge.

Xray provides corresponding capabilities for VLESS, flow control, REALITY, and related features, so v2rayN and v2rayNG commonly use Xray to handle these nodes. v2flyNG targets the v2fly core and is better suited to subscriptions generated for V2Fly capabilities. The client interface is only the configuration entry point; whether a connection works ultimately depends on whether the core actually launched understands those fields.

Similar configurations are not necessarily interchangeable

The basic outbound structure may look very similar between the two families, but extension fields define compatibility boundaries. For example, a configuration containing REALITY settings for Xray cannot be assumed readable by V2Fly merely because the outer format is still JSON. Unknown fields may cause a startup error or be ignored, producing behavior different from what was intended. Migrate configurations feature by feature instead of only changing the executable core name.

Even when both sides support the protocol name, transport details may differ. Check network, security, flow, streamSettings, TLS parameters, and DNS structure. When the client generates a configuration, it adjusts fields for the selected core; that conversion may not happen when importing a complete JSON file manually. Most users should therefore import a subscription or sharing link and let the client generate the runtime configuration rather than maintaining a large configuration file across cores.

How v2rayN, v2rayNG, and v2flyNG correspond

On desktop, start with v2rayN, which covers Windows, macOS, and Linux. It provides subscription management, system proxy settings, routing modes, and core-log access for managing multiple desktop environments. On Android, prefer v2rayNG when a subscription contains VLESS, REALITY, or fields that explicitly depend on Xray. Choose v2flyNG when the subscription is generated for V2Fly capabilities or when you need to verify V2Fly behavior.

These three clients are not three protocols. The client handles the interface, configuration generation, system traffic capture, and core-process management; the core parses the configuration and forwards traffic; the protocol defines how the client core and server exchange data. Separating these layers clarifies many issues: a sharing link that cannot be imported is a client parsing problem, a core startup failure is a configuration compatibility problem, and a handshake failure usually calls for protocol or security-layer troubleshooting.

Identify compatibility issues from logs

When the core fails to start, read the first error in the log rather than the repeated exit messages at the end. Unknown fields, unrecognized protocol types, missing required parameters, and JSON syntax errors usually appear clearly during startup. See How to locate core startup failures from the first log line for details. If the core has started but connections fail, continue with the DNS, dialing, TLS, and authentication entries.

If only some nodes fail after migrating a configuration, group working and failing nodes by protocol, security layer, and transport. If every REALITY node fails while VMess works, check core capabilities first. If only one transport fails within the same protocol, check streamSettings. If all nodes fail to start, inspect the overall configuration structure, port conflicts, and permissions. This classification is more effective than deleting and rebuilding nodes one by one.

Subscription formats and sharing-link compatibility

A subscription is a container, not a protocol

A subscription link usually returns a set of node descriptions. Nodes may use VMess, VLESS, Trojan, or Shadowsocks and may include client-specific fields. The subscription address only locates the content; it says nothing about the protocols inside. After updating a subscription, the client must download the text, identify its encoding and format, and convert each node into a local configuration. A failure at any stage may appear to the user as “no nodes found.”

Common content includes multiple sharing links, an encoded collection of links, or structured configuration. Clients differ in how much they support extension fields and combined formats. If a subscription service outputs REALITY parameters but an intermediate converter keeps only the basic VLESS fields, the node still appears after import while its public key, short ID, or fingerprint is gone. This is more difficult to notice than a complete parsing failure.

What sharing links can express

VMess sharing data generally includes the address, port, user ID, transport, and security settings. VLESS links express encryption, security, type, flow, serverName, publicKey, shortId, and related information through query parameters. Trojan links need the password, address, port, and TLS parameters. Shadowsocks links mainly express the cipher method, password, server, and port, with optional plugin parameters.

Link parameter names are distinct. In a VLESS REALITY link, pbk usually maps to the server public key, sid to the short ID, sni to the server name, and fp to the client fingerprint. Some clients display full names while subscriptions use short parameters. After importing, compare the field meanings rather than guessing from their display order.

vless://[email protected]:443?encryption=none&security=reality&type=tcp&sni=www.example.invalid&fp=chrome&pbk=example-public-key&sid=example-short-id#VLESS-REALITY-example

The structure above illustrates where fields go; the domain and identity values are explicit examples. A real node must use the complete parameters supplied by the server. When editing a link manually, also handle URL encoding correctly: spaces, non-ASCII characters, and special symbols in the node name must be encoded, and reserved characters in a password cannot simply be concatenated as visible text.

Successful import does not mean the configuration is complete

If the client can create a node record, that proves only that the outermost format was recognized. Next open the node details and check the protocol type, address, port, identity fields, transport, and security layer. For WebSocket, check path and Host; for gRPC, check serviceName; for TLS, check serverName; for REALITY, check publicKey, shortId, fingerprint, and flow.

If existing nodes still work after a subscription update but new nodes do not, compare their field differences and confirm core capabilities. If all nodes disappear, first check whether the subscription returned empty content, whether the address was truncated, and whether the client recognizes the current format. See this checklist for expired or unparseable subscription links for six common causes and the recommended order of checks.

How subscription updates overwrite local changes

Most clients regenerate nodes from the subscription group during an update. Manual local changes may be overwritten by the next update. Custom routing, DNS, and system proxy settings that must persist should go in the client’s separate configuration area rather than in individual subscription nodes. For temporary node edits, copy the node to a local profile and rename it to avoid confusing it with the subscription source.

A node name is not a stable identifier. Providers can change names or ordering, and clients may deduplicate by address, protocol, or an internal ID. During troubleshooting, record the protocol, server, port, and key transport parameters instead of referring only to “the second node.” The destination address and outbound tag in the log are better for establishing a match.

Choose clients by field fidelity

Use v2rayN on desktop to inspect fields for multiple protocols and runtime logs in one interface. Use v2rayNG on Android when the subscription contains Xray extensions; use v2flyNG when it is explicitly built for V2Fly configurations. If a subscription contains several protocols, the client should preserve each node’s fields rather than forcing every node into one protocol.

For a complex subscription, the safest approach is not to pass it repeatedly through multiple converters, but to import the original subscription directly into the target client and sample one node from each protocol. Test connections only after confirming that the fields are intact. Every additional format conversion creates another opportunity for lost fields, changed defaults, and encoding errors.

Protocol parameter checks and troubleshooting

Address, port, and identity fields

For any protocol, start with the three basics: can the server address resolve, is the port correct, and are the identity fields complete? VMess and VLESS commonly use a UUID; Trojan uses a password; Shadowsocks uses a password and cipher method. Remove leading and trailing spaces when copying, but do not alter characters inside the value. The port must be a valid number and match the server’s listening port.

When the server address is a domain, first confirm that the client’s network can resolve it. If the configuration includes both an IP and serverName, understand that they serve different purposes: the IP determines the connection target, while serverName is used for the TLS or REALITY handshake. Replacing serverName with an IP can break the security layer; changing the connection address to the certificate domain can also change the actual route.

TLS and the server name

In a TLS configuration, serverName is generally used for server identity verification and the handshake. It must match the server configuration and certificate relationship. If the client offers an option such as “skip certificate verification,” do not treat it as a routine fix. A certificate error usually points to a domain, clock, certificate chain, or intermediary-network problem. Disabling verification hides the root cause and makes later migration harder to assess.

System time also affects certificate-validity checks. If several TLS nodes fail at once while non-TLS nodes work, check the device time, time zone, and certificate-related logs. If only one domain fails, focus on that node’s serverName, target address, and server certificate configuration.

Four key REALITY parameters

A REALITY client configuration must correctly understand at least publicKey, shortId, serverName, and fingerprint. publicKey comes from the server’s corresponding key; shortId must be one of the values allowed by the server; serverName must match the server settings; fingerprint identifies the client handshake fingerprint type. The VLESS UUID remains separate and cannot be replaced with publicKey.

The flow field may also be part of a VLESS configuration. The server and client must use compatible values. If the subscription specifies flow, import it as provided; if the server has not enabled that flow control, do not add it based on another node. An incorrect flow can prevent correct data transfer even after the basic connection is established, and the log is usually more specific than the generic client error.

WebSocket, gRPC, and path fields

For WebSocket, check path and Host. Whether path begins with a slash and whether it includes a query string must follow the server’s original value. Host and TLS serverName may be the same or may serve different purposes. For gRPC, check serviceName and confirm that the client and server agree on options such as multiplexing mode. Putting a WebSocket path into the gRPC serviceName may look plausible, but the protocol behavior is entirely different.

When the connection log shows that the underlying TCP connection and TLS both succeeded, but then an HTTP status error appears or the stream closes, focus on the transport path. If a reverse proxy sits in front of the server, ensure that it supports the required upgrade or HTTP/2 forwarding. The client sends only the request specified by the configuration; it cannot infer the correct path automatically.

Troubleshoot with the minimum-variable method

Start with a node known to have a complete configuration, disable custom routing and extra DNS rules, and test the basic connection in the client’s default proxy mode. Once the basic connection works, restore routing, TUN, app rules, and custom DNS one at a time. If you change the protocol, transport, routing, and system proxy simultaneously, a failure cannot reveal which change caused it.

Read the log from the first error. Repeated reconnections generate many similar lines, while the end usually records only process exit or context cancellation. Save one clean test: clear the log, start the core, access a clearly defined target, wait for the error, and stop. This orders DNS, dialing, handshake, and authentication events chronologically.

Choose a protocol and client by use case

Keep an existing subscription’s original configuration first

If a subscription already provides working nodes, the first rule is to import the original protocols and parameters instead of manually converting them to chase a particular name. A VMess node does not become VLESS by changing its type, and a Trojan password cannot be used directly as a Shadowsocks password. Protocol conversion requires the server to provide the corresponding listener and parameters; a client-side edit cannot perform that conversion.

Desktop users should start with v2rayN and then choose nodes based on the subscription. Android users should use v2rayNG for VLESS, REALITY, or other Xray extensions; use v2flyNG when the subscription is explicitly generated for the V2Fly core. The corresponding installation options are collected on the client downloads page, with platform information for Windows, macOS, Android, and Linux.

Choose VMess for compatibility with legacy environments

When the existing server, subscription system, and clients all support VMess reliably, there is no need to migrate immediately just because newer protocols are available. VMess has extensive configuration documentation and compatibility experience, making it suitable for environments that continue to use WebSocket, TLS, or TCP combinations. Pay particular attention to system time, UUID, transport fields, and security settings.

For a gradual migration, let the server provide old and new entry points in parallel and test them on the same route and device. Verify functionality and stability first, then switch the subscription. Keeping the working original configuration during migration helps distinguish a new-protocol issue from a broader server problem.

Choose VLESS when clear layering matters

VLESS suits environments that want to combine a lightweight protocol layer explicitly with security layers such as TLS or REALITY. With standard TLS, the certificate, serverName, and transport configuration must be complete. With REALITY, you need an Xray core plus matching public key, short ID, fingerprint, and flow-control parameters. Its advantage comes from a well-formed complete stack, not from merely changing the protocol name to VLESS.

After importing a VLESS sharing link into v2rayN or v2rayNG, sample-check streamSettings. If the subscription was converted, verify especially that the REALITY parameters were not removed. With accurate configuration, daily operation is no more complicated than other protocols; with incomplete source data, there are more fields to troubleshoot than in a basic VMess setup.

Consider Trojan when TLS is central

When the server already provides a Trojan endpoint with its password and TLS parameters, use the matching node directly. The key checks are certificate and server-name correctness, TLS-session stability, and transport agreement with the server. Trojan suits environments that prefer a clear password-authentication and TLS structure, but it cannot bypass the basic requirements of certificates, networking, and server configuration.

For workloads with many short connections, watch first-packet time and session reuse. For sustained downloads, watch stable throughput. Do not infer performance from protocol structure alone. If the Trojan node and the comparison node use different servers, the result mainly reflects differences in the complete network paths.

Consider Shadowsocks when fewer configuration fields matter

Shadowsocks keeps its basic configuration to the address, port, password, and cipher method. It suits situations where the server offers a modern AEAD method supported by the client and does not depend on complex extensions. On low-power devices, also confirm that the selected algorithm is well implemented; “fewer fields” does not automatically mean “faster on every device.”

If the sharing link includes plugin parameters, confirm that the client supports the plugin and its options. A basic SS import may succeed while lost plugin fields still make the node unusable. For UDP applications, separately confirm support across the client, core, server, and network path.

On mobile, prioritize stable connections and clear traffic rules

On Android, differences in protocol often matter less than background restrictions, signal strength, and DNS retries. First choose a node supported by the client core, then limit unnecessary proxied apps, keep routing rules simple, and observe recovery after network changes. If problems appear after the screen locks, do not immediately blame the protocol.

For long-running background use, choose a complete configuration that stays stable without frequent reconnects. A node that is slightly faster in one speed test but continually retries its handshake is a poor default for background use. Confirm the reconnection cause in the logs before deciding whether to correct parameters, change transport, or switch nodes.

Final decision order

First confirm what protocol and complete parameters the server actually provides. Second, confirm that the target client and core support that combination. Third, verify that all fields remain intact after import. Fourth, test stability with real connections, sustained throughput, and frequently used apps. Fifth, observe CPU, memory, battery use, and network-switch recovery. This order prevents format-parsing issues from being mistaken for protocol problems and avoids replacing long-term experience with a single latency number.

If you only need to install, import a subscription, and connect, follow the quick-start guide step by step. To choose an installer, visit the V2Ray client downloads page. For subscription parsing, core startup, or latency metrics, continue with the linked specialist articles on this page. There is no universal protocol choice independent of the server, core, and network; complete compatibility and stable operation come before theoretical differences.