Proxy Protocols and Choosing a Core

Configuration layers: a protocol is not a complete connection

Break a node into four groups of settings

A node in a client is more than a protocol name: it is a set of connection settings that work together. The first group is the server address and port, which determine where traffic goes. The second is the proxy protocol and authentication details, which determine how each side identifies the request. The third is the transport, which carries proxy data. The fourth is the security layer, which encrypts the connection and verifies the peer. A subscription bundles these settings for import, saving you from entering them manually, but the layers still depend on one another.

For example, VLESS can use different transports and can be paired with TLS or REALITY. Seeing “VLESS” does not tell you which security layer is in use; seeing “TCP” does not tell you which proxy protocol runs over it. A client might label the transport field “Transport,” “Network” or “Transport protocol.” The wording varies by interface, but it should not be confused with the protocol type shown at the top. When troubleshooting, keep the original configuration and check each layer in turn. That is more useful than changing dropdowns at random.

Trace interface settings to the actual connection

Each transport can have its own parameters. WebSocket commonly uses a path and Host; gRPC commonly uses a service name. These fields are not comments, and you cannot infer them from how a domain looks. The server address establishes the underlying connection, Host may route requests at a higher layer, and SNI indicates the server name during the TLS handshake. These values may be the same or differ, depending on the deployment. Preserve every value provided by the subscription and verify each one; do not replace them all with the server address.

System proxy settings and routing rules belong to a different layer. The system proxy determines whether apps that honor system settings send requests to the client; routing rules decide whether requests that reach the client go direct or through the proxy. Correct node settings do not mean every app is using the node, and an enabled system proxy does not guarantee that routing sends traffic to it. When troubleshooting, first confirm that requests reach the client, then check whether the protocol handshake succeeds. This avoids mistaking an app routing issue for a protocol incompatibility.

How to read errors without changing the wrong settings

A “connection refused” message usually means you should first check the endpoint and whether the server is listening. For name resolution failures, start with DNS. For certificate errors, check the security layer. For authentication failures, review the protocol fields. These clues are not definitive, but they help you choose where to start. Don’t retry based only on the final line of a log; keep the surrounding context from the same connection attempt, and record results from your computer and phone separately. The same node name can follow different processing paths on devices running different cores.

When asking for help, share the client name, core, protocol, transport, security layer and a redacted error message. Do not reveal user IDs, passwords, full subscription URLs or QR codes. A node label can be anything; it does not tell you what the underlying settings are. The useful evidence is in the fields shown in the editor and the runtime result after the core accepts the configuration. The sections below follow the same layered approach: first the protocol, then transport, security and client implementation.

VMess vs. VLESS: authentication and encryption trade-offs

VMess: background and existing configurations

VMess was an important early proxy protocol in the Project V ecosystem. Its design handles user authentication, request encapsulation and data protection within the protocol. The client and server use an agreed user ID to identify a connection, and VMess can work with different transports. Its long history has left a large body of configuration examples and subscription samples, spanning multiple implementation eras. When reading older guides, matching field names do not guarantee that their authentication settings work with your current client.

For modern VMess configurations, check the AEAD authentication method. Extra ID fields found in older configurations are a legacy compatibility concern; don’t fill them with nonzero values just to copy an old guide. The user ID must match the server, and the system clock must be accurate. If authentication fails, first check whether the subscription is current and the ID is complete, then verify time synchronization and client compatibility. Switching transports usually will not fix mismatched authentication settings.

VMess data encryption settings and TLS are separate. The former is part of the proxy protocol; the latter is an outer security layer for the connection. When an interface shows “auto,” it generally means the implementation chooses a supported option based on device capabilities. It does not mean the server accepts any combination of settings. If an existing subscription works, there is no need to disable a setting just to remove an encryption layer. To reduce resource use, first obtain the complete setup supported by the server, then compare under the same conditions.

Why VLESS relies on an external security layer

VLESS focuses on streamlined authentication and request handling, without the same built-in data encryption mechanism as VMess. So any discussion of VLESS security must also specify the security layer it uses. Over the internet, use a TLS or REALITY setup explicitly supported by the server. Assuming that a simpler protocol name means it is inherently safer or faster overlooks the roles of the security layer, transport and server implementation.

The user ID, encryption field and flow control field in a VLESS configuration each have a distinct purpose. A common encryption field is none. This describes the VLESS protocol’s internal encryption choice; it does not mean the whole connection lacks TLS protection. Flow control is an additional feature of specific implementations. For example, the Vision flow control required by a server must be supported by both the client and its core. Flow control is not a universal speed boost, and the same value should not be applied indiscriminately to every transport.

How to choose between them in practice

If your current VMess configuration is reliable and you have no compatibility or performance issues, keeping it is a reasonable choice. If a new configuration explicitly provides VLESS with a modern security layer, first check that your current core supports the full combination. For a fair comparison, keep the server, transport path and test workload as consistent as possible; otherwise, differences may come from different routes rather than the protocol. Two nodes from different providers cannot show that one protocol is always faster.

Migration also requires consistency across subscriptions and devices. A VLESS combination that imports on your computer may include fields an older parser on your phone cannot recognize. Keep the original node on one device, import the new configuration, and check authentication, domain access and the apps you need before rolling it out elsewhere. If only one client fails, compare flow control, security layer and fingerprint fields rather than immediately generating a new user ID. The right choice comes down to whether both ends can correctly use the complete configuration.

Trojan and SS: different approaches to security encapsulation

Trojan’s reliance on TLS

Trojan’s basic approach is to carry proxy requests over a TLS-protected connection and authenticate proxy access with a password. Unlike designs that put encryption inside the protocol, Trojan relies directly on a mature TLS implementation. For a Trojan node, the certificate name, trust chain and system clock are essential to establishing the connection, not peripheral details. A correct password only suggests that the authentication details may be right; it does not mean the TLS handshake succeeded.

The server address may differ from the name on the certificate. If the server requires a specific SNI, enter the name it provides. With a trusted certificate, the system must also be able to establish a valid trust chain. Turning on “skip certificate verification” may change the error, but it also disables an important identity check and is not a routine fix. Check the name, system clock, certificate chain and whether the subscription still points to the right server.

Trojan can also use different transports, so a “Trojan node” may include more than an address, port and password. Preserve any path, Host or service name included in the subscription. A client may display the protocol but omit extra parameters, letting the import succeed while the connection fails. Check the specific combination, not just whether Trojan appears in a support list. For handshake issues, follow the TLS and certificate error troubleshooting guide to check each setting.

SS encryption methods define compatibility

SS is a common abbreviation for Shadowsocks, designed for straightforward encrypted proxying. A typical setup needs the server address, port, password and encryption method. The encryption method is part of how the protocol is interpreted, not a local preference you can change at will. The client must implement the method used by the server. Even with the right password, a different method will prevent communication. Preserve the exact method string from the subscription, including hyphens and numbers; don’t choose a similar-sounding one from memory.

Common configurations use AEAD methods, alongside newer options with their own key and session designs. Requirements for passwords or key material can differ between methods. Don’t use an ordinary password where another method expects an encoded key. Older methods may also have been removed or restricted in current implementations. Being able to open an SS editor only shows that the client supports some SS configurations; it does not mean it accepts every legacy method and extension.

Transport extensions also matter. Some SS share links include extra parameters, but the clients and cores listed on this site may not support those extensions. Ask the configuration provider for a compatible connection setup instead of deleting parameters and assuming the result is equivalent. Removing a parameter may stop an error from appearing in the interface while changing the encapsulation the connection requires. Compare the imported result with the source, especially the encryption method and any additional transport details.

A simpler setup does not automatically mean lower overhead

A basic SS setup has few fields, making it suitable when the server’s method is known and you need standard proxy forwarding. Trojan is suitable when the server has a working TLS setup and can manage certificates correctly. Both can handle everyday web browsing, but suitability for a particular app also depends on UDP support, how the client receives traffic and routing settings. Fewer fields do not automatically mean longer battery life; connection count and background activity often matter more.

When choosing a setup, first check whether your needs include real-time calls, gaming or other tasks that depend on UDP. Then confirm that the client, core, server and transport path all support that traffic. A website loading successfully does not prove UDP works. If your existing SS setup meets your needs, there is no reason to migrate just because another protocol has a newer name. If the target combination depends on a feature your current core lacks, switching to a compatible configuration is usually more effective than repeatedly changing local fields.

TLS and REALITY: checking security settings

TLS verifies the peer

TLS does more than make data unreadable in transit; it also authenticates the peer. Normal verification checks whether the certificate is valid, matches the expected name and chains to a trusted issuer. An inaccurate system clock can make a valid certificate appear not yet valid or expired. A wrong server name can trigger a name mismatch. Fix the clock and configuration source first instead of overriding all checks with an option that ignores errors.

SNI indicates the requested server name during the handshake, and certificate verification also needs the correct name. In a graphical client, the setting may appear as “Server Name,” “SNI” or another security option. The connection address can be a domain or an IP, but that does not mean SNI must match it. When a server hosts multiple services on the same endpoint, the name may even affect request routing. Use the value from the subscription; don’t mechanically copy the address into the security name field.

ALPN negotiates the application-layer protocol, while fingerprint settings affect the specifics of the client handshake. Neither is a universal speed boost. Match the combination required by the server; if there is no requirement, don’t copy settings from another node. Some clients use preset names for handshake fingerprints, but support depends on the implementation. A setting that can be saved by the interface is not necessarily supported by the current core. For startup failures, check configuration loading errors; for handshake failures, check negotiation with the server.

REALITY is not a proxy protocol

REALITY is a security layer, not a proxy protocol on the same level as VMess, VLESS or Trojan. Common configurations pair it with VLESS, but supported combinations depend on the specific core implementation. Read a node as a complete set of protocol, transport, flow control and security layer. A label that says REALITY does not reveal every required field or guarantee compatibility with another client.

REALITY client settings commonly include a server name, server-provided public key material or related authentication fields, a short ID and a handshake fingerprint. Field labels may change as clients and cores evolve, so map them according to the current configuration instructions. The short ID is not a node label, and public key material cannot be replaced with an ordinary password. If anything is missing, request it again from the configuration provider. A server private key should never appear in a client subscription for end users or in a public troubleshooting screenshot.

Troubleshoot the security layer with minimal changes

Refresh the subscription first, then open the failed node’s editor and check the security layer type. If the node should use REALITY but imported as standard TLS, suspect a parsing compatibility issue before trying to fix it by manually adding a server name. Then check the fingerprint, authentication material, short ID and flow control. Change only one field at a time, and only with a clear reason; keep the original configuration. Changing several settings at once may occasionally make the connection work, but it makes the real cause harder to identify and the result harder to reproduce on other devices.

If the same subscription works on your computer but not your phone, compare core support and which fields were preserved. Investigate differences in network access only after confirming that all parameters match and the implementations support them. REALITY is not a universal fix for connection errors, and TLS does not automatically mean a configuration is outdated. A security layer should be maintainable, verifiable and suited to the actual deployment.

Performance and battery life: separate latency, throughput and background overhead

Connection speed is more than one metric

“Fast” means at least three things: the time from connecting to receiving the first valid response, throughput during sustained transfers, and how often the connection drops over time. The first depends on DNS lookup, network round trips and the handshake. The second depends on line capacity, congestion, server load and local processing. A good result on a quick node test does not guarantee faster large downloads or fewer interruptions during a call.

Protocol design affects authentication, encapsulation and encryption overhead, but that overhead’s share of total time varies. On a high-latency network, an extra connection round trip may matter more than local encryption. On a less powerful device, encryption and memory copying may limit high-throughput tasks. There is no protocol speed ranking that holds for every device. For a more reliable comparison, rule out differences in network route and server first, then test complete configurations against your own workload.

Transport also affects performance. WebSocket adds encapsulation and request handling; gRPC has its own transport and negotiation process; a direct TCP setup is generally more straightforward. However, an intermediary may support only certain transports. In that case, the extra encapsulation is part of the deployment, not waste you can simply remove. Check deployment requirements before optimizing. If the server requires a path and upstream routing, switching the client to direct TCP will usually just break the connection.

Resource use depends on the whole workload

CPU use may come from encryption, but also from logging, traffic statistics, rule matching and many short-lived connections. Hardware accelerates different encryption algorithms differently, so the same algorithm may have different costs on two devices. Memory use depends on connection buffers, DNS cache, rule data and the graphical interface. When comparing clients, distinguish the interface process from the core process. A total from one snapshot in Task Manager is not a fixed cost of the proxy protocol.

Connection reuse can reduce the cost of repeated handshakes, but it may also make multiple requests share one transport connection, allowing packet loss to affect them together in some cases. Some protocols and flow control combinations have specific reuse limitations, so enabling reuse is not a universal performance recommendation. Check the provider’s requirements and core support, then test multiple-tab browsing, sustained downloads and your actual apps. Improving one test while making everyday connections less responsive is not a useful optimization.

Mobile battery life depends heavily on network behavior

Phone battery use is not just about the encryption cost of each packet. Wireless wake-ups, frequent reconnects, overly frequent keepalives, continuous speed tests and large numbers of background domain requests can all increase drain. Weak signal also raises the cost of network use. To save power, first reduce unnecessary automatic tests and retries and check that subscription updates are not too frequent. Then consider the protocol. Don’t keep every connection constantly active just to get more aggressive keepalives.

On Android, system battery management may restrict a client in the background. This can look like a node disconnecting when the process or network activity has actually been paused. Check the device’s battery settings for background permissions for v2rayNG or v2flyNG, then see whether interruptions continue. There is no need to remove restrictions for every app. Allow the client responsible for the proxy connection to run as needed, then compare battery use over a day with similar usage.

For a practical comparison, use similar network conditions, keep the test task fixed, and record first launch, sustained use and recovery after standby. Change one major variable at a time and keep the original configuration for rollback. Before testing, disable batch speed tests and reduce other downloads; avoid changing routing or DNS at the same time. If the configurations use different servers, describe the results as how those two setups performed in your current conditions, not as proof that a protocol is always more efficient or reliable.

V2Fly and Xray: core families and configuration compatibility

What the client interface and proxy core each do

Project V provides useful ecosystem context for these tools; V2Fly and Xray are related proxy core projects. A core parses configuration, establishes proxy connections, applies routing and processes traffic. A graphical client manages subscriptions, edits settings, starts the core and shows runtime status. They are different layers. Seeing a protocol name in the interface does not mean the running core supports every related feature, or that it accepted the generated configuration.

v2rayN is this site’s recommended desktop client, with support for Windows, macOS and Linux. Choose a core based on the actual installation package and the options shown in the interface. On Android, v2rayNG primarily uses the Xray core; v2flyNG is an alternative for V2Fly core setups. The three clients do not have identical menus or editable fields, so a field’s location on desktop does not tell you where to find it on a phone. See the client downloads for four platforms.

Shared origins do not make configurations interchangeable

V2Fly and Xray share some technical roots, and their basic configurations use similar concepts, such as inbounds, outbounds, routing and DNS. As the projects have evolved separately, protocol extensions, transport implementations, default values and field semantics may differ. For REALITY, specific VLESS flow control or other extensions, check the target core’s documented support. Two files both being JSON does not mean you can swap them without changes.

Valid JSON syntax only means the brackets, commas and strings are correctly formatted. The core must also check that fields are valid, combinations are allowed and the required implementations are available. The following is a complete outbound object from an Xray configuration, included to show where the protocol layer sits. It is a direct outbound, not a proxy node or a complete client configuration that can run on its own. When adding it to the outbounds array, you still need the other settings.

{
  "tag": "direct",
  "protocol": "freedom",
  "settings": {}
}

In this object, protocol describes the outbound behavior, while tag is a label for routing rules to reference. Changing the label alone does not change the protocol; if a route still references the old label, the configuration may fail. Similarly, transport and security fields in a proxy outbound must follow the structure expected by the relevant core. Graphical clients usually generate these settings for you, so subscription users should manage them in the client rather than combining snippets from different cores.

Define the migration scope before changing cores

Before switching cores, back up subscription groups and custom settings, then test a known-working node on a small scale. Check the protocol, security layer, transport, flow control, DNS, routing and UDP requirements, and confirm the target core can express them all. After switching, don’t just check whether the main screen says it is running. Check logs for unsupported fields, rule-loading failures or outbound initialization errors. A running core process does not mean every feature is working.

DNS and routing settings are particularly prone to subtle differences between cores. Some domain resolution policies, rule ordering and data file requirements do not map one-to-one. A client may convert some settings for you or require a different preset. After migration, test destinations that should use the proxy and those that should connect directly, then check domain resolution and any apps that need UDP. Opening one webpage is not enough to catch routing mistakes or background app issues.

Don’t switch back and forth between cores just to get one feature. Choose a stable configuration that covers your main use cases, and keep a copy of the settings for rollback. If a node requires a specific Xray extension, use a client setup that explicitly supports it. If your existing V2Fly configuration continues to meet your needs, you can keep using it. Choose a core based on feature and configuration compatibility, not because a project name sounds newer.

Subscription formats: a successful import does not guarantee all fields are present

Tell subscription URLs, share links and configuration files apart

A subscription URL is an endpoint for retrieving a set of configurations. A share link usually describes one node. A configuration file may also include inbounds, routing and DNS settings. All three can help transfer configuration, but they are different kinds of data. Importing a subscription URL as a single-node link, or pasting a complete configuration file into a share-link field, may result in an empty list or a parsing error. First identify what you have, then choose the matching import option in the client.

Common share links start with prefixes such as vmess://, vless://, trojan:// or ss://. The prefix tells the parser which rules to use, but it does not guarantee that every extension parameter follows a standard. VMess links often contain encoded structured data; VLESS and Trojan commonly use query parameters for transport and security settings; SS also has multiple encoding formats. One tool recognizing a link does not mean every client parses it the same way.

A subscription service may return multiple encoded links or a client-specific format. Seeing a long block of text in a browser does not tell you whether it works with your client. The response might be a login page, error message or expiration notice, even if the download appears to succeed. Check the entries parsed by the client and its logs. If an update leaves you with no nodes, keep the existing group for now rather than deleting all old settings and losing your fallback.

Fields worth checking after import

The address, port and user ID are usually easy to spot. Easy-to-miss fields include flow control, fingerprint, security layer name, WebSocket path, Host, gRPC service name and REALITY authentication parameters. When a new format reaches an older parser, the parser may ignore fields it does not recognize instead of rejecting the whole link. The node may still appear in the main interface and open in the editor, even though required connection details are missing.

Subscription updates usually fetch the source configuration again. If you edit a node managed by a subscription directly, the next update may overwrite your changes. Behavior varies by client, so a one-time manual edit is not necessarily a permanent fix. To compare settings, make a separate test node if the client allows it, and give it a clear name. If the source is the problem, fix it there or use a compatible endpoint instead of repeating the same edits after every update.

Update methods and syncing across devices

Whether to update a subscription through a proxy depends on the current connection. In v2rayN, related menu items include “Update all subscriptions (without proxy).” If your existing proxy is unavailable, making the update depend on it can create a loop of failures. In some environments, updating directly may fail too, so compare the update methods available in the client. After changing the method, check the specific error and distinguish connection, authentication and parsing failures instead of repeatedly clicking Update.

Using one subscription on multiple devices does not sync all local settings. A subscription usually provides the node list; system proxy, app access, routing and DNS still need to be configured on each device. Custom rules on your computer do not automatically appear when you import the same URL on your phone, and a QR code export may contain only one node. For transfer options, see how to sync subscriptions between computers and phones. For update issues, see the subscription update troubleshooting checklist.

Choose a setup for your needs

Everyday desktop and mobile use

For a first desktop setup, start with v2rayN and choose an installer for your operating system and processor architecture. Don’t pick a protocol name first and then hunt for a configuration. Check which complete setups the server actually provides, rule out those your current core does not support, then compare reliability. For browsing, documents and everyday apps, reliable DNS, correct routing and solid connection recovery usually matter more than theoretical differences between protocols.

On Android, v2rayNG is the primary choice; consider v2flyNG when you need a V2Fly-compatible setup. On a phone, first check background operation, battery management and recovery after network changes, then test sustained transfers. If problems start when the device switches between Wi-Fi and mobile data, check whether the client reconnects before changing a password or user ID. Connection recovery is runtime behavior; authentication details usually do not change when the network changes.

Choose for your workload, not by protocol name

If your existing VMess or SS configuration meets your needs, continuing to use it with a compatible, up-to-date client is a low-effort option. To use VLESS, REALITY or specific flow control, get the corresponding server settings and confirm that the target core supports them. With Trojan, pay close attention to the TLS name and certificate requirements. There is no protocol ranking that works for everyone: the same protocol can perform very differently with another transport, security layer or server.

Be especially careful with tasks that depend on UDP. A protocol’s stated ability to handle UDP does not mean the client entry point, server forwarding and target network all support it. A system proxy also does not guarantee that every app sends traffic through the client; some apps have their own proxy settings or connection methods. First follow the Getting Started guide’s connection and verification steps to confirm where traffic enters, then test in the app you intend to use. A browser loading successfully is not a substitute for testing your actual workload.

A complete selection and rollback workflow

First, list your requirements: platforms, app types, whether you need UDP and whether the client must run in the background. Next, record the source configuration’s protocol, transport, security layer and extra parameters, and confirm the client and core support them. Then import one test configuration, check the startup log, and verify domain access, routing rules and real workloads separately. Finally, check recovery and resource use under similar network conditions instead of relying on a single quick speed test.

If something fails, narrow it down in this order: did the request reach the client, can it connect to the address, did the security handshake succeed, did proxy authentication complete, and are routing and DNS correct? Change only one setting at a time, with a clear reason, and record what happens before and after. For domain request issues, see DNS testing and split-routing settings. For fundamentals, read 10 beginner questions about subscriptions, nodes and cores. Don’t let troubleshooting turn into random combinations of settings.

Keep the original subscription group or a separate configuration before putting the new setup into everyday use. Remove duplicates only after confirming that the new setup covers your main apps. After updating the client, run a brief regression check, especially for custom routing, DNS and core selection. If the new setup improves only one test but causes more background interruptions or compatibility issues, rolling back is perfectly reasonable. A maintainable configuration makes the source of every important field clear and can be reproduced on other devices.