V2Ray Protocol and Core Guide

Clients, cores, and servers are different things

v2rayN, v2rayNG, and v2flyNG are graphical clients. They manage subscriptions, display configurations, generate runtime parameters, and coordinate the system proxy or virtual network interface. The core establishes connections, handles protocols, resolves domains, and applies routing. The server is the service on the other end of the connection. Seeing an option in the interface only means the client can represent it. Actual support depends on the running core and server configuration, so interface support alone doesn’t guarantee end-to-end compatibility.

Think of an outbound connection as a stack of layers. The proxy protocol handles user authentication and the destination address; the transport carries bytes to the other end; the security layer protects the connection and verifies the peer; routing decides which requests use that outbound; and the inbound accepts traffic from local apps. These layers work together but aren’t interchangeable. Changing routing won’t fix a wrong password, and enabling the system proxy won’t supply a missing server certificate name.

A protocol name describes only part of the connection

For example, VLESS can be used with different transport and security settings. Two VLESS configurations may differ: one might use standard TLS, while another uses REALITY. They require different fields and server capabilities. WebSocket is a transport, not a proxy protocol on the same level as VLESS. TLS is not another name for a node password. When reviewing a subscription, note the protocol, address, port, transport, security method, and credentials separately instead of remembering only the protocol label.

In a client, “address” usually means the domain or IP used to connect to the server. “Server name” often maps to TLS serverName and may also appear as SNI. The WebSocket Host and path belong to the application-layer request. These values may match, or the server may require different ones. Replacing them all with the domain in the address field may look tidy, but can break certificate validation or reverse-proxy routing. Follow the field mapping from your configuration provider; similar-looking field names aren’t a reliable guide.

Test importing and connecting separately

A successful import only means the client accepted the input format and created an entry. Some advanced fields may not have been recognized, and defaults may differ from the original configuration. A working connection also requires a reachable address, an open port, matching credentials, correct security parameters, and routing that allows the destination. Even a node with a complete name and normal-looking icon can fail before the handshake. Check the details first, test one connection, and only then compare the experience.

This layered approach also narrows down troubleshooting. If there are no request logs, check the inbound and routing. If the server connects but authentication fails, check the protocol credentials. For certificate or handshake errors, check the security layer and system time. If only certain sites fail, look at DNS, the destination, and routing. Troubleshooting one layer at a time is easier to reproduce than changing the protocol, core, and routing all at once. For concise field definitions, see the Glossary; the sections below cover the trade-offs and limits of each layer.

VMess: authentication and data protection within the protocol

VMess developed within the Project V ecosystem. It uses a user identifier for authentication and handles data protection within the protocol itself. Unlike approaches that rely on a security tunnel at the outer layer, VMess does more within the proxy protocol. Configuration requires more than identifying the UUID: check the implementation’s authentication mechanism and encryption options too. Extra identity fields found in older configurations are historical; don’t add values based on outdated guides. For connections to modern servers, use an authentication method supported by both implementations.

VMess authentication is time-sensitive. A device clock that’s significantly off can cause authentication to fail, even if the error doesn’t mention the time. Enable automatic time synchronization first, then check the authentication logs; that’s often more useful than repeatedly refreshing the subscription. VMess can be a good fit for an established deployment with clearly defined client and server settings. There’s no need to migrate a working connection just to adopt another protocol. A protocol’s age alone says nothing about its performance or the maintenance status of a specific implementation.

VLESS: assign each responsibility to the right layer

VLESS uses a leaner proxy protocol design. It handles authentication and request details, but doesn’t provide the same built-in data encryption role as VMess. So encryption: none in a VLESS configuration doesn’t necessarily mean the entire connection is unencrypted; protection may come from TLS or REALITY. Conversely, seeing VLESS doesn’t guarantee the connection is protected. Always check the security layer too; don’t interpret a none option in isolation.

The VLESS flow field also deserves attention. It specifies a particular traffic-handling mode, such as a Vision-related value, but not every transport can be paired with every flow. A client accepting a value doesn’t mean the server supports it, and a missing field in a subscription isn’t a reason to add one manually. If the server specifies a flow, keep it unchanged and check that the core supports it. A lean protocol doesn’t mean you can combine settings however you like; with fewer responsibilities in the protocol itself, the boundaries between layers matter more.

Trojan: a proxy connection built on TLS

Trojan typically uses TLS for outer-layer protection, then handles password authentication and proxy requests within that connection. The settings users most often see are the server address, port, password, and server name. Password authentication and certificate validation serve different purposes: the password checks whether you’re allowed to connect, while certificate validation helps confirm the peer is the expected server. Fixing a password won’t resolve a certificate name mismatch, and disabling certificate validation won’t fix a wrong password. Troubleshooting starts with identifying which stage failed.

When choosing Trojan, check the certificate chain, server name, and whether the deployment uses a reverse proxy. Connecting by domain usually makes it easier to match the server name to the certificate. If you enter an IP address, you may still need to specify a valid server name separately. Support for additional transports or multiplexing depends on the core and server implementation; don’t assume an extension offered by one client is available in every Trojan deployment. Keep the base protocol separate from implementation-specific extensions.

Shadowsocks: compact data encapsulation and method compatibility

Shadowsocks typically encrypts and encapsulates the proxy data stream directly. The key settings are the address, port, encryption method, and password. It doesn’t require a standardized certificate handshake, which can make it a good fit for deployments that aim to keep the outer layer simple. But not all Shadowsocks methods are compatible with one another. Legacy methods, modern AEAD methods, and the Shadowsocks 2022 family have different requirements; password formats and length constraints may also vary. Don’t copy a password without checking the method name.

Choose based on the actual deployment: which server is available, whether UDP is needed, which methods the device’s core supports, and whether the subscription can represent all required parameters. Don’t assume Shadowsocks always uses less battery on every phone just because it’s “lightweight,” or that VLESS is always faster because it has fewer fields. For a broader comparison, see Four protocols compared by use case. The key principle here: confirm compatibility and functionality first, then compare overhead under like-for-like conditions.

REALITY is a security mechanism, not a standalone proxy protocol

REALITY often appears alongside VLESS, but they’re not interchangeable options at the same layer. VLESS handles proxy requests; REALITY handles the security handshake and related verification for the outer connection. Common client fields include the server name, server public-key parameters, a short ID, and a client fingerprint. The server’s private key shouldn’t appear in a client subscription. Different interfaces may label public-key parameters differently; check the documentation for your client and core instead of judging a setting by its name or age.

A REALITY handshake requires the client parameters and server settings to match. The server name generally must be among those allowed by the server, the public-key parameters must correspond to the server’s key, and the short ID must be one the server accepts. Some deployments allow an empty short ID; others require a specific value. Client fingerprints help construct handshake characteristics; entering any browser name at random won’t improve the connection. Valid values and behavior depend on the core implementation.

TLS: name validation is more than an open port

A standard TLS connection must validate the certificate chain and certificate name. A successful TCP connection to the server port only means the network connection reached it; it doesn’t mean the peer’s certificate is trusted or proxy authentication succeeded. Common issues include an incorrect device clock, a missing intermediate certificate, a server name that doesn’t match the certificate, or a reverse proxy routing the request to the wrong service. Fix these at the certificate or deployment layer instead of leaving verification disabled as a permanent setting.

ALPN negotiates the application-layer protocol; it isn’t a generic speed boost. Some transports depend on a particular negotiation result, while some servers use it to choose how to handle the connection. Changing or removing ALPN can cause requests to fail even after the handshake completes. If your subscription specifies ALPN, keep that value. If it doesn’t, don’t copy one from another node without a reason. A field that looks optional may serve a specific purpose in a given deployment.

The real costs of TCP, WebSocket, and gRPC

TCP is usually straightforward, with relatively little extra encapsulation. WebSocket first completes an HTTP upgrade before carrying data, and its path and Host must match the deployment. gRPC typically relies on HTTP/2, requires a matching service name, and needs support from any intermediary proxy. These transports address delivery and deployment compatibility; they aren’t a ladder where more complex means more advanced. A combination the server actually supports is more important than choosing the newest-sounding transport.

With a reverse proxy, also consider idle timeouts, request size limits, long-lived connection handling, and the upstream protocol. If web browsing works but long sessions disconnect periodically, a timeout at one layer may be to blame—not a sudden failure in proxy authentication. A one-character difference in the WebSocket path or a missing gRPC service name after conversion can cause an ordinary HTTP error. Check the path and proxy logs instead of continuing to change the local listening port.

Multiplexing and UDP depend on the whole connection path

Multiplexing lets multiple logical connections share one underlying connection, which can reduce repeated connection setup. But a shared connection also means congestion or failure can affect them all. If the transport already supports multiplexing, adding another layer may not help. Whether to enable it depends on the core, protocol, server, and application; it shouldn’t be a global default. For troubleshooting, start with a simple setup, then compare short requests and sustained transfers with multiplexing enabled and disabled.

UDP support depends on the inbound, proxy protocol, core encapsulation, server, and destination network all working together. A local SOCKS inbound that accepts UDP doesn’t mean a standard HTTP proxy behaves the same way. And if an app doesn’t use that inbound, protocol support elsewhere won’t help. For problems with voice, games, or other UDP apps, trace how traffic enters the client, how the outbound carries it, and what the server allows. A “UDP supported” label alone isn’t enough to draw a conclusion.

Separate probe latency, first response, and sustained throughput

TCP latency in a client usually measures the time to establish a connection to the server port. A real request test may also include the security handshake, proxy authentication, and destination response. These measure different things, so their results aren’t interchangeable. A fast TCP probe doesn’t guarantee fast page loads if destination routing, DNS, or server load is the bottleneck. Conversely, a failed probe may mean the test target or method isn’t suitable; it doesn’t prove that all traffic will fail.

Time to first response measures how long a new request takes to return data. Sustained throughput measures how much data the connection can carry after it’s established. Security handshakes and transport upgrades are more likely to affect the first; link bandwidth, congestion control, and server egress are more likely to affect the second. Web pages also load many small resources concurrently, so a smooth large-file transfer doesn’t guarantee a fast page render. Before comparing protocols, decide whether you’re optimizing connection setup, everyday browsing, or long transfers. Match the metric to the goal.

Compare protocol overhead under like-for-like conditions

Protocol encapsulation, authentication, and encryption use CPU resources, but they’re rarely the only factors that shape performance. Distance, packet loss, network handoffs, server congestion, and destination differences often matter more than a few extra bytes in a protocol header. For a meaningful comparison, use the same device, network, server region, and test destination where possible. If two subscriptions connect to different servers, the results describe the two complete routes—not the protocols alone.

Hardware also affects the results. Processors vary in their support for encryption acceleration, and core implementation, system scheduling, and thermal limits all affect performance. A laptop may behave differently on battery power than when plugged in; a phone may slow down under sustained heat. Without consistent devices and test conditions, there’s no meaningful universal ranking of resource use. For most people, a stable connection that meets their needs matters more than chasing a small, short-lived difference.

Memory and battery use often depend on how the client runs

Memory goes to more than protocol processing: it also supports connection buffers, DNS caches, routing data, and interface lists. Importing many nodes, keeping verbose logs for too long, or loading large rule sets may have a bigger impact than changing proxy protocols. Distinguish the graphical client from the core process, and check usage after the system has been running steadily rather than at startup. Removing duplicate groups and shortening unnecessary log retention are easier to interpret than repeatedly changing cores to lower a number.

On mobile devices, battery use often depends on how frequently the wireless radio wakes up. Frequent probes, very short keepalive intervals, repeated reconnects on an unstable network, and constant background app requests can all extend active time. A protocol that saves a little during one handshake may use more battery if it keeps disconnecting in real-world conditions. Check idle behavior, normal browsing, and recovery after network changes; a quick test can’t stand in for a full day of use.

Keep repeatable comparison notes

Keep one known-working configuration as a baseline. Use the same test sites and apps, and record first-request time, sustained transfers, idle behavior, and recovery after network changes. Change one variable per round, restore the baseline when you’re done, and then test the next setting. Don’t change the protocol, server, and DNS at the same time; even if performance improves, you won’t know why. Node speed tests are useful tools, not the final verdict. Judge by whether real tasks complete reliably and whether errors can be reproduced.

How Project V, V2Fly, and Xray are related

Project V provides context for understanding this software ecosystem, and V2Ray was once one of its widely used core implementations. The V2Fly community continues development and maintenance of the V2Ray core. Xray grew from related code into an independent project with its own feature roadmap. The projects share history and concepts, but they aren’t two names for the same program. When reading documentation, check which core it describes; don’t assume a feature added by one is automatically available in the other.

Both cores can handle proxy connections, routing, and domain resolution, but their protocol extensions, transport details, DNS behavior, and configuration fields can differ over time. REALITY and XTLS Vision are common examples when exploring Xray’s feature set; that doesn’t mean V2Fly accepts the same parameters in similarly named fields. Likewise, verify that a transport or option documented for V2Fly is supported by the current Xray implementation instead of assuming full compatibility based on their shared history.

Choosing between the three clients

For desktop use, start with v2rayN. It supports Windows, macOS, and Linux, and lets you manage subscriptions and inspect outbound settings in a graphical interface. Interfaces and bundled components can vary between releases, so check the OS and architecture details on the client downloads page before choosing a package. The Windows desktop version uses a cross-platform interface, while the classic WPF version has a different look and workflow. That’s a choice of interface and distribution—not a direct measure of protocol speed or core features.

On Android, v2rayNG with the Xray core is the first option to consider. If you need to verify compatibility with V2Fly, consider v2flyNG instead. The clients may share similar interface concepts, but that doesn’t mean they support the same protocol extensions. If a subscription includes parameters that specifically depend on Xray, first confirm that your client and core match. Don’t import it and then delete fields you don’t recognize; that may let the configuration start, but it can also break the server’s requirements.

Similar configuration syntax doesn’t mean you can copy it as-is

Inbound, outbound, and routing structures in core JSON use similar concepts, but their fields, defaults, and valid combinations may differ. A parser accepting a configuration doesn’t prove it will behave as intended: unknown fields may be ignored, default routing may differ, and DNS queries may take a different path. When migrating, check the protocol and security layer first, then the transport, then routing and DNS. Don’t move a complex configuration all at once; if it fails, it’ll be hard to identify the cause.

Clients typically convert their own node model into a core configuration. If you edit a setting in the interface, the generated file may be overwritten at the next startup, so directly editing a temporary runtime file usually won’t persist. For advanced customization, use a configuration option the client explicitly supports, and check whether it replaces default routing or remains compatible with subscription updates. Runtime logs can confirm which core started, but avoid publicly sharing file paths or configuration contents from those logs.

Keep a rollback path when updating or migrating

Updating a client and updating a core solve different problems. A client update may change the interface, subscription parsing, or parameter generation; a core update may change protocol implementation or runtime behavior. If something breaks after an update, note exactly what changed instead of blaming the whole release. Test a small number of configurations, common apps, and network handoffs first, then restore the full rule set. Unless you have a clear need, don’t replace every component just to try an extension.

Keeping a rollback path doesn’t mean using an old implementation forever; it gives you a point of comparison when troubleshooting changes. Before updating, export the configuration you need and note important interface settings, then compare startup logs with actual requests. If the interface shows an unexpected core, correct the client setting first. If only a particular extension fails, check its documentation. Separating ecosystem history, client capabilities, and the core that actually runs helps avoid most “why does the same configuration behave differently?” misunderstandings.

Subscription URLs, share links, and runtime configurations

A subscription URL fetches a set of configurations; a single-node share link describes one connection; a core runtime configuration describes how a process operates. They aren’t the same kind of file. A subscription response may contain multiple links, be Base64-encoded, or use a client-specific structure. Opening the URL in a browser only confirms that the server returned something. If it returns a login page, a message, or an error page, the client will still report a format error. When an update fails, distinguish connection problems from response-format problems.

Common share formats include URI schemes such as vmess, vless, trojan, and ss. VMess links often use an encoded JSON payload; VLESS and Trojan links commonly put connection parameters in the query string; Shadowsocks has several formats, including encoded credentials. Parameters in a share link are part of its format, not arbitrary notes. Different share formats for the same protocol may rename fields or limit what they can express. The first few characters alone don’t tell you whether the full configuration is compatible.

What may be lost during import

Advanced security settings, flow, ALPN, client fingerprint, WebSocket Host and path, gRPC service name, and some UDP encapsulation options deserve careful checking. Some subscription formats can represent only basic connection settings, not every core feature. A converter that doesn’t recognize a field may drop it; an unsupported client may keep only the note and basic address. An entry that appears to import successfully may no longer match the original configuration.

Encoding can also change the result. Special characters in query parameters usually need correct percent-encoding, and notes and credentials may follow different encoding rules. A link can be altered if its ending is cut off, a line break is inserted in the middle, or encoded content is decoded twice. Don’t replace symbols by hand just to make a link “easier to read.” If you must make a change, compare every field in the client’s details view rather than judging the share text by appearance.

What to check when a subscription update fails

First, check that the URL is complete, especially if it has query parameters. Then confirm whether it requires a login, has expired, and can be reached from your device. If the logs show a network timeout, check whether the subscription is fetched directly or through the current proxy. Some clients offer different update routes; relying on a broken proxy to fetch its own subscription can create a loop. Choose a reachable route for your setup instead of repeatedly clicking the same button and hoping for a different result.

If the request succeeds but parsing fails, confirm that the response is a subscription format supported by the client—not a web page. Avoid uploading a full subscription to an unfamiliar conversion service; the URL and returned data may contain account credentials. Asking the configuration provider for the correct format is usually more direct. To report a problem, share the error type, client name, selected core, and a redacted outline of the fields. Don’t post the full subscription URL or authentication details publicly.

Groups and the limits of update preservation

Subscription nodes are often regenerated during updates, so manual changes may be overwritten. For test configurations you need to keep, copy them to a separate local group and label their purpose. Group notes are for organization, not security isolation. Before deleting a group, check whether it contains manually maintained nodes mixed in with subscription data. Removing duplicate entries regularly also reduces the chance of accidentally choosing an outdated endpoint.

When moving between clients, test one configuration first, checking that its settings survive a round trip, before importing the entire subscription. The goal isn’t to match the number of nodes; it’s to preserve the important parameters. If the base settings match but behavior differs, revisit core compatibility and extension support. If connections work but routing differs, check the client’s local routing; a subscription usually isn’t a complete routing policy. The subscription supplies connection details, while the local client decides how to use them.

Desktop work: make sure apps use the same inbound

On desktop, start with a simple, verifiable setup in v2rayN. Browsers, terminals, and productivity apps may not use the same proxy settings: some follow the system proxy, some have their own settings, and others need to be configured individually. One browser working doesn’t mean all apps are sending traffic through the core. First confirm how each app connects, then compare protocols. The system proxy works for apps that follow system settings; it doesn’t automatically capture all traffic on the device.

Everyday work involves many short requests, persistent meeting connections, and background sync. Rather than focusing on one speed test, pay attention to long-connection stability, consistent DNS behavior, and understandable routing rules. If an existing TLS or REALITY setup works, keep its default parameters to start. For apps that need UDP, verify support at each layer. Don’t enable a complex mode just to make every request appear to “take the same route.” First identify what each app needs, then choose the inbound and routing scope.

Mobile use: check network handoffs and idle recovery

On Android, start with v2rayNG and verify settings against the protocol combinations supported by Xray. When a phone switches between Wi-Fi and mobile data, its source address and underlying connection may change; existing connections often need to recover or reconnect. Recovery speed depends not only on the protocol but also on the client’s network monitoring, system background limits, server timeouts, and app retry behavior. Test by switching networks and opening your everyday apps; one successful connection on a fixed network isn’t enough.

Adjust battery settings based on what’s happening. If the system stops the client, the connection may drop when you leave the foreground. Letting all background activity run unrestricted may also add unnecessary active time. First check whether the system is applying overly strict background limits, then see whether the client keeps reconnecting or probing while idle. Allow only the background activity you need; frequent speed tests aren’t a way to keep a connection alive. The goal is reliable service while you’re using it and fewer unnecessary wake-ups when idle.

Weak networks: reduce variables before changing protocols

Packet loss, jitter, and intermittent disconnects are common on weak networks. Switching proxy protocols won’t fix an unreliable underlying link. Start with a stable path and a straightforward transport, and avoid stacking multiplexing and extra forwarding layers while troubleshooting. If new requests often fail but established connections are relatively stable, focus on handshakes and reconnects. If ongoing transfers stall, look at congestion and packet loss. These symptoms need different checks; “the protocol is bad on weak networks” isn’t a useful catch-all explanation.

Multiplexing may reduce repeated connection setup when many short requests are involved, but a problem with the shared underlying connection can affect multiple requests at once. Establish a baseline with optional multiplexing turned off, then compare settings against your actual workload. That’s more reliable than assuming it must be enabled on weak networks. If your transport relies on HTTP/2, also confirm that intermediary proxies can maintain long-lived connections reliably. Complex setups have their place, but they shouldn’t add unknowns when you’re troubleshooting an unstable network.

Test sustained transfers and real-time apps separately

File transfers depend more on sustained throughput, connection stability, and server egress; real-time voice depends more on jitter, packet loss, and the UDP path. A fast download doesn’t guarantee good call quality, and low web latency doesn’t guarantee a large transfer won’t hit thermal or bandwidth limits. For long-running tasks, observe a real session and watch device temperature, error logs, and recovery after disconnects. Tests that resemble everyday use provide more useful results.

If you need a V2Fly-specific compatibility path, you can test it in a separate v2flyNG configuration, but it isn’t a universal fix for connection problems. If the server parameters depend on Xray, switching to a different core may introduce new issues. Match the client, protocol, and server: first find out what the server supports, then choose a client that preserves all required parameters, and finally compare how each setup performs in everyday tasks. Don’t choose by name alone.

Write conclusions as conditions, not rankings

A useful conclusion sounds like: “On this device and network, these settings reliably support meetings and syncing”—not “this protocol is always the fastest.” The conditions include the device, core, inbound, transport, security method, and server route. Record them so you can retest when the network changes or components are updated. If several configurations meet your needs, favor the one with clear structure, reliable settings, and an easy recovery path to reduce long-term maintenance.

Start with a minimal working baseline

Choose a complete configuration and use the client defaults or a clearly documented routing setup. Start by testing one ordinary web request. Don’t import complex custom rules, change DNS, enable multiplexing, and switch cores all at once. Open the logs, confirm the core starts successfully, then confirm that the request reaches it. If startup fails, speed tests won’t help; first address syntax errors, port conflicts, or unsupported options until the process runs reliably.

Be clear about the local listening address too. The following is a minimal inbound snippet for use in the inbounds section of a complete Xray configuration. It illustrates how the fields fit together; it’s not a complete configuration with a remote server. The SOCKS inbound listens only on the local loopback address and isn’t exposed to the LAN. The port must match the one entered in the app. If the client already uses that port, another process can’t bind to it at the same time. For everyday graphical setups, prefer changing the corresponding setting in the client interface.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ]
}

Narrow down the problem by the stage where it fails

If there are no request logs, first check whether the app is using the local inbound and whether routing sends the request directly. For a connection timeout, check the server address, port, current network, and server listener. An immediate refusal usually means the target port isn’t accepting connections, but confirm that against the logs. If the failure occurs during the handshake, check the TLS server name, certificate, REALITY parameters, and system time. For authentication failures, check the UUID, password, or encryption method; don’t treat different error types as the same problem.

If the server connection is established but only certain domains fail, distinguish the destination site itself from DNS results and routing matches. Direct DNS and proxy DNS may run in different places and return different results for the same domain; whether a DNS query goes through the proxy also depends on the core’s policy. Changing to a public resolver alone doesn’t prove the issue is fixed. For more on DNS paths, see How to test and configure DNS in v2rayN, then verify with real requests.

Use logs to trace traffic, but keep sensitive details private

Focus on timestamps, inbound sources, matched outbounds, and error types. A single warning doesn’t necessarily mean the whole connection failed; it may be a background request rejected by its destination. Conversely, an interface showing “running” doesn’t prove that app traffic is working. Temporarily reduce activity in other apps, make one clear test request, then find the matching log entry by time. Increasing log detail temporarily can help; restore the normal level afterward to avoid generating large logs indefinitely.

Before sharing logs, remove subscription URLs, credentials, private domains, and parameters that could identify an account. For a useful report, include the client name, core type, inbound method, protocol and security-layer combination, and enough context around the error. Don’t publish the full runtime configuration or treat a complete subscription as an ordinary test URL. Redaction doesn’t mean removing all technical detail: keep the structure and cause of the error while removing credentials that could be used to connect.

Restore complex settings only after the baseline passes

Once the minimal setup works, restore routing rules, DNS settings, custom inbounds, and multiplexing one at a time, repeating the same request after each change. If the problem returns after restoring a setting, investigate that setting instead of randomly trying protocols again. Watch rule order in custom routing: a broad rule placed first can match requests before a later, more specific rule ever gets a chance. See How routing rules are matched and prioritized for syntax details, and still change only one variable at a time.

Final checks should cover normal browsing, the apps you actually use, recovery after idle periods, and network handoffs. If you need UDP, test the relevant app separately. If you use multiple devices, verify the inbound on each one; success on one device doesn’t prove the others work. Save a configuration you can restore and note the reasons behind key choices. If a problem comes up later, compare changes in the environment and settings before deciding whether to update or migrate. For installation and importing, see the Quick Start Guide. Choose an installer and platform on the client downloads page.