V2Ray Protocols and Core Selection

Configuration Layers: Protocol, Transport and Security

A node may appear as a single line in your client, but several layers determine how it connects. The proxy protocol defines authentication and how requests are represented; the transport determines how data is carried; and the security layer encrypts the connection and verifies the remote endpoint. The address and port identify the service entry point. Understanding how these fields fit together explains why two nodes labeled VLESS can’t necessarily share the same settings, and why a client menu option isn’t a complete protocol description.

Which configuration layers should you check?

VMess, VLESS, Trojan and Shadowsocks are proxy protocols; TCP, WebSocket and gRPC are transports; TLS and REALITY are security options. REALITY is not a proxy protocol on the same level as VLESS. A client may list it as a separate option simply to make a common combination easier to configure. Even then, check the underlying protocol instead of relying on the menu label to tell you how the connection works.

Start by confirming the address, port, proxy protocol and authentication details, then check the transport and security settings. UUIDs are commonly used as user IDs for VMess and VLESS; Trojan uses a password, while Shadowsocks requires an encryption method and a key that meets its requirements. These credentials may all look like strings, but they serve different purposes. Don’t copy a password into a user ID field just because both accept text. If the editor saves the entry, it only means the input passed the client’s checks—not that the server will accept it.

The connection address isn’t the server name

The address is the destination the client actually connects to. It can be a domain name or an IP address. SNI, also called the server name, is used during the TLS handshake and for identity verification; it may differ from the connection address. The WebSocket Host header and path are separate transport settings. A provider may intentionally use different values for these fields, so making them all the same domain won’t fix the connection. The port doesn’t define the protocol either: common ports reflect deployment conventions, and the client’s port must match the server’s listening port.

Check transport-specific fields against the selected transport. WebSocket typically requires a matching path and Host header; gRPC requires a matching service name. Plain TCP doesn’t need these fields. When you change an existing node to a new transport, leftover settings may be ignored or may still affect the generated configuration. The safest approach is to add a new node with the correct type and enter each field from the source, rather than repeatedly changing dropdowns on an old entry.

A correctly configured node doesn’t guarantee every app will use it

Node settings cover the connection between the client and server. Whether an app’s traffic reaches the client depends on the system proxy, TUN or the app’s own proxy settings. Routing rules then determine which outbound connection it uses. So a browser connecting successfully while another app can’t connect doesn’t prove the protocol is at fault. First check whether the app’s traffic reaches the proxy, then review routing and DNS. Don’t immediately replace the UUID, disable certificate verification or change encryption settings.

Use the configuration layers to narrow down log errors, too. A parsing error happens before the connection starts; a timeout may occur while dialing; a TLS identity error belongs to the security layer; and an authentication failure usually points to protocol settings. A single error can have several underlying causes, so consider when it occurs. Keep the original imported entry and change one field at a time. That makes configuration errors easier to distinguish from temporary network issues and helps you return to a working setup.

VMess vs. VLESS: Authentication and Encryption

VMess is an earlier proxy protocol in the Project V ecosystem. Its design builds user authentication and data protection into the protocol itself. It helps explain why V2Ray is more than a system proxy toggle: the core identifies users, wraps destination addresses and processes data according to the protocol. Later versions of VMess introduced AEAD authentication, reducing the overhead of older authentication designs. This background is useful mainly for recognizing legacy configuration fields—not as a reason to keep using historical compatibility modes.

VMess: Alter ID and Encryption Settings

Some clients retain an “alter ID” or alterId field. Modern VMess configurations commonly use an alter ID of zero, corresponding to the AEAD path. This value is neither a node count nor a security level you can raise at will. If a source specifies another value, first check whether the server and core still support that legacy mechanism. If authentication fails after import, verify the original settings and compatibility range instead of guessing different numbers.

The auto encryption setting lets the implementation choose an appropriate method based on conditions; it doesn’t disable encryption. Algorithm performance depends on processor instruction support, so no option is guaranteed to be faster on every device. Manually selecting an algorithm also requires support from the protocol implementation. For an imported node, keeping the source settings is usually more reliable than changing the algorithm on a hunch. To compare options, first make sure the server accepts both configurations.

VMess depends on accurate system time. A clock that’s off can cause authentication to fail even when the address, port and user ID are correct. Check automatic time synchronization and the displayed time zone instead of assuming every failure is a password issue. If the connection also uses TLS, certificate validity checks are affected by the same clock problem. Correct the system time and try again before making unnecessary configuration changes.

VLESS Relies on the Outer Layer for Content Protection

VLESS is designed to be more minimal: it retains the user ID and proxy request format without duplicating content encryption at the protocol layer. In common client configurations, the encryption field is set to none as required by the protocol. That doesn’t mean the entire connection should run unencrypted. Use an appropriate security transport, such as TLS or a supported REALITY configuration. Confusing VLESS’s none setting with VMess’s encryption dropdown leads to an incorrect understanding of where security is applied.

The VLESS flow field selects a supported flow-control mode. xtls-rprx-vision is the value for Vision. It’s not a universal speed boost and can’t be used with any VLESS transport. The server, client core and transport combination must all support it. If the source doesn’t specify a flow, don’t fill in the field just because it’s available. If the source does require Vision, removing it and assuming the connection is equivalent can also cause problems.

Choose based on deployment needs, not which name is newer

If an existing VMess service is stable, changing the protocol to VLESS in the client alone won’t migrate it. The server needs a matching inbound and user configuration, and the share link should be regenerated. For a new VLESS deployment, decide on the outer security layer and core support before considering flow control and performance. A newer protocol name doesn’t guarantee a better connection. Server load, link quality and transport can outweigh small differences in protocol overhead.

Troubleshoot these node types in a set order: verify the user ID is complete, confirm the protocol matches the server, then check transport, security and system time. For VMess, focus on alter ID and authentication compatibility; for VLESS, check that encryption and flow match the source. If the original link works with a supported core but a manually entered node doesn’t, compare the fields for anything missing before assuming the service is unavailable.

Trojan vs. Shadowsocks: Two Approaches to Connection Security

Trojan and Shadowsocks both appear in client protocol lists, but they rely on different approaches to connection security. Trojan commonly uses a TLS connection for authentication and proxy requests, while Shadowsocks is built around a pre-shared key and symmetric encryption. Compare credentials, the encryption boundary and transport settings together; they aren’t simply the same kind of node with different password formats. The client must use the protocol offered by the server.

Trojan: Check TLS as well as the password

A Trojan password is used for protocol authentication; a TLS certificate verifies the server’s identity. They solve different problems. A correct password can’t fix a certificate name mismatch, and a valid certificate doesn’t prove the password is correct. Clients may let you set the connection address and SNI separately. If you connect by IP, enter the server name specified by the server configuration. Copying only the password and missing the SNI can leave the connection stuck at the TLS stage, before password authentication begins.

“Allow insecure” skips an important identity check and shouldn’t be used as a routine fix. For certificate errors, check the system time, server name, certificate chain and server configuration in that order. If you use a custom trust setup, be clear about who issued the certificate and how the client trusts it rather than leaving verification disabled indefinitely. If a node source asks you to disable verification, confirm why the deployment requires it; the client’s toggle isn’t an inherent protocol requirement.

Trojan may support different transport combinations in different cores. The same basic protocol name doesn’t mean every core supports WebSocket, gRPC or other add-on capabilities. When the source specifies a transport, keep its path, service name and security settings together. Don’t overlook transport fields just because Trojan is commonly paired with TLS. Even after a successful TLS handshake, a mismatched transport entry point can cause a disconnect or leave the connection waiting.

Shadowsocks: The Encryption Method Determines Key Requirements

Shadowsocks is designed for a relatively simple encrypted proxy connection. Older methods and newer AEAD methods differ in format and security properties. Legacy methods remain in client lists mainly for compatibility; that doesn’t mean they’re all suitable for new deployments. When choosing a node, the exact method name matters more than a “high speed” note: it determines how both sides process data and whether the current core recognizes the connection.

Shadowsocks 2022 methods further change key and session handling. One example is 2022-blake3-aes-128-gcm. The password isn’t an arbitrary, human-readable passphrase: this method requires a key of the specified length and encoding, unlike traditional password derivation. Preserve the server-provided key exactly. Don’t replace it with a short phrase or encode an already encoded value again. If the method and key format don’t match, the configuration may save successfully but fail at runtime.

Some Shadowsocks share links include plugin settings. A plugin is an additional dependency, and not every core or graphical client can interpret it directly. An importer may recognize the address and password but drop the plugin parameters, leaving an entry that looks complete but uses a different connection path. Check the client’s supported features to see whether plugin settings are converted or retained. Changing the encryption method won’t make up for a missing plugin, and plugin settings don’t belong in the TLS server name field.

Test UDP and performance separately

UDP support in both protocols also depends on the core implementation, server settings and local traffic mode. A webpage loading only confirms that some TCP requests work; it doesn’t prove that voice calls, games or other UDP apps will work. Test the apps you actually use and check whether their traffic reaches the proxy and uses the expected outbound route. Some deployments only provide TCP service, and enabling TUN on the client can’t add UDP support on the server.

On resource-constrained devices, Shadowsocks’ symmetric encryption may have lower overhead, but actual performance depends on the algorithm, hardware and implementation. Trojan needs a TLS handshake to establish a connection, though long-lived connections can spread that cost over time. Compare short request-response tasks separately from sustained downloads. If an existing service is reliable, keep the settings that have been tested. For a new choice, consider the app type, key management and core support.

REALITY and Vision: Check Related Fields Together

REALITY is a secure transport mechanism in the Xray ecosystem, commonly used with VLESS; Vision is a flow-control mode used in related connections. They solve different problems, so enabling REALITY isn’t the same as enabling Vision. If a client offers a combined option, it’s simply grouping common fields for convenience. The generated configuration still needs to specify the proxy protocol, transport, security mode and flow separately, and the selected core must support them.

How REALITY Authenticates the Connection

A typical TLS deployment establishes trust through the certificate chain and server name. REALITY uses its own handshake and authentication mechanism. The client needs parameters provided by the server, such as its public key, and uses them to verify the connection. REALITY isn’t TLS with a different label, or a way to bypass certificate errors. Understanding the difference helps you avoid applying TLS certificate settings from a regular TLS node to a REALITY node.

The publicKey is the public key the client needs for the related handshake verification; it isn’t a private key to enter on the server. shortId identifies a deployment setting, usually represented in hexadecimal, and must match a value accepted by the server. The UUID still identifies the VLESS user. Although all these fields look like random strings, they aren’t interchangeable. Similar-looking lengths don’t change their distinct encoding and handling rules.

serverName or SNI must be within the range allowed by the server configuration; it’s not an arbitrary domain name for a website that happens to load. The fingerprint selects a supported client handshake fingerprint, such as chrome. It describes handshake behavior, not a browser the client launches or needs you to install. Fingerprint options are limited by the core implementation; typing in any browser product name doesn’t make it a valid value.

Vision isn’t another layer of encryption

Vision focuses on how data flows, especially when TLS traffic is carried within a proxy connection. It isn’t another authentication password or a standalone proxy protocol. Common VLESS configurations use xtls-rprx-vision to specify this flow-control mode; it must match the server settings and a supported transport. Don’t copy it into arbitrary combinations such as WebSocket. Even if a client lets you save an incompatible setup, the core may reject it or fail to connect.

REALITY and Vision often appear together, but their requirements can be considered separately. The server deployment determines the security mode; the flow setting must be supported by both ends. Neither can be chosen by the client alone. For a REALITY node without Vision, keep the source settings. For one that specifies Vision, check whether the flow field was lost during import. Adding a field based only on a promotional note can turn a compatible configuration into an incompatible one.

Troubleshoot Import Errors Separately from Handshake Failures

If a link won’t import, first check whether the client recognizes the REALITY fields and share format. If import succeeds but the core reports an unknown field, the issue is in configuration generation or core compatibility. For a handshake failure, check the address, port, user ID, public key, server name and shortId. A handshake can also fail if the server can’t reach a destination required by its deployment. The client can check its own settings, but changing the public key won’t fix server-side network conditions.

After a subscription update changes fields, review the node editor, especially the security mode, flow and public-key settings. Don’t combine an old public key with a new node, or assume the server configuration is unchanged just because the address is the same. If you need to maintain settings manually, keep a copy of the original import for comparison. For REALITY nodes, check Xray support specifically; VLESS support alone doesn’t guarantee support for this security and flow combination.

Connection Performance, Resource Use and Mobile Battery Life

There’s no fixed ranking for protocol performance. “Fast” may mean quick connection setup, a fast first webpage response, high download throughput or quick recovery after a disconnect. Different factors affect each metric, so one speed test can’t represent them all. Protocol headers and encryption are only part of the connection. DNS lookups, server distance, transport handshakes, congestion control and server load can all have a greater effect.

Different Costs for Short and Long Connections

Opening a webpage may create several connections. DNS lookups, TCP setup and TLS handshakes all take time before data transfer starts, and some transport wrappers have their own setup costs. Connection reuse can spread those costs out, but depends on support from the protocol, app and core. Short requests are more likely to reveal connection setup overhead; sustained downloads depend more on link capacity, congestion and server performance. Fewer handshakes don’t automatically mean faster downloads.

WebSocket adds an application-layer wrapper, while gRPC typically relies on HTTP/2 connection behavior. Both have deployment and reuse benefits, but also add processing overhead. Whether they’re a good fit depends on the server entry point and network conditions, not the protocol name alone. Don’t switch transports while keeping the same server address just to compare: the server may not listen for the alternative transport at all. A failed connection in that case indicates a deployment mismatch, not a performance difference.

Understanding Encryption and Memory Use

Processor support for AES instructions, implementation quality and single-core performance all affect encryption overhead. Core memory use also depends on concurrent connections, buffers, DNS cache and the size of routing data. If the client process uses a lot of memory, distinguish the graphical interface from the core subprocess. A single idle memory reading isn’t enough to show that one proxy protocol uses fewer resources. Compare under the same connection count and workload.

Multiplexing can reduce some connection setup costs, but routing traffic through a shared channel may change blocking and recovery behavior. It isn’t a speed boost that should be enabled on every node; implementations also differ for UDP and some flow-control combinations. If the source or core documentation doesn’t recommend it, keep the default. If enabling it causes problems only with concurrent requests, restore the original setting and check whether multiplexing is involved instead of immediately changing the server password.

Mobile Battery Use Depends on More Than the Protocol

Wireless radio wakeups, background app requests and connection keepalives can all have a significant effect on mobile battery life. Even a lightweight protocol may drain more power if it reconnects frequently. When the network switches between Wi-Fi and mobile data, existing connections may fail and the core has to reconnect. Repeated node switching and frequent speed tests also consume extra resources. Look at battery use during normal activity rather than attributing a single manual test to the protocol.

v2rayNG and v2flyNG use Android’s VpnService to receive traffic. Per-app settings determine which apps enter the proxy. Excluding apps that don’t need proxy access may help more directly than changing protocols. Android battery-saving settings can also stop background services, causing disconnects when the screen is locked. Allow necessary background activity in system settings and check whether an app is generating constant traffic; don’t mistake background restrictions and high battery use for the same problem.

Use a Repeatable Testing Method

Test short requests first, then sustained transfers, and finally standby and network switching. Record whether the connection succeeds, stays stable and causes noticeable processor load; there’s no need to invent a universal protocol score. Repeat each test and avoid updating subscriptions or downloading other content at the same time. If only domain requests are slow, investigate DNS separately. If only UDP apps fail, check traffic access, routing and server support.

For battery tests, use similar screen brightness and app workloads, and allow enough time to observe a trend. Distinguish active foreground use from background standby. For VpnService permissions, battery optimization exceptions and per-app modes, see v2rayNG setup tips for Android. If the connection is stable and device load is acceptable, there’s no need to migrate repeatedly for a theoretical reduction in protocol overhead. Maintainability is part of the cost, too.

V2Fly vs. Xray: Project Lineage and Compatibility

The Project V ecosystem brings together proxy connections, routing, transport and other configurable core capabilities. V2Fly continues development related to the V2Ray project, while Xray branched from this technical foundation and developed its own features. They share configuration concepts and history, but a common origin doesn’t mean every setting is interchangeable. Protocol support, transport implementations, security features and field structures can diverge as each project evolves.

What the GUI Client and Core Each Do

v2rayN is a desktop client for managing nodes, subscriptions, configuration and runtime controls; the selected core handles the actual connection. v2rayNG is for Android and typically uses the Xray core, while v2flyNG offers an alternative based on V2Fly. Similar-looking interfaces don’t imply identical underlying capabilities. To check whether a node will work, verify both that the client can enter its fields correctly and that the core can interpret the generated configuration.

For desktop, start with v2rayN to manage nodes, routing and system traffic modes in one place. That doesn’t mean every imported configuration will work automatically. Switching between cores requires support from the client version and runtime environment. After a core switch, recheck the current node and routing; seeing the client icon in the system tray isn’t enough. When moving between Android clients, recheck subscription format, app traffic access and protocol options as well.

Shared Configuration Concepts Don’t Make Fields Interchangeable

Common JSON configurations may include inbounds, outbounds, routing and DNS, but field meanings depend on the target core. Some features are supported by only one project; others exist in both but use different configuration formats. Before copying JSON to another core, check the protocol, transport and security settings, then review routing and DNS. Don’t keep deleting fields from the error message until the configuration starts.

REALITY and Vision are common Xray capabilities to check when choosing a core. V2Fly support for a basic proxy protocol doesn’t imply support for every Xray extension combination. Likewise, Xray’s ability to read some V2Ray-style configurations doesn’t guarantee that every legacy or future field will work. Converting a share link in a client can hide differences in the underlying formats; native JSON makes them more apparent.

Routing Snippets Show the Shared Concepts

The JSON snippet below is a routing section. It sends private IP addresses to direct first, then routes remaining TCP and UDP traffic through proxy. Merge it into a complete configuration for the target core, and make sure an outbound with the same name is defined. The geoip rules also require the relevant data to be available. This snippet contains no connection credentials and can’t run as a standalone node configuration. It illustrates rule order and shouldn’t replace the full configuration generated by your client.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

Rules are generally evaluated in order, so an earlier condition can prevent later rules from being reached. AsIs doesn’t resolve domains to IP addresses for IP-based matching, so the private-address rule doesn’t mean that every domain resolving to a private IP will go direct. To route based on resolved addresses, learn how domainStrategy works. See domain, ip, geosite and rule priority for details.

Keep Updates and Core Switches Reversible

A client update may affect the graphical interface, import logic, core capabilities or several of these at once. Keep a working configuration and check whether the update changed the core in use. Don’t rely on a made-up minimum version to determine support for every feature; check the current release notes and configuration support. If only a few nodes stop working after an update, compare their protocol combinations. If all nodes fail, check the runtime environment, permissions and configuration generation.

An unknown protocol or field in the logs points to a capability or syntax issue; a connection timeout doesn’t prove that the core lacks a feature. If switching cores resolves the issue, check whether the client also changed other settings. For desktop installation or Android client options, use the downloads page to check platform and architecture. This page covers feature compatibility, not a separate core download process.

Subscriptions and Share Formats: Check Compatibility After Import

A subscription distributes nodes; it isn’t a new proxy protocol. It may contain entries that use different protocols, or configuration data understood by only certain clients. A successful subscription request only means a response was received; it doesn’t guarantee the format can be parsed. Seeing nodes in the client means only that some of the import succeeded. Check whether all transport and security fields were retained and whether the current core supports them.

Share Links, Base64 and Native JSON

Share links typically identify their type with a protocol prefix, such as vmess://, vless://, trojan:// and ss://. Each format stores the address, credentials and additional settings differently. VMess links commonly contain Base64-encoded JSON; VLESS and Trojan links commonly use URI query parameters. These formats can’t be converted into one another by simply changing the prefix. Preserve the entire link when copying it, including special characters and encoded parameters.

Base64 is often used to package multiple share links into a subscription response. It’s an encoding, not encryption for the connection. Decoding the text doesn’t produce a complete, runnable core configuration, nor does it mean every link is valid. The client still needs to parse each protocol and create an outbound. Check the source before importing, and don’t upload subscriptions containing credentials to untrusted services. Local parsing and remote conversion have different privacy implications.

Native JSON may include inbounds, routing, DNS, logging and multiple outbounds in addition to nodes, and is usually intended for a specific core or client workflow. It contains more than a single share link. Converting full JSON into a share link drops many global settings that have no equivalent field; converting a share link to JSON requires adding local traffic access and routing. Conversion isn’t lossless: decide whether you need to preserve node details or the complete runtime policy.

Fields and Encoding Details That Can Be Lost

Newer security parameters, flow, handshake fingerprints and transport-specific fields can be ignored by older importers or simplified converters. The node name, address and user ID may still be present even when this has happened. After importing a REALITY node, open the editor and check all fields. For a Shadowsocks link with a plugin, verify that the plugin settings were retained, too. A preserved note doesn’t prove the configuration is complete; compare the actual fields.

Special characters in URIs need to be encoded according to the format. This matters especially when a password, path or remark contains delimiters. Manual edits can cause part of a password to be treated as a query parameter or alter characters in the path. If import fails, try the client’s clipboard or file import instead of deleting punctuation repeatedly. Share formats can differ between implementations, so if one entry fails to parse, ask the source which client it targets instead of rewriting every link.

Troubleshoot Update Failures Separately from Connection Failures

If a subscription update fails, first check whether the address is complete and still valid, whether the request can be sent, and whether the update request needs to use a proxy. A working node with a failed update may mean the subscription service has different access requirements. If the update succeeds but a node fails, check its settings and server status. An incorrect system clock can also affect TLS verification for subscription requests. Don’t mistake a subscription request error for a flaw in the proxy protocol.

Automatic updates change the node list, and can overwrite manual edits the next time they run. If you need to keep test settings, copy the node into a separate entry or group and note that it no longer follows changes from the source. After switching subscriptions, check which node is selected instead of assuming the client chose the right one. For update requests and refresh intervals, see common causes of subscription update failures.

When moving to another client, import a small number of nodes first, then check UDP, routing and app traffic access before moving the rest. Don’t switch cores, convert the subscription and change DNS all at once, or it will be hard to tell which step caused a problem. For the structure and conversion limits of these three formats, see Base64 subscriptions, native JSON and share links compared. Treat subscription credentials as sensitive; redact them before sharing troubleshooting screenshots.

Choosing a Setup and Checking Configuration

Server support is the primary constraint when choosing a protocol; client preference comes second. If you have only one working service, importing it correctly and keeping it stable matters more than choosing a newer protocol name. If you can choose how to deploy, compare maintenance requirements, device capabilities, app types and performance needs. The workflow below combines selection and troubleshooting: rule out incompatible combinations first, verify traffic access and routing next, then use repeatable tests to decide whether migrating is worthwhile.

Set a Baseline for Desktop and Mobile

For desktop, start with v2rayN to manage nodes, choose an installer for your operating system and processor architecture, then check which core is in use. A system proxy can verify ordinary browser traffic. Consider TUN only for apps that don’t follow the system proxy. TUN changes how local traffic enters the client; it doesn’t change the server protocol or fix an incorrect public key or password. Getting one ordinary connection working first makes later traffic-access changes easier to troubleshoot.

For Android, start with v2rayNG, especially if you need Xray features. If you already have a configuration intended for V2Fly, consider v2flyNG. Verify protocol support in either client rather than assuming a node is compatible because the app installed successfully. First-time setup requires VpnService permission, and background restrictions can affect stability when the screen is locked. Configure per-app proxy access for the apps you intend to use; otherwise, an app that bypasses the proxy may look like a protocol failure.

Choose a Combination Based on Apps and Maintenance

For many short requests, focus on connection setup and DNS. For sustained transfers, check throughput and stability. Real-time communication needs separate testing for UDP and network switching. On resource-constrained devices, consider symmetric encryption overhead and concurrent connections, but don’t draw conclusions from a single idle memory screenshot. Services with standard TLS certificates and a mature maintenance process may be a good fit for a TLS setup. With REALITY, make sure the public key, server name and related parameters can be managed reliably.

If a VMess or Shadowsocks service is already stable, migration requires the server to provide the corresponding protocol; changing a client dropdown isn’t enough. With VLESS, choose the security layer and flow together. With Trojan, verify the password and certificate identity. With Shadowsocks, check the method and key format. A setup that maintainers can understand and update correctly is a better long-term baseline than a more complex one they can’t manage.

Narrow Down Connection Problems by Stage

First check import and startup: is the node present, is the correct entry selected, is the core running, and do the logs report unknown fields? Next check dialing and the handshake, including address resolution, port reachability, server name and system time. Then check authentication and transport: verify the user ID, password, encryption method, path, public key and flow. At each stage, start by restoring the settings from the source. Don’t pile on several unverified “optimizations.”

If the connection is established but webpages won’t load, check app traffic access, the routing outbound and DNS. You can compare a request to an IP with one to a domain, but first confirm that the destination permits both. If only certain apps fail, check whether they follow the system proxy, appear in the per-app list and rely on UDP. Before changing protocols, identify whether the issue is with local traffic access, the proxy connection or the destination service. This avoids unnecessary tests.

Keep a Working Configuration and Test Notes

Once you have a baseline, record the protocol, transport, security mode, core and traffic access mode. Don’t include credentials in public notes. Change one setting at a time and keep the original imported entry. After updating the client or subscription, retest common apps, especially background use and UDP. If the network is temporarily unstable, don’t change every setting at once. Repeat the test, check the logs and confirm the problem is reproducible before taking further action.

This page explains compatibility and selection. For the complete setup process, return to the quick-start guide. For specific usage questions, see the FAQ; for field definitions, see the glossary. The goal is a configuration with a known source, consistent fields, core support and verified app connectivity—not an abstract protocol ranking. Stability, maintainability and success with your actual tasks are what make a setup the right choice.