V2Ray Protocol Guide
Protocol Types & Core Selection

01 · Protocol Layers & VMess

A server name is not a complete connection profile

A server entry in a client typically includes the server address, port, proxy protocol, transport, transport security, and authentication credentials. The protocol defines how the destination is represented, the user is authenticated, and requests are organized. The transport carries the bytes, while the security layer protects the connection and verifies identity. A subscription label may show only the protocol name, but the connection depends on the full set of parameters. Changing a dropdown from VMess to VLESS does not convert an existing service to another protocol.

Before troubleshooting, break the configuration into three layers: outbound protocol, underlying transport, and security settings. For example, VMess can use WebSocket and TLS; VLESS can use a direct transport and REALITY. Two profiles with the same address may still connect to different ports or server entry points. The combinations shown here explain the structure; whether they work depends on the server configuration. The client can initiate a connection as configured, but it cannot provide capabilities the remote server does not have.

VMess: background and authentication

VMess was one of the core protocols used when Project V first developed its proxy ecosystem. It handles user authentication and proxy request encapsulation at the protocol layer, and can be paired with different transports. It is neither a simple socket-forwarding format nor a synonym for any particular encrypted outer connection. This distinction explains why profiles all labeled VMess can behave very differently in their handshakes, outer-layer protection, connection reuse, and network characteristics. The name alone does not predict performance.

Modern VMess configurations should use implementations that support AEAD authentication. Do not carry over legacy identity counts or authentication methods from older guides. If a client still shows a historical field such as alterId, check the subscription source and core documentation; modern configurations commonly use a value of zero. Authentication and payload encryption are separate concepts. An algorithm shown in an encryption dropdown does not tell you which generation of authentication is in use.

System time directly affects VMess authentication. A device that has been asleep for a long time, has had its clock changed manually, or cannot sync time may reject a profile even when the address and credentials are correct. Distinguish the displayed time zone from the actual clock: a different time zone is not necessarily a problem, but a clock that is out of sync is. Restore automatic time synchronization and retry before assuming the server is down or the protocol is incompatible.

Field checks and their limits

After importing, check the address, port, and user ID first, then the transport type, and finally TLS, server name, and transport path. The user ID is authentication data: keep it intact, but never include it in a public screenshot. A transport path is not a local file path, and a WebSocket Host is not always the server address. These values may be needed to match the remote entry point. Do not delete them just because they look redundant, or replace every domain field with the resolved IP address.

The right VMess payload encryption setting depends on the core implementation, processor, and server configuration. A processor with hardware acceleration may perform better with certain algorithms, while mobile performance also depends on system scheduling. Automatic selection is usually a good baseline. Set an algorithm manually only when both sides explicitly support it and you can reproduce the test results. Disabling one layer of payload encryption does not mean another layer is protecting the connection; verify outer-layer security separately.

If an existing VMess profile is stable, there is no need to migrate just to change its name. If you need new capabilities, first check whether your current core supports them, then get a complete new connection profile from the provider. To compare performance before and after migration, keep the device, network, destination, and test window as consistent as possible. Otherwise, changes to the remote entry point can be mistaken for protocol differences, leaving you with speed results that cannot be reproduced.

02 · VLESS & REALITY

A lightweight protocol still needs transport protection

VLESS is designed around lean authentication and request encapsulation in the V2Ray ecosystem. Unlike VMess, the base protocol does not provide the same payload-encryption role; connection protection comes from the accompanying transport security. So “lighter protocol” describes how responsibilities are divided, not permission to send data in the clear on any network. In a common VLESS profile, encryption set to none describes that protocol field—it does not mean the whole connection lacks a security layer.

After selecting VLESS, confirm that the remote endpoint uses TLS, REALITY, or another explicitly supported combination. Do not switch the security option based on personal preference: the remote handshake must use the same scheme. Matching user IDs do not prove that two entry points are interchangeable. If an importer replaces an unknown security type with a default, it may still create a server entry while changing the handshake. Reopen the settings and check the parameters against the original profile.

REALITY is a security scheme, not a standalone proxy protocol

REALITY is a transport security scheme in the Xray ecosystem and is commonly paired with VLESS. It changes the security handshake and authentication; it does not replace the proxy protocol's destination or request semantics. A subscription's “REALITY node” usually refers informally to the whole connection profile. When choosing a setup, confirm the underlying protocol, transport, and flow control instead of looking for a REALITY option that can replace VLESS in the protocol list.

Unlike a typical certificate deployment, REALITY uses its own authentication parameters and handshake. Clients generally need a server name, public-key authentication data, a short ID, and the client fingerprint required by the implementation. The public key is not the client user ID, and the short ID is not a free-form note. Labels for these fields can vary between clients and core versions. Match them to the source profile and current implementation rather than copying values based on their position in an older guide.

The server name participates in the handshake and identity checks, and usually must be allowed by the server. It does not have to match the connection address character for character, but it cannot be replaced with any domain at random. The connection address determines where the client connects; the server name helps construct and verify the security handshake. Treating both as a single “domain” causes confusion. A reachable address with failed authentication is a classic case for checking each layer separately.

How Vision, fingerprints, and transport fit together

XTLS Vision is commonly set with the flow field, typically xtls-rprx-vision. It controls data flow for specific connection combinations; it is not a universal speed-boost switch. Whether it can be enabled depends on the server, core, and transport combination. Do not copy a setting intended for direct transport to a WebSocket or other transport. If the provider has not specified a flow setting, do not add one just because another profile uses it.

A client fingerprint controls some TLS client handshake characteristics. It does not mean the corresponding browser is installed or that all app behavior will change. Fingerprint options require core support, and similarly named controls may be handled differently by different implementations. If a connection fails, restore the subscription's original value and check the security-layer error in the logs. Then determine whether the fingerprint is unsupported, an authentication parameter is wrong, or the server name does not match.

For REALITY or Vision, first check the Xray core included with v2rayNG on Android. On desktop, confirm which core is active in v2rayN. If an existing VLESS profile is missing essential authentication parameters, get the complete share content again instead of guessing. See the core families section for implementation differences. A matching protocol name is only the starting point for a compatibility check.

03 · Trojan & Shadowsocks

Trojan: authentication and proxy requests over TLS

Trojan places proxy authentication and requests inside a TLS connection, commonly using a password as the user credential. Its design makes the boundary between the protocol and outer security relatively clear: establish a TLS connection as configured, then exchange proxy requests. Choosing Trojan does not make certificate problems disappear. The server name, certificate trust chain, and device time must still be correct; any of them can terminate the connection before proxy authentication begins.

A standard Trojan connection usually does not need a user ID like VMess. If you copy settings from another protocol and leave unrelated fields in place, the client may ignore them or create a bad configuration. Create a new entry for the right protocol and use the original share content to enter the password, address, port, and security settings. Special characters in a password can be escaped incorrectly when you assemble a share link by hand. Prefer the client's import and export features.

Do not treat bypassing certificate verification as a routine fix. First check whether the connection address and server name have been confused, then verify system time, certificate validity, the certificate chain, and whether the remote endpoint actually offers TLS. Allowing insecure connections changes the identity-verification boundary and may accept the wrong endpoint. If you change this setting temporarily to diagnose an issue, record the change and revert it promptly. Fix the underlying cause for a long-term setup.

Shadowsocks: method and key determine compatibility

Shadowsocks, often shortened to SS, uses a relatively compact encrypted proxy format. Its authentication and data handling differ from VMess and Trojan; a similar-looking password field does not mean the protocols are compatible. For SS, confirm at least the server address, port, encryption method, and password or key. The method is part of the protocol agreement, not a local client preference. Both sides must use a matching algorithm and interpret the key the same way.

Older stream ciphers, later AEAD methods, and the Shadowsocks 2022 series have different designs and configuration requirements. Modern deployments should generally favor AEAD methods still supported by current implementations, but “supports SS” does not mean every generation is supported. Newer methods may require a specific key format and length; do not enter an arbitrary short password and expect the core to derive a compatible value. Follow the remote method's documentation for the required format.

SS share links also have several legacy encoding formats. Some encode the method and password together; others encode authentication separately and may append a remark or plugin parameters. If importing fails, first make sure the link is complete and messaging apps have not truncated it, then check whether the current client supports the extension. Repeatedly decoding and reassembling the content can damage special characters and delimiters, creating further errors.

Do not assume extra encapsulation is built into the protocol

Some SS profiles rely on an extra plugin or a dedicated outer wrapper. Support for the base protocol and support for a plugin are separate capabilities. A graphical client recognizing a method name does not mean the required plugin runtime is available. This guide does not recommend additional clients. If a share profile depends on extra components, first confirm that the current implementation in v2rayN, v2rayNG, or v2flyNG can handle it fully.

UDP is another path to check separately. A protocol allowing UDP forwarding does not mean the subscription endpoint, remote service, client mode, and local app have all enabled it. A working web page only confirms that some TCP requests work; it says nothing about real-time audio and video or other datagram traffic. For app-specific failures, check for fallback behavior, supported destination ports, and whether routing sends the two traffic types through different outbounds.

With a complete, compatible profile, Trojan may suit deployments that use familiar TLS operations; SS may suit setups with an existing deployment and clearly documented method requirements. Neither is automatically faster just because its encapsulation looks smaller. To switch protocols, obtain an entry actually provisioned for the new protocol instead of keeping the old port and changing only the client type.

04 · Connection Speed, Resources & Mobile Battery Use

Measure first-request latency separately from sustained transfer

The time it takes to load something can come from DNS resolution, connection setup, the security handshake, proxy authentication, and the destination's response. A protocol affects only some of these. Apps that make many short connections are sensitive to handshake costs; large transfers are more often limited by link bandwidth, congestion control, and remote capacity. Before comparing protocols, decide whether you are measuring page load, time to first response, or sustained throughput. Combining them into one speed score will not show where the problem lies.

An outer transport may add requests or handshakes, or reduce later overhead through connection reuse. TLS, WebSocket, and transports with multiplexing do not imply a fixed speed ranking. Extra round trips can matter more on high-latency networks; with a reused connection, a new request may not pay the full setup cost again. The experience of the first page load is therefore not directly comparable to repeated refreshes on the same connection.

CPU overhead during sustained transfers depends on algorithm implementation, hardware acceleration, buffer handling, and data copying. Desktop processors and mobile chips can hit different bottlenecks even with the same protocol. Discuss encryption or encapsulation overhead only when the CPU is consistently busy and the link has spare capacity. If every profile stalls at about the same point, check the network and remote resources before cycling through protocol names.

Mux is not a universal performance switch

Mux puts multiple logical connections onto fewer transport connections. It can reduce the cost of frequent connection setup, but it can also make multiple requests share the same bottleneck. Its benefits depend on the protocol, transport, core implementation, and workload. Some combinations already have multiplexing, so adding traditional Mux may not help; some flow-control schemes also impose restrictions. Start with the original settings and change one multiplexing option at a time.

Mobile battery use is not just about encryption. A VPN service running continuously, background polling, repeated DNS retries, and network switching can all wake the processor or radio. If the client is using more power while other apps are also generating heavy traffic, first identify where that activity is coming from. Traffic from an app using the proxy may be counted partly under the VPN service, so system battery stats cannot be attributed entirely to protocol efficiency.

Background limits, keep-alive, and network changes

Aggressive battery optimization can stop a background service, forcing repeated reconnects; disabling all restrictions can also keep it running unnecessarily. First confirm that the system is actually stopping the service, then grant the client only the background permissions it needs. Do not change keep-alive, Mux, DNS, and per-app rules all at once. Even if battery use drops, changing too many variables makes it hard to tell whether traffic decreased or the protocol settings improved.

When switching from Wi-Fi to mobile data, existing connections usually need to be rebuilt, and DNS caches and network interfaces may change. A brief failure at this point is not necessarily an authentication error. Wait for the network to settle, reconnect once, and note whether the logs show a failure during resolution, connection, or handshake. If it fails only on a certain network, check address family, path MTU, and reachability instead of repeatedly changing authentication parameters to mask a link issue.

For a repeatable comparison, keep the device, app, destination, and network conditions fixed. Test cold-start access, repeated requests, and idle background behavior separately. Change one factor per run and allow the connection time to stabilize. Avoid background downloads, system updates, and other heavy workloads during testing. There is no need for a universal ranking: a useful result shows which settings reduce failures, reconnects, or sustained resource use on your device and for your workload.

Per-app proxying can keep apps that do not need a proxy from sending traffic through the VPN, but consider app handoffs, sign-in components, and system service dependencies. Proxying only the main app while excluding its authentication component can let pages load but prevent sign-in. Performance tuning must preserve functionality. Once the workload works, narrowing the proxy scope and reducing unnecessary background activity is more likely to help than choosing a protocol that merely sounds lighter.

05 · Project V, V2Fly & Xray

The client interface and core are different layers

Project V provides useful background for understanding the V2Ray ecosystem. V2Fly continues V2Ray's community development, while Xray branched from related code and has developed its own feature set. They share some history and configuration concepts, but they are no longer different names for the same program. Similar protocol names, JSON fields, or directory layouts point to shared foundations—not a guarantee that new features will appear in both implementations or that the same configuration will always behave identically.

Graphical clients handle tasks such as subscription management, configuration editing, routing, and startup control. The core actually establishes and forwards connections. The interface may offer an option, but the active core still determines what runs. A field being editable does not mean the core accepts it; a saved configuration does not prove that the setting reached the runtime file. Troubleshooting requires checking the client, core family, and effective configuration—not just the window title.

Choosing among the three clients

For desktop, start with v2rayN, which provides installation options for Windows, macOS, and Linux. It offers a unified interface for subscriptions, routing, and desktop proxy management, although interface details and system integration may differ by OS. For protocol support, check the core currently enabled and what the installation actually includes. Do not assume that because v2rayN on another device supports a combination, your current installation does too.

On Android, v2rayNG uses the Xray core and suits profiles that need its capabilities. v2flyNG uses V2Fly and is an alternative for profiles targeting that implementation. Choose based on the capabilities the profile requires; similar names do not make the clients interchangeable. If a subscription explicitly requires REALITY or Vision, check the Xray path first. For a V2Fly profile, verify its fields and behavior against the current V2Fly implementation.

Both core families support widely used protocols and transports, but their coverage and exact semantics evolve. REALITY and Vision are important capabilities to check when using Xray; do not pass an outbound containing these fields to V2Fly unchanged. Conversely, do not assume Xray supports a transport or configuration structure specific to V2Fly. Check each item when switching cores instead of replacing the entire file and merely seeing whether the client starts.

Check configuration structure and semantics when migrating

Core configurations typically include inbounds, outbounds, routing, DNS, and logging. Copying only an outbound may omit the routing or DNS policies that refer to its tag; copying the entire configuration may bring over listen addresses, ports, or file paths that do not exist on the local device. Keep a working backup and migrate one section at a time. Even if field validation passes, verify that traffic reaches the intended outbound and that domain resolution still follows the original policy.

Unknown fields, unrecognized security types, and unsupported flow settings in the logs are compatibility clues. Do not force them away by deleting the fields that triggered errors. Removing a key field may let the program start while changing the connection's intended behavior. First identify which implementation provides the field, then decide whether to use the matching core or obtain a profile adapted to the current one. Both approaches are easier to understand than deleting fields blindly.

Updating the client and updating the core are separate changes. A client update may fix subscription parsing; a core update may change protocol support. Save your subscription and local rules before updating. Afterward, test a known profile before restoring complex routing. If something regresses, record the exact stage and fields involved rather than just “it stopped working after the update.” For more on the core families, see Xray vs. V2Fly: differences and configuration compatibility.

06 · Transport Settings, Routing & DNS

Path, Host, and server name each have a distinct role

The transport determines how proxy traffic is carried. A direct TCP connection has a relatively simple structure; WebSocket adds an HTTP upgrade; gRPC and other transports have their own request and multiplexing semantics. These are not decorative options the client can choose independently—they are part of the remote entry point. If the server accepts only one transport, changing it locally will usually fail before authentication. Compare performance only between combinations that actually exist on the server.

A WebSocket path is used for request routing; Host may be used to match a virtual host on a reverse proxy; the TLS server name is used for the security handshake. They may match or be set separately as required by the deployment. Preserve the path's capitalization, leading slash, and special characters. If the reverse proxy does not forward the request to the right backend, you may receive an ordinary web page or error even after a successful certificate handshake. That does not mean the proxy protocol is working.

The gRPC service name must also match the remote configuration; it is not a client-side label for convenience. ALPN negotiates the application protocol over a secure connection, and restricting the options incorrectly can prevent the required transport from connecting. Do not copy another node's ALPN list unless the deployment documentation calls for it. Troubleshoot in layers: address reachability, security handshake, transport, then proxy authentication. Identify the failing stage before changing the corresponding field.

Rule order determines which traffic uses a route

Selecting a proxy outbound does not mean all traffic will use it. System proxy settings, VPN interception, app-specific proxy settings, and core routing all determine where traffic goes. A system proxy affects only apps that honor it; VPN or virtual-interface mode covers more traffic but is still subject to exclusions and permissions. If one app behaves differently, first check whether its requests reach the client. Do not spend time changing outbound protocols when the issue is at the entry point.

Routing rules are usually evaluated in order. A broad rule near the top may prevent more specific rules below it from ever matching; the default outbound handles anything unmatched. The example below is a rule fragment, not a complete runnable configuration. It requires existing direct and block outbounds and the relevant rule resources. When merging it, check that the referenced tags exist. Valid JSON alone does not mean it can replace the entire file.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Validate DNS and outbounds together

DNS is more than entering a resolver address. Check which component sends the query, which outbound it uses, and how the returned address affects subsequent routing. An app may use encrypted DNS, while the system may retain a separate resolution path; core DNS settings do not necessarily take over either. After setting a remote DNS server in the client, verify the actual request path instead of assuming resolution follows the proxy based on the settings page.

Remote DNS can also create a startup dependency. If the proxy server uses a domain name but resolving it requires a proxy connection that has not been established, the setup becomes circular. Provide a clearly reachable resolution path for the server's domain without accidentally sending all destination lookups through that startup path. Separating server address resolution from destination-site resolution helps explain why some problems appear only after clearing the cache.

FakeDNS uses synthetic addresses to preserve domain information and can help with specific interception and routing setups, but enabling it alone is not a simple anti-leak fix. Synthetic addresses must return to a handler that recognizes them; if another app or outbound treats one as a real address, the connection will fail. Coordinate caching, address families, and rules as well. For a verification guide, see how to check DNS request paths and configure DNS. Save the current settings before making changes.

After changing transport or DNS, test access by domain name, resolution of any proxy entry that uses a domain, and datagram connections required by your apps. A single web page can hide DNS issues through caching, and a reused connection can hide handshake problems. Include a fresh connection and check the outbound tag in the logs. This helps distinguish an unavailable protocol, a routing rule that did not match, and an incorrect DNS path.

07 · Subscription Formats & Cross-Client Compatibility

A subscription is a distribution format, not a communication protocol

A subscription link retrieves a set of server profiles, which the client converts into runtime configuration. It does not define how data is transmitted, and it does not guarantee that every entry works with the current core. A successful update only shows that some steps in retrieval and parsing completed. Check more than the number of entries: confirm the protocol type, preserved security parameters, and whether the active core understands the fields.

Common formats include one share link per line, encoded collections of links, and full configurations for a specific implementation. A file extension or URL appearance alone does not establish the actual format; the client must identify the returned content. If the response is a web page, login prompt, or error message, copying it again will not turn it into subscription data. First check whether the source requires authorization and whether its response matches the expected format, then investigate parsing compatibility instead of reinstalling the client.

Recognizing a prefix does not mean every setting was preserved

VMess shares often contain structured fields. VLESS and Trojan links usually describe security and transport through the address and query parameters, while SS has several legacy encoding formats. Clients may differ in how many aliases, optional parameters, and extension fields they support. An importer can ignore unknown parameters and still display an entry that looks complete. After moving between clients, open the editor and compare every field—matching names and addresses are not enough.

Server name, flow, fingerprint, short ID, transport path, and service name are easy to miss. Some parameters appear only with certain security or transport types. If the type is detected incorrectly, later fields may be hidden or cleared. If a field in the original share has no matching control, first check whether the client and core support it. Do not put unknown parameters in a remark or substitute a similar-looking input field.

Subscriptions usually describe connection entry points, not complete routing, DNS, system proxy, or per-app rules. Two devices can import the same subscription and still behave differently because local policies are not synced. When moving from desktop to Android, keep these two parts separate: migrate the servers first, then review routing and VPN settings independently. See how to sync subscriptions, share links, and backups across devices.

Updates, groups, and the limits of local edits

Automatic updates usually regenerate the entries in a subscription group. Local edits may be lost on the next update, depending on the client. If you need to keep an experimental profile, copy it to a clearly labeled manual group and record which subscription entry it came from. Do not mix edits from unknown sources into the same group and rely on remarks to guess which entries an update will overwrite. After an update, spot-check critical security settings, not just the sort order.

Subscription filters and remark regexes affect which entries appear in a list; they do not verify whether a protocol works. A filter that is too strict may hide a usable entry, and similar names do not mean two profiles are the same. If a server seems missing after an update, disable filters and check the group before deciding the source removed it. See subscription groups and server filtering to avoid mistaking a display issue for a core failure.

A QR code is just another way to carry text; it does not add protocol support. A scan failure may be an image-recognition problem, while an import failure after a successful scan may be a text-format issue. Diagnose them separately. Check the recognized protocol prefix and structure locally on the device; do not send credential-bearing content to an unknown conversion service. When forwarding long share text through a messaging app, watch for line breaks, punctuation changes, and truncation at the end.

A useful migration record includes the source type, client, core family, and key settings—not just a screenshot of the server list. After migrating, test one simple profile from a known source before importing the rest. Once it works, restore filters, automatic updates, and complex rules. If it fails, trace the issue through retrieval, parsing, configuration generation, startup, and handshake instead of replacing everything and losing the original clues.

08 · Choose a Setup for Your Use Case

List your constraints before comparing protocols

Start by checking which entry points the remote server actually offers, not by looking for a speed ranking. Then consider the device OS, client, core family, workload, and maintenance needs. If the server provides only one complete profile, get it working correctly before considering another protocol. A client cannot create capabilities the server does not provide; changing the local protocol type usually creates a profile with no matching remote endpoint.

For everyday desktop use, start with v2rayN. Import the original subscription and keep the default settings easy to interpret. If you need REALITY or Vision, confirm that the selected Xray core path supports the combination. For a stable VMess, Trojan, or SS profile, check its actual fields and core support; there is no need to migrate just to standardize names. Choose an installer and system architecture on the downloads page. This page focuses on checking whether a profile is compatible after installation.

Android and battery-sensitive use

If you need Xray features on Android, check v2rayNG first. To maintain V2Fly profiles, consider v2flyNG and check settings against that implementation. For the first test, keep Mux and per-app rules simple enough to understand. If the connection drops in the background, check whether the system is stopping the VPN service. If it stays connected but uses more battery, look at app requests and network reconnects rather than blaming protocol header overhead for a system scheduling issue.

On battery-sensitive devices, reduce unnecessary background network activity instead of simply seeking the fewest configuration fields. Choose a combination that connects reliably, avoids frequent reconnects, and meets the workload's needs; then set per-app proxying based on which apps need it. For real-time audio, video, or datagram workloads, verify the UDP path separately. A basic web request is a useful baseline for web use, but it does not prove that every app will work.

Different considerations for stable profiles and new deployments

For a stable existing profile, include maintenance costs in the decision. Switching protocols can affect the remote entry point, security parameters, subscription generation, and compatibility across all devices, without necessarily improving performance. Migrate only when there is a clear need, such as a missing capability in the current core, handshake overhead that is demonstrably a bottleneck, or a setup that has become difficult to maintain. Define a testable goal, not a vague aim to “update things.”

For a new deployment, choose a combination both sides explicitly support, with clear documentation and settings that are easy to verify. If you need familiar TLS operations, evaluate Trojan or a compatible VLESS setup. For an existing SS deployment, check the modern method, key format, and datagram support. For VMess, confirm a modern authentication method and time synchronization. For REALITY, assess Xray support and how authentication parameters will be managed; seeing the name in a client is not enough.

Narrow down options by identifying the failure stage

If import fails, check the share format and client parsing first. If the core will not start, check field structure and feature support. If the address is unreachable, check resolution, port, and network path. If the security handshake fails, check the server name, certificate, or REALITY parameters. If the handshake succeeds but apps do not work, check proxy authentication, routing, and interception scope. Each stage has different evidence. Do not label every issue “the protocol is broken” and replace all the settings at once.

Keeping one known-good profile is valuable: it helps show whether a problem is with the whole device, the current network, or one entry point. When comparing, do not switch networks, cores, and protocols at the same time. Retest in the original environment, then change one thing at a time. Hide credentials in shared logs, but retain the sequence of events and error category. To rebuild a baseline step by step, return to the setup guide; for a specific issue, browse the FAQ by topic.

There is no single protocol choice that works best in every environment. A maintainable setup makes the source of each key field clear, shows how traffic enters the core, distinguishes DNS failures from handshake failures, and can pass the same basic tests after an update. Manage the protocol, security layer, transport, and local policies separately, then test them together. This preserves reliable behavior when migrating devices or changing cores instead of relying on a connection that happened to work once.