Protocols and Core Guide

1. Configuration Layers and Field Mapping

Identify the client, core, and server

The client is the graphical interface for managing configurations. It imports share links, organizes subscription groups, selects servers, and sets the system proxy. The core reads the configuration generated by the client and handles listening, DNS resolution, routing decisions, and remote connections. The server runs the corresponding connection settings. Each has a distinct role: a record that saves successfully in the interface has only passed the interface's checks. That does not mean the core supports every field, or that the server is configured the same way.

A connection can be understood in four layers: the proxy protocol defines authentication and how proxy requests are represented; the transport carries that data; the security layer encrypts and authenticates the external connection; and routing rules decide which requests use it. A subscription URL distributes configuration but is not part of these connection layers. Entering a subscription URL in the server address field, or treating a transport name as a proxy protocol, breaks the relationship between settings and makes troubleshooting harder. First check whether you are editing a subscription group or an individual server.

Don't infer configuration from the display name

A server alias is only a label for identifying an entry in a list, and subscription providers can name it anything. An alias containing a protocol name does not prove that the actual protocol field uses that protocol. Check the type, address, port, identity fields, transport, and security settings in the editor. The address may be a domain name or an IP address; the port is where the remote service listens, not the local proxy port. The local listening port used by a browser and the remote server port belong to separate connections. Changing one will not fix the other.

The transport path and server name are not interchangeable. With web-based transports, the path is generally used to route requests on the server. The server name is used during the security handshake or certificate validation. Some configurations also include a host name in the request headers. These three values may be the same or different, depending on the deployment. They appear near each other in the client for convenience, not because they mean the same thing. Check each value against the original configuration rather than replacing every domain field with the server address.

Make one change at a time to get reproducible results

A subscription usually provides a complete configuration, so changing one layer to suit a preference is rarely appropriate. For example, changing an existing entry's security layer does not give the server support for that layer; changing the transport also requires matching support on the server. To compare two options, get two complete configurations explicitly provided by the server, and keep local routing, test targets, and network access the same. Changing only the type field on one entry is more likely to break the connection than produce a useful comparison.

Before troubleshooting, note the client name, running core, protocol, transport, and security layer. Then record whether the issue occurs during import, startup, handshake, or access. This turns “it doesn't work” into a specific failure point. If the logs show an unrecognized configuration field, check core and format support first. If the core starts but the remote handshake fails, check the address, identity, and security parameters. Changing settings across several layers at once makes it harder to restore a previously working configuration.

2. Trade-offs Among Four Proxy Protocols

VMess and VLESS: Different responsibilities

VMess is an earlier proxy protocol in the Project V ecosystem. Its design includes user authentication and message protection, and common configurations use a user ID as the authentication credential. Historical implementations used different authentication methods; newer configurations generally use AEAD. Extra identity parameters found in older guides should not be treated as recommended values for new configurations. As a client user, import the fields provided by the server and keep the system clock accurate. Some authentication failures are caused by clock skew, not an unavailable route.

VLESS separates responsibilities by keeping the protocol itself simple and leaving transport security to an external security layer in common deployments. An empty encryption field does not mean the entire connection is necessarily unencrypted, nor does it mean security settings can be ignored: protection depends on correctly enabling TLS, REALITY, or another explicitly designed secure channel on the outer layer. VLESS also commonly uses a user ID for authentication, but its identity, encryption, and transport fields are not interchangeable with those of VMess. Treat the security layer and any flow-control requirements as part of the VLESS configuration.

Some VLESS combinations use specific flow-control modes, such as XTLS Vision. A flow-control field is not a universal speed boost and only works when the core, transport, and server all support it. Don't add a flow-control name to a subscription that doesn't include one, or remove it from an existing configuration just to make it fit another core. Either change can affect connection behavior. Choose based on whether both ends support the complete configuration, not just which protocol name sounds newer.

Trojan: Requires correctly configured TLS

A common Trojan setup carries proxy authentication and requests over a TLS connection, using a password as the primary credential. The password authenticates the proxy request; certificate validation verifies the identity of the peer on the secure connection. They are not substitutes for each other. A correct password cannot prevent a connection from failing when the certificate name does not match, and a valid certificate cannot compensate for a wrong password. Check the server address, server name, port, and password separately. Don't treat “allow insecure” as the default fix for every handshake error.

Trojan's fields are relatively straightforward from a user's perspective, but deployment still depends on how certificates, domains, and the server are maintained. Core support for extended transports and optional settings may also vary. A share link named after this protocol doesn't tell you which transport combination it uses. If importing a subscription leaves out a path, drops security options, or includes an unrecognized extension field, check the original configuration rather than assuming every client will fill in the same settings.

Shadowsocks: A lean design with method compatibility requirements

Shadowsocks uses a relatively simple proxy structure. Common configurations rely on the server address, port, password, and encryption method. Each method has its own data handling and key requirements, so don't keep the password and swap in a different method at random. Older methods, common AEAD methods, and newer protocol families are not inherently interoperable. Some methods require a key of a specific length or encoding. A client accepting ordinary text as input does not mean the server will interpret it as the same valid key.

Shadowsocks is often used when fewer configuration layers are desired, but its suitability still depends on the client implementation, server method, and any additional transport components. If a share link refers to an extra component that the client does not support, importing only the base fields is not enough. Include additional components when comparing resource use, too. A simpler structure may reduce some processing steps, but it cannot change remote bandwidth, network congestion, or how an app makes requests.

3. TLS and REALITY Settings

Certificate validation, server name, and time

TLS protects the connection and uses mechanisms such as certificate validation to verify the peer's identity. The server address is used to establish the network connection; the server name is generally sent in the handshake and matched against the certificate. They do not have to be identical, but both must match the server configuration. If you connect by IP address and the certificate is issued for a domain, changing the server name to the IP address may cause validation to fail. Get the required server name from the provider instead of disabling validation to bypass the error.

Certificate validation also depends on the device clock and the certificate chain. If the device date is significantly wrong, a certificate may appear not yet valid or expired. Some environments may also fail to establish trust if the server does not provide the appropriate certificate chain. If several unrelated servers report certificate errors on the same device, check the device clock and network first. If only one configuration fails, check that server's certificate and name. Different causes require different fixes; repeatedly changing the password usually won't help.

Additional matching requirements for REALITY

On the client side, REALITY commonly requires a server name, server public key, and short ID. Its authentication differs from conventional deployments using publicly trusted certificates. The server public key must come from the corresponding server configuration; generating one on the client is not a substitute. The short ID's value and format must also meet the server's requirements. REALITY cannot be enabled simply by switching a security-layer option. The client and core must support it, and the server must be configured for it.

The public key and user ID serve different purposes: the user ID identifies the proxy-layer user, the public key is used for security authentication, and the short ID has a separate matching requirement. Copying one value into another field does not make the configuration equivalent, even if the strings look similar. The interface may also offer a client fingerprint setting that affects the handshake. A fingerprint is not a brand label to fill in arbitrarily: use a value explicitly supported by the current core and keep the combination consistent with the provider's requirements.

Some guides write REALITY, VLESS, and Vision together, which can make it seem as if all three must always be used at once. Understand them separately as the proxy layer, security layer, and flow-control layer, then check which combinations the specific implementation supports. Success with one combination does not prove that every transport supports the same flow control. Nor can a core-specific field be copied to another core with the expectation that it will work the same way. Check the core's actual capabilities, not just whether its interface shows a similarly named option.

Transport paths and negotiation settings

WebSocket configurations commonly use a path and request headers; gRPC configurations commonly use a service name and related mode settings. These usually need to match the server and any intermediary proxy. Even after the security handshake succeeds, an incorrect path or service name can still break the transport. Certificate checks alone won't rule out these errors. ALPN indicates application-layer protocol negotiation preferences, and its values must also match the deployment. Adding more options does not necessarily improve compatibility; it can instead send the connection down a path the server is not prepared to handle.

Before saving security-layer settings, compare every field against the original share link, especially spaces, encoding, and case sensitivity. If you encounter an unfamiliar field, first check whether the client supports it, then whether the core does. A complete configuration does not mean filling every blank field; many options should be left at their defaults or unset. If you need a temporary change for diagnosis, keep a copy of the original and restore it after testing. Long-term security settings should not be based on a one-off successful connection.

4. Speed, Resources, and Connection Overhead

Separate initial connection time from sustained transfer

“Fast” might mean a web page opens quickly, a download maintains a high speed, a video starts promptly, or interactive requests respond quickly. The initial connection may involve DNS resolution, establishing a network connection, a security handshake, and a proxy request. Sustained transfers depend more on bandwidth, congestion control, packet loss, and server load. A combination that reduces handshake steps does not guarantee faster large downloads. Likewise, a route that performs well during sustained transfers may still feel slow to open a page if DNS resolution takes time.

Proxy encryption and encapsulation have a processing cost, but on modern devices they are often not the bottleneck. Differences between protocol implementations and hardware acceleration are more noticeable when the processor is constrained, throughput is sustained, or many connections run in parallel. For everyday browsing, the remote route and destination server may account for most of the time. Don't attribute a single download result to the protocol when server load may have changed, or apply a fixed speed or resource ranking to every device.

Multiplexing and transport encapsulation: what they can and can't do

Multiplexing attempts to carry multiple logical requests over fewer underlying connections. It can reduce the cost of repeatedly establishing connections, but it also changes how concurrent requests share a link. If the underlying connection is blocked or loses packets, several requests may be affected at once. Some transport or flow-control combinations do not work with general-purpose multiplexing; forcing it on may do nothing or cause errors. Start with a combination supported by default on both client and server. Consider supported multiplexing only after confirming that frequent connection setup is actually the problem.

Adding a web transport or other encapsulation layer may help with access or distribution in a particular deployment, but it can also add headers, buffering, and intermediary proxy restrictions. A shorter native connection path is not necessarily more stable on every network; a more complex path through an intermediary is not necessarily slower. To compare configurations, make sure they connect to the same region and server resources. Otherwise, route and protocol differences are mixed together, and your results describe only those two complete routes, not the protocols themselves.

How to interpret latency tests

A basic network probe only shows whether a particular layer is reachable; it does not fully test proxy authentication or access to a destination. A real proxy latency test usually sends a request to a specified target through the full proxy chain, but results still depend on the test address, routing rules, DNS resolution, and timeout settings. A successful test means that request worked; it does not mean every app is using the proxy. If it fails, check which stage reported the error. For a first-time check, see v2rayN: First Connection and Proxy Verification.

For a fair comparison, use the same network, similar times of day, and the same target. Test each configuration individually, then repeat a limited number of times. Don't run several high-bandwidth tasks at once or compare connections while a subscription is updating. Record whether requests complete, whether the initial response is consistent, and whether sustained transfers remain stable. These observations are more useful than keeping only the best-looking number. If results keep reversing between rounds, conclude that there is no consistent difference under the current conditions rather than forcing a winner.

When monitoring resources, distinguish the client interface from the core process. Keeping large logs for a long time, refreshing lists frequently, or running background tests can increase interface load; sustained connections and rule processing happen mainly in the core. Observe both in your system's task manager to avoid mistaking window usage for protocol overhead. Memory growth can also come from connection caches, DNS caches, or rule sets; don't switch protocols based on a single peak. Stop tests and background tasks first, then observe the system at idle.

5. V2Fly and Xray Cores

Shared origins don't mean identical features

Project V established a technology ecosystem for proxy connections, routing, and multiple transports through configuration. V2Fly continues the development of V2Ray-related projects, while Xray evolved as a fork on that technical foundation and expanded protocol and transport capabilities to meet its own goals. They share concepts and parts of their historical configuration structure, so many fields look similar. But as the projects have evolved, their supported features, defaults, and extension fields have diverged. Choose a core based on feature compatibility, not a simple old-versus-new ranking.

For combinations involving REALITY or XTLS Vision, check Xray support and its configuration requirements; don't assume V2Fly handles them with the same semantics. Even for protocols supported by both, verify the specific transport, encryption method, and optional settings. A protocol appearing in a support list does not mean every historical or newer extension for it is available. If a field is unrecognized or the core fails to start, narrow down the specific feature instead of judging compatibility by the protocol family alone.

How the three clients differ

v2rayN is a desktop configuration manager for users who need to view server lists, subscription groups, logs, and routing status. The features it can manage depend on the core in use and how the client integrates with it; the window's name alone doesn't tell you. v2rayNG is for Android and is commonly used with Xray configurations; v2flyNG is an Android alternative for the V2Fly path. The two mobile clients may look similar, but check feature support before moving configurations. They are not the same app with different names.

Updating the client, core, and subscription are three separate actions. A client update affects the interface and configuration generation; a core update affects runtime capabilities; a subscription update replaces or adds server entries from the provider. A successful subscription update does not add features unsupported by the core, and a core update will not fix a bad subscription URL. Before updating, identify which layer needs to change. Afterward, check the logs for the core actually in use and verify that existing connections still work as expected.

Configuration compatibility depends on meaning, not just format

If two files both parse as JSON, that only confirms valid syntax. Field structure, allowed values, defaults, and behavior determine compatibility. Some unsupported fields are rejected during parsing; others may be silently ignored, which is easier to misinterpret. When switching cores, have the target client generate a new configuration from supported share links rather than replacing the entire configuration file directly. Then check custom routing, DNS resolution, and special transports section by section.

Keep a recoverable copy of the original configuration when testing a migration, and first verify a server known to work. Don't update the core, import a new subscription, and change routing all at once, or you'll have no way to identify the cause of a failure. Check startup logs for unknown fields, then verify the security handshake and destination access before migrating complex rules. For features only supported by the original core, keep the existing setup or get a complete alternative configuration from the server provider. Don't try to force startup by deleting fields that trigger errors.

Open source means an implementation can be studied and maintained, but it does not replace checking features in your specific environment. Projects may use different open-source licenses, which govern code use and distribution; they do not directly determine connection speed or server compatibility. This site provides download and documentation links, not the projects' technical specifications. If you only need to check the package platform and CPU architecture, return to the downloads page. For protocol support, use the core and field compatibility guidance in this chapter.

6. Subscription Formats and Import Compatibility

Fetching a subscription and parsing its configuration are separate steps

A subscription URL usually points to an address that returns configuration content. That content may be a collection of share links, encoded text, or a structured configuration. The client must fetch the response, identify its format, and then convert its fields into server entries. So “subscription update failed” can mean a network request failed, the response was in the wrong format, or an individual entry could not be parsed. Opening a URL in a browser only shows that it returned some kind of response; it doesn't prove the content works with the client or that every configuration is supported.

Some URLs return an explanatory web page when authentication expires; others redirect or return empty content. If the client tries to parse a web page as subscription text, it may report a format error or import nothing. Check the complete URL in the subscription group, access permissions, and the provider's format instructions. Don't add the same URL repeatedly as separate groups. Subscription URLs often contain access credentials, so protect them like passwords. When reporting an error, hide query parameters and personal identifiers; the error type is usually enough.

Share links are converted into configuration fields

Share links for different protocols do not use the same internal structure. Some encode a configuration object in the URL; others express fields using user information, host, port, and query parameters. Percent encoding represents reserved characters, and incorrect encoding depth or missing separators during copying can change the parsed result. Don't decode text yourself and save it just because it looks scrambled, and don't replace every plus sign or slash by hand. Start with the client's standard import option and check which specific fields are missing if it fails.

After a successful import, check that the conversion preserved all fields, especially the security layer, public key, short ID, flow control, path, and service name, which different implementations may handle differently. An alias and group appearing in the list do not prove that important settings were preserved. Some clients recognize a base protocol but do not support extension parameters in the link. The entry may look normal while the generated configuration does not meet the server's requirements. Compare the edit window with the provider's instructions, then check startup logs to see whether the core accepted the settings.

Distinguish a complete configuration from a single server entry

A complete configuration with rules, DNS resolution, inbound connections, and multiple outbound connections is not the same as a single server share link. Pasting a full configuration into a single-server import field may fail or import only part of it. Conversely, a single link usually won't include your complete local routing policy. If changing subscriptions doesn't change how local apps connect, routing may be configured separately from server entries. Don't expect a share link to fix local listening, the system proxy, or per-app settings automatically.

Subscription groups help preserve the source of each configuration. After an update, the provider may change fields, remove entries, or rename them. Whether local edits are preserved depends on the client. For experimental configurations you need to keep, first copy them into a separate entry and label their purpose before testing. Copies do not automatically follow changes to the original subscription, so you are responsible for checking them later. You cannot expect full manual control of settings while also assuming subscription updates will always correct every manual change.

If the same subscription behaves differently in two clients, first compare how many entries were imported and whether their key fields match. Don't immediately blame an unstable core. One client may support the format while the other only supports some links; one may fetch the subscription through an existing proxy while the other tries to access it directly. Check “what content was fetched” separately from “how the configuration runs,” then verify the network path. If needed, use a format the provider explicitly offers for your client. Avoid exposing credentials to untrusted online conversion services.

7. Routing, Local Access, and Battery Use

System proxy settings and routing solve different problems

System proxy settings tell apps that honor them which local address and port to send requests to. Once the core receives a request, its routing rules decide whether to connect directly, use a proxy, or block it. Choosing “set system proxy automatically” does not guarantee that every program will use the proxy. Choosing a routing rule won't make an app that never connected to the proxy start using it. If nothing changes in the browser, first check whether it reads the system proxy and whether the local port is correct. Then check which rule matched the request in the core.

Local listening should usually be limited to the interfaces you actually need. If only local apps need access, there's no reason to expose the listener on every network interface for troubleshooting. If you need to share it on a local network, also consider access controls and the device firewall. After changing the listening address, the system proxy may still point to the old one. If another process is using the port, the core may fail to start or create an inbound connection, so the remote protocol never runs. See how to fix a port-in-use error.

Rule order and DNS resolution

Routing rules are usually checked in order, and a request goes to the specified outbound when it matches. Domain rules depend on whether the request retains its domain name; address rules may depend on the resolution result and DNS handling policy. A broad rule placed early can prevent later, more specific rules from taking effect. The snippet below uses Xray-style syntax and shows direct routing for two local domains only. It is not a complete, runnable file; before integrating it, define an outbound named direct and verify the syntax for your core.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:localhost",
          "domain:local"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

Rule matching and DNS resolution are not controlled by the same setting. An app may resolve a domain itself before sending the address to the proxy, or it may send the domain name to the local proxy. The core's DNS policy, system resolver settings, and browser DNS settings may also act independently. If only some domains fail, check whether the actual request uses a domain name or an address, and whether the resolved address is reachable. Changing one DNS setting does not necessarily unify the entire request path. Don't pile on exceptions without understanding rule order.

Android access and per-app proxying

Android clients usually receive app traffic through a virtual network interface provided by the system. This differs from desktop apps that read the system proxy. Enabling a connection requires system permission, and another app using the same access mechanism may cause a conflict. Per-app proxy settings determine which apps enter this path, but the core can still route their traffic directly. Selecting an app does not mean every request it makes will go through the remote server. Leaving an app unselected also means the core cannot use its rules to add it to the connection path.

Battery use can be affected by the protocol, but the protocol name alone doesn't tell you how much power a setup will use. Sustained uploads and downloads, retransmissions on a weak signal, frequent reconnects, overly frequent background checks, and periodic app wakeups can keep the radio and processor active. Two configurations handling different app traffic cannot be compared directly by battery use. When testing, keep app activity and screen state the same, avoid extra tests, and check the system battery report and connection logs. If the connection keeps dropping, find the cause of the reconnects before weakening all security settings.

Exempting a client from battery optimization may keep it running in the background, but it can also allow more background activity. Restricting background activity may save power but affect reconnection after standby. Choose based on whether you need to receive messages continuously. Per-app proxying can limit unnecessary traffic through the connection, but it does not guarantee a fixed reduction in battery use. For more detail, see v2rayNG background and battery settings. After testing, disable background checks you no longer need so diagnostic activity isn't mistaken for normal usage.

8. Choose by Use Case and Troubleshoot by Layer

List your requirements before comparing options

With an existing working subscription, first check what configurations the server actually provides, then whether the client and core support all of their features. On desktop, start with v2rayN to manage and verify connections; on Android, choose v2rayNG or v2flyNG based on the features required by the configuration. If the subscription offers only one supported, stable combination, there is no need to change it just to chase a protocol name. If the server offers several combinations, compare initial response, sustained transfers, background stability, and maintenance effort rather than assuming one option is best for everyone.

For setups where maintenance effort matters, clear fields, a reliable source, and stable updates are more valuable than piling on optional features. For a new security layer or special flow control, use a core that explicitly supports it and get a complete configuration from the server. On less powerful devices, monitor resource use during sustained tasks and avoid redundant encapsulation, unnecessary checks, and too much background concurrency. On mobile devices, include network changes and recovery after standby in your tests; a single connection while the screen is on is not enough to evaluate the setup.

Narrow down the problem from import to access

First check the input and parsing. If a subscription creates no entries, check whether the request succeeded, the response format is correct, and the URL is complete. If an entry appears but the core won't start, check for unknown fields, invalid parameters, and local listener errors. Don't change the remote server yet; the connection may not have started. If you're not sure where to find the logs, see v2rayN main window overview to locate server editing, the status bar, and the log panel.

Next, check the remote connection and security authentication. Once the core starts normally, distinguish among DNS resolution failure, connection timeout, connection refused, security handshake failure, and proxy authentication failure. A timeout doesn't prove the password is wrong, and changing the local port won't fix an authentication error. Use the log stage to check DNS resolution, remote port, time, server name, identity fields, and security settings. If the server is outside your control, ask the provider to confirm its configuration instead of repeatedly changing valid fields at random.

Finally, check whether requests actually reach the proxy and how they are routed. If a core test request succeeds but the browser still can't connect, check the browser's proxy settings, the local listener, and the matched routing rule. If only some apps fail, compare how they connect and resolve domains. If only some destinations fail, check their status, routing rules, and DNS results. On Android, also verify per-app settings and system permission. Test server availability separately from app access to avoid switching between servers that are already working.

Keep conclusions within their limits

When the connection works but performance is inconsistent, then look into speed and battery use. Stop background speed tests and parallel downloads first. Compare the stability of different entries on the same network, then test on other networks. If all entries fail on just one network, investigate its DNS, access, and link conditions. If only one entry fails, check its server status and configuration. Change one factor at a time and keep the original results so an occasional recovery isn't mistaken for proof that a setting always works.

A useful configuration choice should answer four questions: What complete configuration does the server provide? Does the current core support it? Do apps connect as expected? Is it stable under real workloads? Protocols don't need permanent speed or quality rankings. Keep a record of the configuration source, key fields, test conditions, and failure stage to make future updates and migrations easier to compare. To return to the setup workflow, see the Getting Started guide. For a specific error, consult Troubleshooting; this is easier to diagnose than reinstalling the client and rebuilding every setting at once.