01 / Protocol, Transport, and Security Layers
One configuration label can describe three layers
“VLESS + TCP + REALITY” in a client list doesn't mean three interchangeable protocols. VLESS handles identity and destination details for proxy requests; TCP is the underlying connection and part of the transport setup; REALITY provides a secure handshake. Similarly, VMess can use different transports, while Trojan typically relies on TLS. Separating these layers helps you put each server-provided field in the right place and avoid assuming that “supports VLESS” means “supports every VLESS combination.”
A proxy protocol defines how the client identifies itself to the server, specifies the requested destination, and wraps the request. Transport settings determine how that data is carried—for example, directly over TCP or through WebSocket or gRPC. The security layer handles peer authentication, key negotiation, and protection of transmitted data. These layers can be related, but not every combination works. The core implementation and client interface also impose limits.
Check the address, port, and names separately
The address is usually the server's domain name or IP address used to establish the connection; the port selects the service. The TLS server name is used for authentication and the handshake, while the WebSocket Host and path are used to process requests for that transport. These values don't necessarily match the address field. If your provider specifies them separately, enter each value as given. Replacing every domain with the address-field value may establish a network connection but still fail certificate validation or transport request handling.
The local listening port is a separate setting. In v2rayN, the local SOCKS port is commonly used by browsers and other programs; it is not the remote server's entry point. Changing the local port won't change the server protocol, and changing the remote port won't fix a local listener conflict. When reading logs, identify whether the error occurs at the local inbound, during the remote connection, or while accessing the destination. Each stage has different settings to check, so avoid changing several at once just to see what happens.
| Layer | Common Fields | What to Check |
|---|---|---|
| Proxy Protocol | Protocol type, user ID, password | Identity format matches the server |
| Transport | Network type, Host, path, service name | Transport matches the server entry point |
| Security | TLS, server name, REALITY parameters | Authentication method and keys match |
| Local Access | Listen address, port, system proxy | Whether application traffic reaches the client |
Routing and DNS aren't measures of protocol strength
Routing determines whether a request goes direct, through the proxy, or to a blocked route. DNS resolves domain names to usable addresses and may also affect routing decisions. The same protocol can produce very different results under different routing rules. If a site works directly but fails through the proxy, the protocol itself may be fine; DNS results, address families, or rule order could differ. First identify which outbound route the request actually takes, then consider whether changing protocols would help.
Domain strategies, traffic sniffing, and multiplexing in the interface are also separate features. Domain strategies affect when and how domain names are resolved and matched against addresses; traffic sniffing attempts to identify destinations from requests; multiplexing changes how multiple requests share connections. Each can help in specific situations, but can also add variables. To establish a working baseline, keep the client's sensible defaults and fill in only server-required fields. Once the connection is stable, test advanced options one at a time.
02 / VMess and VLESS: Design Trade-offs
VMess: Authentication and Built-in Protection
VMess developed alongside the Project V ecosystem and remains common in many existing configurations. Its design includes authentication and data protection, and clients typically require a user ID and corresponding security settings. Use a valid configuration supported by a maintained core; don't copy fields from old tutorials into a current interface without checking them. Importing an old link only shows that the parser recognizes its structure—it doesn't prove its authentication method is still suitable for the server.
When working with VMess, distinguish protection within the protocol from outer TLS. A configuration may use TLS as required by its deployment, even when the protocol already provides protection; adding another layer doesn't automatically make it faster or more reliable. Each layer adds negotiation and processing requirements. Match the server's required combination: don't disable a required security layer or add a transport the server hasn't configured.
VMess authentication depends on time, so a significantly incorrect system clock is a worthwhile early check. Enable automatic time synchronization on the device and try connecting again before changing the user ID. Use security options supported by both the current client and server; don't guess compatibility from a setting's name. If an old profile contains legacy fields such as an extra identifier, ask the provider for the current parameters instead of repeatedly trying values to keep a mismatched setup running.
VLESS: A Lean Protocol That Relies on Its Security Setup
VLESS keeps the proxy protocol's responsibilities minimal, retaining essential identity and request details while relying on external mechanisms for transport security. It doesn't provide the same built-in encryption system as VMess, so “VLESS is lighter” doesn't mean you can skip the security layer in every situation. Common setups pair VLESS with TLS or REALITY; the actual security boundary depends on the complete configuration, not the protocol name.
The VLESS fields for user ID, encryption, flow control, and security type serve different purposes. Some configurations show none for the encryption field; that is the value for that protocol field and doesn't mean the entire connection lacks security. Check the outer security settings too. Flow control isn't a speed boost you can enable at will: use it only when the server, core, and transport combination support it. Don't add it without explicit parameters.
REALITY and Vision often appear in the same configuration notes, but they aren't interchangeable. REALITY is a security mechanism; Vision is a flow-control mode used in related implementations. A core that supports VLESS may not support REALITY or a particular flow-control combination. If the interface lacks the relevant option, check the running core and client capabilities first. Don't paste a flow-control string into a notes, path, or other unrelated field.
How to Choose Between Them
For an existing service, start with a maintained setup the server actually provides. There's no need to replace a complete, stable VMess configuration just because VLESS sounds newer. Likewise, if the server already offers a secure VLESS setup, there's no reason to switch to VMess just to follow an old tutorial. A migration requires a matching server entry, client fields, and compatible core. Keep the original configuration for comparison, then test the destination sites, long-lived connections, and UDP requirements separately.
Compare new setups on the same network, against the same destination, and under similar transport conditions. If VMess and VLESS use different servers or transports, measured differences mostly reflect deployment conditions, not the protocols themselves. Focus on whether parameters can be distributed accurately, the client can import them completely, and issues can be reproduced quickly. Small theoretical differences in overhead matter less than a clear, maintainable configuration.
03 / Trojan, Shadowsocks, and REALITY
Trojan: Proxy Connections over TLS
Trojan uses a proxy connection built around TLS. Common configurations use a password for proxy authentication and rely on TLS to authenticate the server and protect the connection. These are separate jobs: the password determines whether the proxy accepts a request, while the certificate and server name let the client verify the connection endpoint. A correct password can't fix a mismatched certificate name, and a valid certificate doesn't guarantee proxy authentication will succeed. Use the logs to identify which stage failed.
A Trojan setup commonly requires the server address, port, password, and TLS server name; other fields depend on the transport and implementation. If certificate validation fails, check the name, device time, certificate chain, and server configuration first. Don't leave certificate verification disabled. Skipping verification changes the authentication boundary; it isn't a routine compatibility tweak. Even if the connection works temporarily, that doesn't mean the original configuration is fixed.
Shadowsocks: The Method Determines Compatibility
Shadowsocks originated as a relatively lightweight encrypted proxy design and is often abbreviated to SS. Connections use parameters such as an encryption method and password. It isn't a VMess transport mode, so select the correct protocol when importing it. Methods from different generations have different key requirements and support, and not every configuration bearing the SS name is interchangeable. For newer methods, a matching option in the client interface isn't enough; the running core must implement it too.
For AEAD methods, the client and server must use the same method and password; some newer methods also impose specific key-format requirements. Don't treat outdated methods from old tutorials as the default for a new deployment. If a shared link includes plugin parameters, confirm that the current client and core can handle them. Importing the address and password successfully doesn't mean the extra requirements can be ignored. Without the required transport component, correct protocol fields still won't establish a connection.
REALITY: A Security Mechanism, Not a Standalone Proxy Protocol
REALITY is a security mechanism in the Xray ecosystem, commonly used with VLESS. It can't act as a complete proxy protocol on its own like VMess or Trojan. If the client offers a REALITY security option, you'll still need an upper-level protocol, an address, and identity fields. It's included in comparison tables to explain the boundaries of common combinations—not to suggest that every name belongs to the same layer. Keep these layers distinct when reading service configuration.
Common REALITY client parameters include the server public key, server name, short ID, and client fingerprint; exact names and presentation can vary by implementation. The public key comes from the server's corresponding key configuration—don't generate a new one and substitute it. The short ID must also be in the set accepted by the server. The fingerprint option affects the relevant handshake behavior; switching it at random won't improve performance. A parameter that looks reasonable on its own doesn't guarantee the full set is compatible.
| Name | Role | What to Check |
|---|---|---|
| Trojan | Proxy protocol, typically used with TLS | Password, TLS server name, certificate validation |
| Shadowsocks | Encrypted proxy protocol | Method, password or key, additional parameters |
| REALITY | Security mechanism | Public key, server name, short ID, core support |
Compare complete setups, not abbreviations
You can't compare the connection cost of Trojan, Shadowsocks, and VLESS with REALITY just by counting fields. TLS session resumption, server implementation, processor acceleration, network round trips, and actual traffic all affect the result. Fewer parameters can make manual checks easier, but that doesn't make a setup suitable for every workload. For UDP applications, verify that the client inbound, protocol outbound, and server forwarding path all support the required behavior. A single “UDP supported” note isn't enough.
When choosing, first check what the existing service supports, then consider how easily the configuration can be distributed without errors. If several devices need to share a setup, confirm that each can represent all required parameters. A device that imports it only by dropping fields isn't truly compatible. Keep a verified baseline and test the new combination with the same application. This makes it easier to tell whether a failure comes from authentication, the security layer, or application routing instead of blaming protocol stability.
04 / V2Fly, Xray, and Client Roles
The Client Interface Isn't the Runtime Core
Project V provides useful context for this ecosystem, while V2Fly and Xray are separate core projects that should be identified individually. A graphical client manages subscriptions, configuration editing, system integration, and process startup; the core handles protocols, transports, routing, and connections. The v2rayN interface alone doesn't tell you which core is running the current connection. To investigate capability differences, check the relevant client settings and the runtime details in the startup logs.
V2Fly continues the development of V2Ray-related implementations and ecosystem, while Xray grew from a related codebase and has developed its own features. They share some concepts and configuration conventions, but they aren't two names for the same program. Capabilities such as REALITY and Vision generally require checking Xray support; V2Fly's transport and configuration changes should be verified separately. Availability ultimately depends on the specific core implementation and client integration.
What Each Client Does
For desktop, start with v2rayN: installation options for Windows, macOS, and Linux are on the downloads page, though the interface and system integration can vary by platform. It can manage core-related settings, but that doesn't mean every protocol can run on any core. On Android, v2rayNG uses the Xray core, while v2flyNG is an alternative for the V2Fly ecosystem. Choose a client to match the service parameters—not as a speed tier.
Before switching cores, make a copy of the working configuration and note the routing, DNS, listening ports, and startup options. Then change only the core or related configuration combination, check the startup logs, and test access. If the new core rejects an advanced field, look up the equivalent configuration for that core instead of deleting the offending line until the program starts. The removed field may control essential routing or security; a successful startup doesn't guarantee equivalent behavior.
Similar JSON Doesn't Mean Drop-in Compatibility
Two configurations that both contain inbound, outbound, routing, and DNS sections only share a similar organizational structure. Field values, transport names, defaults, and extension support may still differ. A graphical client may also add local listeners, tags, and platform-specific settings when generating the runtime configuration, so a manually saved snippet may not match the final file. When troubleshooting, use the client's configuration viewer or logs to confirm what the core actually receives.
The following rule object is for routing configuration in a supported core. It sends private-address matches to the outbound named direct. This isn't a complete runtime configuration; the outbound tag and rule data must already exist for it to have an effect. Use the example to understand how the fields relate, not to overwrite the entire configuration generated by the client. In a graphical interface, the safer approach is to add an equivalent rule in the routing editor and review the generated result.
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}Rule files are another part of compatibility. A configuration containing the geosite: or geoip: prefix doesn't guarantee that the corresponding data is present or contains the referenced tags. After changing cores, moving directories, or restoring a backup, check the data location used by the client and whether updates succeeded. See the GeoIP and GeoSite Rule File Update Guide. Don't mistake a rule-loading failure for proxy authentication failure.
05 / Comparing Speed and Resource Use
Break speed down into measurable stages
“Fast connection” could mean quick client startup, a fast initial handshake, a quick first response from a web page, or high sustained download throughput. These are different metrics. Core startup depends on configuration size, rule loading, and device performance; the first connection depends on name resolution, network round trips, and the security handshake; sustained transfers also depend on bandwidth, congestion, the destination service, and server load. Comparisons between protocols are meaningful only when you specify which stage you're measuring.
A security handshake can add work when establishing the first connection, but that doesn't mean “TLS always makes a setup slow.” Session resumption, connection reuse, and an application's persistent connections can reduce repeated overhead. Conversely, a quick client connection test doesn't guarantee that a complex web page will load quickly: it may need to access multiple domains, resolve several addresses, and open multiple connections. A test button is only one limited signal.
Assess CPU use alongside throughput and idle behavior
Encryption methods, processor instruction support, memory copying, and encapsulation layers all affect CPU use. The same protocol can perform differently across devices, so there is no universal ranking of resource use. When checking usage, distinguish idle periods from sustained transfers and compare at similar throughput. A setup using more CPU because it transferred more data isn't automatically less efficient; sustained unexplained activity while idle is more worth investigating.
Memory use also depends on connection count, routing data, DNS cache, and log buffers. Don't compare values taken just after startup with those recorded later; system monitoring tools may also measure memory differently. If usage grows, first check whether connections keep accumulating, apps are retrying, or logging is too verbose. A single screenshot usually isn't enough to conclude that one core “uses less memory.”
Use controlled comparisons, not a single speed test
For a fair comparison, use the same device, network, destination resource, and roughly the same time window. Record the complete protocol combination, and don't rank protocols using servers in different regions. First compare real application tasks, such as opening the same page, syncing the same file, or maintaining the same kind of connection; then add client connection tests. Repeat several rounds and alternate the test order to reduce the effects of caching, background updates, and temporary network changes.
| Symptom | Check First | Don't Assume |
|---|---|---|
| First page load is slow; later loads are normal | DNS, initial handshake, connection resumption | The protocol has poor sustained throughput |
| High CPU during sustained transfers | Actual throughput, encryption implementation, encapsulation | The core is faulty |
| Repeated connection attempts while idle | Retries, keep-alives, background apps | Changing protocols will fix it |
| Only one application fails | Access method, UDP, app proxy settings | All connections are unavailable |
Test multiplexing as a separate variable. It can reduce connection setup costs in some situations, but may also affect how streams interact; some transport or flow-control combinations have specific restrictions. Don't change multiplexing, fingerprints, DNS, and domain strategy all at once and then credit one setting for the result. Keep a test log after each change and note whether the improvement affects first access or long-lived connections. That makes it easier to decide whether to keep the setting.
On desktop, account for differences between system proxy and TUN access. If two tests use different access methods, the traffic reaching the core, DNS behavior, and background load may all change. Limit performance conclusions to the complete setup—for example, a particular device, access method, and service configuration—instead of claiming that one protocol is always faster. Prioritize correct, stable behavior, then make small optimizations to the parts that actually affect your experience.
06 / Android Battery Use and Background Connections
Protocol isn't the only factor in battery use
On Android, v2rayNG and v2flyNG commonly receive traffic through the system VPN interface. System battery statistics may attribute some of the work handled through that interface to the client, so a higher client battery percentage doesn't necessarily mean the core is idle and wasting power. Consider screen use, actual data transfer, background apps, and device idle time together. File sync, video playback, and long periods of inactivity are different workloads; a single battery percentage isn't enough to compare them.
A mobile radio switches between activity states. Frequent small requests, connection retries, and overly frequent keep-alives can make it harder for the device to enter a low-power state. CPU work for protocol encryption is only part of the cost. Weak signal or frequent disconnects can also make reconnecting more expensive. Before assessing protocol impact, confirm that the device is on a stable network and check whether an app is continuously making background requests.
Balance keep-alives with background restrictions
Keep-alives are generally intended to maintain necessary connections or detect failures promptly, but timeout behavior varies across networks. Shortening every keep-alive interval can increase wake-ups; disabling them completely may make some long-lived connections less reliable. If there isn't a specific problem, use the client's and service's sensible defaults. If you need to make a change, adjust one related setting at a time and observe idle behavior, reconnection after unlocking, and recovery after changing networks—not just foreground browsing.
System battery optimization and manufacturer background management may terminate the client process. Symptoms include disconnects when the screen locks, reconnecting after unlock, or a mismatch between service status and notifications. Check that the client is allowed to run in the background and that any relevant system prompts have been handled. Background permission doesn't mean every app must stay connected. If you use per-app proxying, remember that excluding an app changes its traffic route; it doesn't simply reduce the client's processing cost.
Check idle, active use, and network switching
Start with a verified working configuration and observe three situations: idle with the screen off, foreground use of a fixed app, and recovery after switching between Wi-Fi and mobile data. Keep the duration and usage roughly consistent, and note reconnection prompts or error logs. Avoid installing updates, syncing photos, or running repeated speed tests during the comparison. Extra activity makes battery results less useful and can hide the background behavior you're trying to investigate.
If foreground access works but idle battery use is unusually high, check for repeated authentication failures, name-resolution errors, unreachable destinations, or keep-alive retries. Repeated failures may keep the device doing the same work over and over. Fix the cause before changing protocol parameters. Keep logs only long enough to reproduce the issue, then restore normal logging levels; verbose logging also adds processing and writes, and may record connection details you shouldn't share.
If battery use rises only with a particular app, compare its actual traffic and connection behavior, and check whether it is repeatedly retrying because the proxy route changed. Per-app proxying can also involve browsers launching external apps, account logins, and interactions with system components. Proxying only part of that chain may produce inconsistent behavior. If the battery percentage drops after excluding an app, don't assume the client became more efficient; the work may simply have moved to another battery category.
To compare v2rayNG and v2flyNG, use a service combination both fully support and avoid running multiple VPN services at once. If one setup uses REALITY while the other uses a different server, the results can't be attributed to core power efficiency alone. For a more detailed checklist, see Troubleshooting v2rayNG Battery Use and Background Operation. The goal on mobile is stable service for the tasks you need—not the lowest battery percentage regardless of usage.
07 / Share Links, Subscriptions, and Configuration Compatibility
A subscription distributes configurations; it isn't a protocol
A share link usually describes one connection configuration, while a subscription distributes and updates a set of configurations. The subscription URL itself doesn't determine the proxy protocol, nor does it guarantee that every client can read its contents. Common formats include lists of links, encoded lists, and structured configuration documents. Parsing the outer format is only the first step; verify the protocol, security layer, and transport fields in each entry separately.
VMess share links commonly encode parameters as structured data; VLESS and Trojan often use an address with query parameters, while SS links have their own user-info encoding. Clients don't all support the same extensions, and fields with the same name may need different mappings. When copying a link, keep it intact—don't retain only the domain and port. If a QR code contains a complete configuration, check that the scanning app hasn't truncated the result.
After import, check the key fields
After importing, open the editor and check the protocol, address, port, and identity fields. Then verify the security type, server name, transport, path, or service name. For REALITY, also confirm that the public key, short ID, fingerprint, and flow control were preserved. A correct-looking profile name only means the label was recognized; it says nothing about whether the underlying parameters are complete. This check is especially important when migrating a configuration from another device.
Special characters in URLs may need percent-encoding. If symbols in a password, path, or name are split incorrectly, parsing can change. Don't replace encoded characters at random to “fix” a link. Instead, copy the full original again or use a file import method supported by the client. When sharing through messaging apps, watch for line breaks, automatically added punctuation, and truncated links. Manual re-entry is best reserved for clearly specified parameters you can check one by one.
Format conversion can change meaning
Converting one subscription format to another isn't as simple as changing a file extension. The target format may not support a particular flow-control mode, fingerprint, DNS behavior, or routing rule, and the converter may use different defaults. The result may start successfully but no longer preserve the original traffic routes or security conditions. Before converting, check the target client's capabilities and compare key fields before and after, rather than checking only whether the configuration counts match.
A complete runtime configuration isn't the same as a single share link. Runtime configurations may contain local inbounds, multiple outbounds, routing, and DNS, while a share link usually covers one remote connection. Migrating a full configuration to another device can bring along unsuitable listen addresses or platform-specific settings; sharing only one connection may omit routing rules the original setup depended on. Choose an export method for the migration and identify which settings need to be configured again on the new device.
Before updating a subscription, separate remote content from local edits
Subscription updates usually follow the remote content, and local edits to subscription entries may be overwritten on the next update; the exact behavior depends on the client. To keep a change long term, copy it into a separate configuration or group using a method the client supports, and label its purpose. Keep test entries separate from everyday subscriptions so it's clear which entries still match the server after an update. Keeping a recoverable backup before making changes is more reliable than recreating fields from memory later.
Subscription URLs and exported identity parameters may grant access to a service, so treat them as sensitive information. Redact full subscription URLs, user IDs, passwords, and similar details from troubleshooting screenshots. A public key isn't the same as a private key, but there's still no need to share it alongside other configuration details. If an update fails, distinguish between failure to reach the URL, failure to parse its contents, and failure to connect after import; each points to a different cause. For the basic workflow, follow the subscription import and connection guide.
08 / Choose by Use Case and Troubleshoot by Layer
Check compatibility first, then compare the experience
Narrow your choice with three questions: which complete combinations does the server provide, can your devices support them, and what connection capabilities does your workload need? On desktop, start with v2rayN and confirm which core is actually running. On Android, if the service requires Xray-specific features, use v2rayNG to configure the necessary parameters; for V2Fly-based service configurations, check v2flyNG support. Choose a client for capability fit, not as a ranking by name.
For everyday browsing and office work, favor setups with clear configuration distribution, well-defined certificate or key management, and an easy way to recover after updates. If you already have a stable configuration, keep it as a reference and test new setups separately rather than overwriting it. For services shared across devices, use a combination every device can represent in full. If one device can import it only by omitting essential parameters, choose a setup all devices support instead of treating the missing fields as normal compatibility.
For real-time communication, gaming, or other UDP workloads, check support across the entire path: can application traffic reach the client, does local access carry the request, does the protocol outbound support it, and will the server allow and forward it correctly? A browser loading a web page doesn't prove the UDP path works. TUN isn't a universal fix for every application; it changes which traffic is captured and still depends on routing, name resolution, and remote capabilities.
When a connection fails, trace the data path
First check whether the core starts. If logs report an unknown field, unknown protocol, or rule-loading failure, address the configuration syntax, implementation support, or rule data first; don't change the remote password yet. Next, check whether a connection to the server is established: an unresolvable address, a timeout, and a refused connection point to different causes. Then check the security handshake and proxy authentication. Verify the name, system time, certificate, public key, short ID, or identity parameters according to the specific log message.
Fourth, check whether requests take the expected outbound route. The client may show as running while an application ignores the system proxy or a request is routed directly. Confirm the local listen address and port, check whether the application has its own proxy setting, and see which rule matches the destination domain. If domain access fails while address access behaves differently, investigate DNS and domain strategy. Disabling certificate verification won't fix an unrelated problem.
| Use Case | Priority | Test |
|---|---|---|
| Everyday Desktop Use | Complete import, matching core, clear routing | Check fields and access a fixed destination |
| Long-running Android Background Use | Stable network, sensible background settings | Check recovery after screen-off idle |
| Migration Across Devices | Full combination supported on every device | Compare key fields after import |
| Real-time and UDP Workloads | Support across the full path to the server | Test with the actual application |
Use the right guide for the problem
If the local port fails to start, follow Troubleshooting a Local Port Conflict and update any programs that depend on the port. For first-install and directory issues, see the First Install Checklist. These are local runtime issues; changing protocols usually won't help. If the problem is DNS resolution or split routing, read the DNS Split Routing and Resolution Guide instead of repeatedly recreating the same connection profile.
When documenting an issue, note the device OS, client name, actual core, protocol combination, access method, and a redacted error summary. Describe when it happens—for example, only with the screen locked, in one app, or for a particular type of destination. Change one variable at a time and record whether you can revert it. This makes it easier to distinguish an intermittent network change from a reproducible configuration error, avoid retesting ruled-out causes, and reduce unnecessary reinstalls and migrations.