Proxy Protocols and Core Guide

Where the client, core, and server fit

The graphical client displays server lists, reads share links, manages subscriptions, and saves settings. The core handles inbound listeners, applies routing rules, connects to remote servers, and forwards traffic. The remote server accepts connections using the agreed protocol. An option appearing in v2rayN does not mean the selected core supports it. Likewise, a client importing a link does not mean the server accepts every parameter it contains. To check compatibility, verify how the client interprets each field, what configuration the core actually generates, and which combinations the server allows. The protocol name shown in the interface alone is not enough.

A local app usually connects through the system proxy or a virtual network interface before the core forwards its traffic to a remote server. A browser connection can fail at any stage: the local entry point, name resolution, route selection, remote connection, or destination site. The protocol is only one part of that chain. Blaming every failure on VMess or VLESS can obscure more immediate causes, such as a port conflict, an inactive system proxy, or a routing rule matching the wrong traffic. For an initial test, use one app and one destination. Confirm the request reaches the client, then identify where it fails. Don't change nodes, DNS, and routing all at once.

Proxy protocols, transports, and security layers

VMess, VLESS, Trojan, and Shadowsocks define how the proxy endpoints identify users, specify destination addresses, and encapsulate data. TCP, WebSocket, and gRPC are transport options; TLS and REALITY provide outer security mechanisms. VLESS and REALITY are not peer protocols to compare directly: they can be used together on the same connection. Likewise, WebSocket does not automatically mean VMess, and TLS does not necessarily mean Trojan. Compare complete configurations rather than ranking names from different layers by speed.

Connection address, server name, and app destination

The connection address tells the client where to establish its network connection. The server name is typically used in the security handshake and identity verification. The app destination is the site the browser originally wanted to reach. They may sometimes use the same domain, but they serve different purposes. Changing the connection address should not also overwrite the server name; changing the WebSocket Host does not change the app destination. With a reverse proxy on the server, the path, Host, and server name may all affect forwarding. Missing one of these values can leave the endpoint reachable while preventing requests from reaching the right service—not just cause an account error.

When reviewing a configuration, first record its layers: the protocol, the transport, whether outer security is enabled, and where authentication fields come from. Leave unfamiliar settings unchanged and keep a copy of the original import. Short field names in share links do not always match interface labels word for word, so don't swap settings just because their names look similar. The most reliable references are the complete parameters from the server and the meanings documented by the core. The following sections use this layered approach to explain design trade-offs and what to check in a client.

VMess: authentication and data protection

VMess is part of the Project V protocol ecosystem and incorporates user authentication, request information, and data protection into its design. Common configurations use a UUID to identify the user and include a corresponding encryption choice. Newer implementations use AEAD authentication; legacy IDs and older authentication settings found in outdated guides are not universal recommendations. After importing a configuration, let the client generate settings in its current format instead of reverting to old fields to match a historical screenshot. Keep the device clock accurate, too: if authentication is time-sensitive, a significant clock skew can cause authentication to fail even when the network is reachable.

Whether VMess is a good fit depends mainly on support from your existing server and client. If your VMess service works reliably, there is no need to switch just because another protocol has a newer name. Check that the transport, user ID, encryption settings, and outer security match. VMess works with different transports, and the connection overhead varies with the combination. You can't compare a VMess connection with multiple layers of encapsulation to a direct transport on a different route and attribute the whole difference to the protocol. At a minimum, keep the server, destination, network, and test method consistent.

Trojan: proxy authentication over TLS

Trojan carries proxy requests inside a TLS connection and uses its own authentication information to identify users. It does not use UUID as a universal account identifier; clients typically require a password. You still need to distinguish the remote address from the server name and check that the certificate matches the name. Establishing a TLS connection does not mean proxy authentication succeeded, just as a correct password cannot fix a certificate name mismatch. Read logs for these as separate stages. Don't disable certificate verification as a routine setup step; doing so weakens the client's ability to verify the remote server's identity.

Trojan is often considered to have a relatively compact set of configuration fields, but its maintenance complexity still depends on certificates, domains, and server deployment. Connection reuse, transport extensions, and external forwarding can add requirements. A client supporting Trojan does not necessarily support every extension combination with a similar name. Before migrating a configuration, confirm the exact server implementation and transport, then check that the client preserves the password and server name. Passwords can contain characters that require URL encoding, making this an easy place to introduce errors when assembling a share link by hand.

Shadowsocks: the method and key must match

Shadowsocks usually uses a compact configuration for proxy connections. Key fields include the server address, port, encryption method, and password. SS is just a shorthand for the protocol family, not a specific method. Classic AEAD methods and the newer Shadowsocks 2022 methods differ in key requirements and implementation support; the latter cannot simply use any password of arbitrary length. A client that recognizes an SS link may still lack support for the method it specifies. If import succeeds but the connection fails, check the method name and key format before repeatedly changing the server address.

These three protocols each handle authentication and forwarding, but field count alone does not determine security or resource use. A shorter configuration isn't necessarily more power-efficient, and extra layers don't necessarily make a connection slower. For an existing service, prefer a complete configuration that the client clearly supports. If you need to maintain several devices, consider whether they can all use the same format. For a broader comparison of these four proxy protocols, see Choosing between VMess, VLESS, Trojan, and Shadowsocks, then read the next section to understand VLESS's security boundaries.

VLESS is not a complete encrypted connection

VLESS is designed to keep the proxy protocol itself lean and delegate some responsibilities to outer mechanisms. User identification typically still uses a UUID, but its behavior is not interchangeable with VMess encryption settings. In common VLESS configurations, encryption: none means that no additional data encryption method is selected at the protocol layer; it does not automatically mean the entire connection is unprotected. To determine whether the full connection is protected, check for TLS or REALITY in the transport settings. Conversely, if there is no outer security mechanism, don't assume encryption just because the protocol is called VLESS.

When discussing VLESS, specify the full combination—for example, VLESS with TLS or VLESS with REALITY—and state the transport. Different combinations have different server requirements, handshake fields, and core support. The flow option is not a universal speed boost; it identifies a specific flow-control mode and must match the server and transport. Setting xtls-rprx-vision at random will not give an unsupported combination that capability. If the original link lacks this field, don't add it based solely on a screenshot in a guide.

REALITY verification material on the client

REALITY is a secure transport mechanism, not a separate user-account protocol that replaces VLESS. In common Xray client configurations, check the server name, public-key verification material, short ID, and fingerprint settings. Labels vary by client and core configuration model, and share links may use abbreviations. Check what each field means after import rather than relying on its label alone. Client-side material used to verify the remote server is distinct from the private material stored on the server. Never copy server private material into ordinary client settings.

Short IDs are usually subject to hexadecimal format and length constraints; the server determines whether an empty value is allowed. The server name must be among those permitted by the server—it can't be replaced with any familiar domain. Fingerprint settings affect the handshake and are limited by core support; they are not a general-purpose way to change device identity. If the original configuration works but a manually rebuilt one fails, compare these fields one by one, then check for spaces, full-width characters, or missing query parameters. Restoring the original values is easier to troubleshoot than trying several supposed optimizations at once.

How to isolate compatibility failures

If the core exits immediately after you save a configuration, first suspect an unsupported field, malformed parameter structure, or invalid combination. If the core starts normally but the remote handshake fails, check the address, port, server name, and verification material. If the handshake succeeds but apps still cannot connect, investigate routing, DNS, and the destination connection. This order separates local configuration parsing from the network handshake. A security-layer name in the client log only indicates that the corresponding stage is being processed; it does not, by itself, confirm user authentication or application traffic forwarding.

For new desktop configurations, v2rayN with a core that supports the required capabilities is the main option to check. On Android with v2rayNG, verify the capabilities of the core actually in use as well. Don't expect a VLESS and REALITY configuration designed for Xray to work fully with a different core family. If an existing configuration works, first make sure the import tool hasn't dropped any fields before considering a client change. See Section 05 for core support boundaries and Section 06 for preserving fields in share links; both affect whether this combination can be migrated correctly between devices.

Connection setup, response time, and throughput

Connection performance involves at least three distinct questions: how long a new connection takes to establish, how long it takes to receive a response after a request, and how much throughput a connection can sustain. Different factors affect each. Name resolution, TCP setup, the security handshake, and proxy authentication affect the first response; round-trip time, packet loss, congestion control, and server load affect sustained transfers. A protocol with fewer application-layer fields isn't necessarily faster on a worse link. A single speed test can't separate the effects of protocol implementation, server location, and network conditions.

Tests such as tcping usually only show whether a TCP endpoint is reachable; they don't complete proxy authentication or access a destination. A real connection test more closely resembles an app accessing a test URL through the proxy, but results still depend on the test destination and client implementation. These are different metrics. If the endpoint is reachable but a real connection fails, the cause could be authentication, the security handshake, destination access, or DNS—not necessarily an outage. For test steps, see the first connection and real connection testing guide, using the same test destination for each run.

Encapsulation, connection reuse, and resource use

Transports such as WebSocket and gRPC add their own handshakes and encapsulation, while also supporting existing server deployments. Extra encapsulation generally means more structure to process, but whether its overhead is significant depends on request size, connection lifetime, and implementation efficiency. For short requests, connection setup may matter more than sustained data processing; for long downloads, link throughput and packet loss are often more important. There is no fixed ranking that holds for every network, and fewer configuration fields do not necessarily mean lower processing costs.

Connection reuse can reduce the cost of repeatedly establishing connections, but it won't necessarily improve every workload. When several requests share an underlying connection, they are affected by that connection's state; an unstable link or a resource-intensive stream can also affect other requests. Decide whether to enable it based on core support, server capabilities, and workload. Record the default behavior before comparing. CPU use also depends on the encryption method, hardware instructions, traffic volume, and log level. A brief spike in one process does not prove the protocol is unsuitable for the device.

What affects Android battery use

Battery drain on mobile devices comes not only from encryption, but also from wireless radio activity, background wake-ups, connection retries, and app traffic. Repeated reconnects on a weak signal can use more power than normal data processing. With full-device tunneling enabled, apps that wouldn't otherwise use the proxy may also enter the processing chain. Once more traffic is covered, you can't attribute all battery differences to the protocol. Background restrictions can also interrupt the client, triggering reconnections and reauthentication. This may show up as higher standby drain, delayed notifications, or a burst of reconnects after unlocking the device.

For a meaningful comparison, keep the device, network type, apps, and test duration consistent, and distinguish foreground transfers from background standby. Disable repeated speed tests and verbose logging, and check for continuous retries before comparing configurations. When reviewing system battery stats, also check screen, mobile network, and app activity. If you change the protocol along with the server, transport, and amount of traffic covered by the proxy, the results only compare two complete setups; they don't show the protocol's power use in isolation. The same applies when comparing v2rayNG and v2flyNG.

In practice, fix configuration errors, unnecessary retries, and needless full-device tunneling before fine-tuning the transport. For everyday browsing and messaging, a correctly configured, stable setup is usually easier to evaluate than one that is switched frequently. Test sustained throughput and recovery from failures separately for large downloads. Without reproducible test conditions, keeping a working setup is more sensible than changing protocols based on a single screenshot. To isolate a specific error, use the FAQ and check each stage of the failure.

How Project V fits into the ecosystem

Project V is a useful starting point for understanding this ecosystem: V2Ray's configuration model and protocol design laid the groundwork for later tools. V2Fly maintains V2Ray-related implementations, while Xray has developed as an independently evolving core project from related code and technical foundations. Both retain many similar concepts, including inbounds, outbounds, routing, and DNS, but their features and field models evolve separately. Xray is not simply a version-number upgrade to V2Fly, and the two are not interchangeable copies of the same program. Compatibility must be assessed feature by feature.

Clients operate at a different layer. v2rayN provides desktop users with a graphical management interface, while the core in use handles protocol processing. The common v2rayNG workflow centers on Xray capabilities; v2flyNG is an Android alternative built around the V2Fly core. Platform and required features—not just interface preference—should guide your choice. For desktop, start with v2rayN. On Android, check v2rayNG when you need Xray-specific features; for an existing V2Fly configuration, check whether v2flyNG supports it.

Shared configuration structure and core-specific features

inbounds define how the local client receives traffic, outbounds define how it connects outward, and routing determines which outbound handles a request. Similar concepts do not mean every field beneath them is identical. Transport settings, security mechanisms, flow-control options, and DNS behavior especially need verification. Xray-specific REALITY and related connection features cannot be moved to V2Fly just because the outer JSON looks familiar. Some fields may be rejected by the other core; others may have similar names but behave differently.

Routing data resources are not interchangeable just because they serve an abstractly similar purpose. Domain and IP classification tags depend on the resource content actually loaded. Missing files or unavailable tags can cause rules to fail at startup or behave differently than expected. During migration, check both the JSON and the resources and paths in the runtime environment. Relative paths often depend on the working directory used by the client when starting the core; don't carry over an absolute path from another machine. For resources managed by a graphical client, use its update and settings controls where possible, so you know which copy is actually being loaded.

Which layer needs an update?

If the interface can't recognize fields in a link, check the client's import support. If it generates a configuration but the core reports an unsupported option, check core capabilities. If the core runs but can't find a routing tag, check the resource files. These are three different problems. Updating the graphical interface alone may not change the core, and replacing the core may not fix a client that drops fields. Before updating, keep the original subscription and working settings. After updating, test a known-good configuration before restoring complex rules. Avoid changing core families, rewriting a subscription, and importing a whole new rule set in one operation.

Open source means the code can be inspected and used under its applicable license; it does not mean two projects will always share the same configuration format. Choose based on required features, client support, and maintenance—not on the assumption that one family is the only answer for every use case. To understand the parts of a configuration, see A breakdown of the Xray configuration file. To get an installer for another device, return to the download page and choose by operating system and processor. Don't confuse core concepts with package architecture.

Individual share links and link collections

Share links describe a server configuration. Common prefixes include vmess://, vless://, trojan://, and ss://. They do not all use the same internal format. VMess links commonly encode JSON content, while VLESS and Trojan typically express settings through URL user information, addresses, and query parameters. Shadowsocks has also used different formats over time. When importing a link, the client must identify its protocol prefix and parse it accordingly; the decoding method for one link type cannot be applied to another.

A subscription URL is a way to retrieve a set of configurations, not the address of a single server. A subscription commonly returns multiple lines of share links or a base64-encoded collection of those links. Base64 is an encoding, not encryption or a proxy protocol. Decoding successfully only means you got text; you still need to check whether it's in a format your client supports. Line breaks, character encoding, and URL encoding can all affect parsing. Copy the complete URL supplied by the provider, without adding page titles, explanatory text, invisible spaces, or line breaks inserted by an email client.

Native JSON and client-managed configurations

Native Xray JSON can describe a complete runtime setup, including multiple inbounds and outbounds, routing, and DNS. It isn't simply another way to display a set of share links. An individual link usually covers only the main fields needed for a remote connection; it does not include the full local listener setup or complex routing logic. Converting a native configuration to a link can therefore lose global behavior. A configuration generated after importing a link may add the client's own default inbounds and routing. Both configurations may connect, but differ in which traffic they handle, their DNS paths, and rule priority.

A client's own settings file may also contain groups, display names, window state, and speed-test preferences—none of which are part of a core's universal format. Before migrating, decide whether you need to preserve remote server settings or the entire client environment. To move one server to another device, a share format recognized by that client is usually the simplest option. To preserve complex rules, record routing and DNS separately; don't expect a share link to include them. When importing a complete custom configuration, also check whether the client still manages system proxy and port settings. Not every interface toggle can override custom content.

Limits of conversion and updates

Conversion can rearrange existing information, but it cannot supply missing server names, public-key verification material, short IDs, or transport paths. A converter producing valid JSON does not prove that the fields have the right meaning or that the target core supports the combination. Older parsers may silently ignore unknown query parameters for newer transport fields, leaving what looks like a normal server entry in the client. If that happens, compare the imported details with the original parameters. A server name appearing in the list is not proof of compatibility.

Subscription updates usually regenerate entries managed by the subscription, so manual changes may be overwritten next time. For experiments, copy a test configuration into a separate entry and leave the original subscription group untouched; use the client's own options for copying and grouping. Duplicate names after an update don't necessarily refer to the same endpoint; the address, transport, or user parameters may differ. Compare the key fields before deleting anything. If a group suddenly becomes empty, first check the returned content and format. Don't repeatedly delete, recreate, or clear all configurations.

A complete troubleshooting sequence is: confirm the subscription endpoint is reachable, check that the returned text is the expected type, confirm the client recognizes the protocol, verify that key fields were preserved, and then test the core connection. Record format issues separately from remote authentication failures. For an overview of formats and conversion limits, see Subscription base64, native JSON, and share links explained. This page does not provide an online conversion form. Handle sensitive configurations in trusted local tools and clients instead of increasing exposure just to convert formats.

System proxy and TUN coverage

The system proxy gives apps a proxy entry point; only apps that read the relevant settings will use it as expected. Some programs use their own networking stack or proxy settings, so a working browser connection does not mean every program follows the same path. TUN mode captures traffic through a virtual network interface, providing broader coverage but adding requirements around routing, permissions, and DNS. It does not change the proxy protocol or fix remote parameters. If protocol authentication fails, enabling TUN only changes how traffic enters the client; it cannot make the server accept invalid credentials.

Choose “Set system proxy automatically” or “Enable TUN mode” in v2rayN based on the task, rather than enabling every traffic-capture method by default. First test one app that follows system proxy settings, then try TUN if needed; this reduces variables. Windows, macOS, and Linux differ in their permissions, virtual interfaces, and system network settings, so follow the prompts shown by your client and operating system. Android clients rely on the system's virtual network capture and need the relevant permission and background status checked. Avoid running multiple apps that compete for the same type of network entry point.

Rule order, outbound tags, and DNS

Routing rules are usually evaluated in order, and the first matching rule determines the outbound. Put specific rules before broad ones, and make sure outbound tags match actual definitions. domainStrategy controls how routing handles domains and IP addresses during rule matching; it does not define all browser DNS behavior. IPIfNonMatch means that if no domain rule matches, routing may continue by trying to match the IP address obtained through DNS resolution. It does not create geographic routing rules or guarantee that every domain is classified as expected; the result depends on the rules and DNS response available.

The following JSON object fragment belongs in the routing field of a native Xray configuration; it is not a complete runtime configuration. It sends local loopback traffic to the outbound named direct and other TCP and UDP traffic to the outbound named proxy. Both outbounds must be defined first, and the proxy outbound must support the network types used by the requests. This example demonstrates order and tags only. It does not replace a full setup for LAN exceptions, DNS policy, or preventing virtual-interface loops, and should not overwrite all the routing generated by a client.

{
  "domainStrategy": "AsIs",
  "rules": [
    {
      "type": "field",
      "ip": ["127.0.0.0/8", "::1/128"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "network": "tcp,udp",
      "outboundTag": "proxy"
    }
  ]
}

DNS, UDP, and troubleshooting

Domain resolution may be handled by the app, operating system, or core; the path determines what information routing can see. If an app has already resolved a domain to an IP address, the core may no longer have the original domain available for domain rules. Traffic sniffing also has capability and scope limits; it cannot be relied on to recover the domain in every case. Before configuring DNS, identify who sends the query, which outbound carries it, and who uses the result. If resolution depends on the proxy while connecting to the proxy itself also requires resolving its address, a dependency loop can occur. Make sure the remote endpoint has a clear, working resolution path.

UDP requires support from the local entry point, core, protocol implementation, and remote server. If websites work but a real-time app does not, UDP forwarding may be unavailable or routing may not cover the app; the protocol name alone doesn't guarantee support. During testing, first check whether the app's traffic reaches the client, then confirm the network type and outbound actually used. If the remote connection is stable but only some domains fail, check rules and DNS first. If no apps reach the core, start with the local entry point. For more on rule syntax, see Custom routing rules and match priority.

Choosing for desktop and Android

For desktop, start with v2rayN, then choose the right installer for Windows, macOS, or Linux. Windows Desktop and the classic WPF interface are different client variants, not different proxy protocols. On macOS, distinguish Apple Silicon from Intel; on Linux, match the processor and package format. These choices determine whether the program installs and runs correctly, not whether the remote protocol is available. After installation, still check the core and imported parameters. Use the download page to find the right package; don't infer the installer filename from an example in a protocol guide.

On Android, first check which core capabilities your configuration requires. For Xray-specific features, v2rayNG is the primary choice. If your configuration and maintenance workflow specifically target V2Fly, consider v2flyNG. Don't import all app settings between the two just because their names look similar, especially custom JSON and routing resources. Processor architecture is independent of the protocol. Modern devices commonly use arm64, but check the device's actual architecture and confirm the installation. A universal package can't fix a protocol combination unsupported by the core; architecture and feature support are separate checks.

Evaluating options alongside a working service

If your current service is stable, keep its protocol for now and confirm that it meets the needs of your apps and network. Switch only for a clear feature requirement, device compatibility issue, or maintenance problem—not just because the protocol name is different. If the server only offers VMess, selecting VLESS in the client won't create a compatible connection. If the server offers several combinations, you can compare them under the same destination and network. First confirm each combination authenticates successfully, then compare initial response time, sustained transfers, and background stability. Speed-testing a broken configuration only mixes setup errors into the performance results.

When evaluating a new setup, keep a short record of the client, core actually in use, proxy protocol, transport, security mechanism, flow-control fields, DNS, and traffic-capture mode. Change one layer at a time and keep a known-working entry. For long-running background use, check recovery after disconnection and system background restrictions. For many short requests, focus on connection setup and reuse. For sustained transfers, watch throughput, resource use, and recovery from interruptions. Different workloads can lead to different choices; one metric doesn't need to decide every use case.

Go back to the right section for each failure

If import reports an invalid format, return to Section 06 and check the link or subscription format. If the core won't start after saving, return to Section 05 and check support and field structure. If the endpoint is reachable but the handshake fails, return to Sections 02 and 03 to check authentication and security. If only some apps fail, return to Section 07 to check traffic capture, routing, and DNS. If the connection works but battery use is abnormal, return to Section 04 and rule out repeated retries and excessive testing. This sequence is more reproducible than switching protocols repeatedly and makes it easier to describe the issue accurately without exposing sensitive information.

The final choice comes down to four conditions: the server actually offers it, the client can represent it fully, the core explicitly supports it, and it has been tested for your workload. Once these are met, consider your management preferences and resource use. For your first setup, follow the Getting Started guide to import, connect, and test. For a comparison of the three clients, read the Choosing Wisely guide. For a specific issue, see the FAQ. This guide explains the technical limits behind those choices; it does not rank protocols universally, regardless of server capabilities.