The Complete v2rayN Guide
From core concepts to routine maintenance

Stage 1 · Understand the Basics

Core Concepts and the Connection Path

Know the Difference Between the Client, Core, and Remote Service

Start by tracing a connection: an app sends a request to the local proxy, which passes it to the core. Routing rules then decide whether to connect directly or send the request to a remote server. v2rayN is the graphical client that manages these settings: it stores server details, updates subscriptions, selects the active configuration, and starts the core. The core handles protocols and connections. Downloading a client does not provide a remote service; server addresses, identity parameters, and service validity must come from a legitimate provider you already use.

Project V is a useful starting point for understanding this ecosystem; V2Fly and Xray are related core families. The client interface and the core's capabilities are not the same thing: seeing a field in the interface does not mean the selected core supports that combination. If an imported configuration reports an unsupported protocol, transport, or security setting, first check which core is actually running, then review the configuration. Don't mistake missing support for an expired subscription, or assume that a running client means the remote connection is working.

Understand Protocol and Transport Fields

VMess, VLESS, and Trojan are protocol-layer details in a connection configuration. TCP, WebSocket, and gRPC describe transport methods; TLS and REALITY relate to security handshakes and mechanisms. These are not interchangeable performance options. Match the remote service's requirements, including the address, port, user ID, service name, path, and server name. VLESS alone does not provide an encrypted channel; that depends on the complete transport and security configuration.

Domain-related fields may serve different purposes. The server address determines where to connect; the TLS server name is used for certificate and handshake processing; and the WebSocket Host belongs in the request header. These values may or may not match. Resolving an address only confirms that DNS returned a result; connecting to a port does not prove authentication succeeded. Troubleshoot in order: name resolution, network connection, security handshake, protocol authentication, and access to the destination. Don't lump every failure together as a speed issue.

Set Up a Repeatable Test Baseline

Choose one everyday site that should connect directly and one test destination that genuinely requires a proxy. Close other tools that capture network traffic, and note the active server, system proxy status, and routing preset. Use the same browser and network for each test, change one setting at a time, and compare the logs with the result. A page loading once isn't conclusive: caching, reused connections, and an app's own DNS resolution can all affect the outcome. After changing configurations, a new connection is often more revealing than repeatedly refreshing the same page.

Know what test results can—and can't—tell you. A latency result reflects the specific test method; it does not directly measure download bandwidth. A successful web request does not prove that real-time communication, games, or all UDP traffic will work. It's more useful to record which layer failed, which app was involved, and which destination you tested than to write “can't connect.” Each chapter follows the same baseline: confirm one layer before adding the next, and return to the last working state if something breaks.

Stage 2 · Choose Your Tools

Choosing a Client and Platform

Start with v2rayN on Desktop

For Windows, macOS, and Linux, start by considering v2rayN. It brings subscription, server list, and routing management together in one workflow. Before opening the download page, confirm your operating system and processor architecture. Packages aren't interchangeable just because they share an OS label; ARM and x64 packages, in particular, aren't distinguished reliably by their file icons. For a side-by-side comparison, read the client selection guide, then return to the download page to choose the right option.

Windows offers Desktop and the classic WPF edition. Desktop uses a newer cross-platform interface, while WPF retains the familiar classic Windows workflow. If you're new to v2rayN, start with Desktop. If your current setup is stable, compare the interfaces and configuration differences before switching. These editions are not separate service providers. Don't run both at once while troubleshooting: they can interfere with local ports, system proxy settings, and configuration directories.

Choose an Architecture Based on System Information

On Windows, check Settings → System → About for the system type; don't infer it from the computer's brand. On macOS, open About This Mac: choose the Apple Silicon option if it shows an Apple chip, or the Intel option if it shows an Intel processor. On Linux, check both the processor architecture and whether your distribution uses deb or rpm packages. Package format doesn't map one-to-one to desktop environment, so don't copy an installation choice from another machine just because it uses the same desktop.

On Android, start with v2rayNG, which uses the Xray core. Consider v2flyNG when you need behavior consistent with the V2Fly core. Recent mainstream phones generally use arm64; if you can't confirm the architecture, consider the universal build, but check the system requirements first. A universal build addresses package architecture coverage—it doesn't guarantee support for every protocol combination. The two apps may have similar settings, but feature support isn't identical. See Xray vs. V2Fly Core: Key Differences for details.

Choose Based on Requirements, Not Performance Guesswork

Start by listing what you need: support for the remote protocol, subscription import compatibility, whether your apps need TUN, and whether the device permits elevated privileges. Once those requirements are met, compare interface preferences and maintenance overhead. A different client can't improve the quality of a remote connection or fix an expired service or incorrect parameters. When comparing clients with the same configuration, keep the network, destination, and test time as consistent as possible so you don't mistake connection fluctuations for client differences.

Keep your working setup during migration, but don't let both clients capture network traffic at once. Back up the subscription source and any custom rules you need, then verify three things separately in the new client: import, server selection, and access to a destination. Move complex routing over only after that. A phone and a computer can use the same service, subject to the provider's device and concurrent-connection limits. A good selection isn't measured by how many apps you install; it's having one primary client, a recovery path, and a configuration with a known source.

Stage 3 · Complete Initial Setup

Installation, Permissions, and First Launch

Choose a Stable Location for the App

Choose the right package from the download page for your platform, then follow the system prompts. Installers and portable archives need different handling: if you downloaded an archive, extract it fully to a directory you'll keep. Don't launch the main executable from inside the archive utility. On first launch, the app creates configuration and log data, so its directory must be writable. Avoid temporary folders that get cleaned automatically, and try not to let sync software modify the files at the same time.

If Windows reports a missing runtime on first launch, use the error message to identify the required component and architecture. Don't download a supposed repair tool from an unfamiliar pop-up. On managed devices, check whether policy allows proxy software and virtual network adapters. A standard system proxy usually doesn't require running as administrator all the time; TUN may need additional permissions. Test a normal launch and an elevated launch separately to distinguish application issues from directory permissions or network driver problems.

Resolve Startup Issues by Platform

On macOS, move the app to a stable Applications location before launching it. If you see a security warning, first confirm the download source and system compatibility, then use the security settings provided by macOS. Don't blindly copy commands that disable system protections. On Linux, use your distribution's package manager to handle dependencies. If the app won't start, check the message for a missing library or runtime. A working graphical interface doesn't confirm that network permissions are in place; virtual network adapters may require separate system authorization.

After installing v2rayNG or v2flyNG on Android, the first connection may prompt for system VPN permission. This is the system entry point that lets the app handle traffic on your device; it doesn't provide a remote service. Read the permission prompt, then allow the client only if you've confirmed its source. For now, don't enable other apps that use the same entry point. Background restrictions may interrupt connections when the screen is locked; once the basic connection works, adjust the client's background permissions in your device's battery settings.

Check Local Listeners and Client Status

In the v2rayN main window, locate the server list, subscription groups, logs, and status bar. An empty list is normal before you import a configuration; there's no need to change core parameters straight away. Open Settings → Parameter Settings and note the actual local listener address and port. Different configurations may use different entry points. When setting a proxy manually in an app, use the values shown here rather than guessing based on common numbers in tutorials.

If the log says an address is already in use, close other clients first and check for an old process that hasn't exited. Don't keep changing ports at random: browsers or other apps may still point to the original port, creating a second problem. Listener addresses should generally stay local. Only broaden the listening address when you explicitly need to share access on a local network, and set access controls and firewall rules at the same time. Exposing a local port to the network is not a routine fix for connection problems on your own device.

For the first-launch check, confirm just three things: the interface opens reliably, settings can be saved, and the core starts without recurring errors. You don't need every website to work yet; you haven't set up a remote service. Read the v2rayN main window guide to learn where to find logs, then move on to subscriptions. If installation fails, save the original error text and system architecture details. Address the specific environment issue rather than treating an OS reinstall as troubleshooting.

Stage 4 · Import a Configuration

Import Subscriptions and Manage Servers

Tell Subscription URLs and Share Links Apart

First identify what you have. A subscription URL is usually a URL that fetches a list of servers. Content beginning with vmess:// or vless:// is usually a single share link. A complete JSON file may be a core configuration. Don't treat these as interchangeable just because they're all text. The standard subscription update option may not accept a full configuration file, and a share link shouldn't go in a subscription URL field as if it were a web address.

A subscription URL may contain credentials that provide direct access to a service, so treat it like account information. Don't post the full link in public screenshots, forums, or speed-test help requests, and don't submit it to an unfamiliar online conversion site. When sharing a redacted example, keep only the protocol, error type, and necessary field names. If your provider issues a new subscription URL, check whether the old one has expired before replacing it; avoid duplicate groups that point to the same service.

Import and Update by Subscription Group

1. Open Subscription Group → Subscription Group Settings, then add an alias that identifies the source.
2. Paste the full subscription URL into Optional Address (URL). Check for leading or trailing spaces, line breaks, and an incomplete copy.
3. Make sure Enable Updates is selected, save, then choose Update Current Subscription from the Subscription Group menu.
4. Return to the group, check the server list and logs, then select a server to make it active.

For the first update, use the option that doesn't route the request through the current proxy, provided the subscription URL is directly reachable. If the URL requires a proxy, first establish a separate working connection, then choose the menu option to update through the proxy. Don't rely on a subscription you haven't imported successfully to download itself. If an update fails, determine whether the cause is name resolution, a timeout, rejected authentication, or unrecognized content. Don't treat every error as a reason to delete and recreate the group.

Subscription Group → Subscription Group Settings → Optional Address (URL) → Save → Update Current Subscription

Understand How Updates Affect Local Changes

A subscription syncs with its source; it isn't a permanent copy to edit by hand. When the provider updates it, server aliases, addresses, and even entry order may change. Local edits to subscription entries may also be overwritten. To test parameters, first duplicate the entry as a separate item and label its purpose; don't edit your primary source directly. Set automatic update intervals based on actual need. Frequent requests won't create new servers and may trigger access limits from the provider.

If the list is empty, check the selected group and any interface filters first, then review the update log. Getting a login page or an informational page doesn't mean you've received a parseable subscription; expiration, access restrictions, and incompatible formats can all cause import failures. If only an entry for one protocol is missing, check client and core support rather than replacing the entire configuration. For more on subscription formats and conversion limits, see Subscription Formats Explained.

Don't bulk-delete old entries as soon as an update succeeds. Select one new entry and test access first; then check whether the previous active server is still available. Give frequently used groups clear names and note the service period and update method, but never put credentials in an alias. A clearly identified source, active server, and verifiable update result give you a stable base for configuring proxy modes. For the steps only, see Quick Subscription Import Steps.

Stage 5 · Connect Your Apps

System Proxy and Global Proxy

Set Up a Standard Proxy Entry for Apps

After choosing an active server, select Set System Proxy Automatically from the system proxy option at the bottom of v2rayN. This sets the operating-system proxy entry that apps can read, but it doesn't force every process to use it. Some browsers follow system settings, some apps use their own settings, and some connection types don't use a system proxy at all. Test first in a browser that follows system settings, then handle special cases. That's more reliable than assuming the whole computer is captured from the start.

Clear System Proxy removes the relevant system proxy settings. Use it to restore direct access before exiting or to troubleshoot the entry point. Do Not Change System Proxy means the client won't change that setting; it doesn't guarantee that no proxy is currently configured. If a manual setting was left behind, choosing Do Not Change may keep pointing to an old port. If the network stops working after exit, check the address and port in system proxy settings before clearing them. Don't leave apps pointed at a dead entry after the client is closed.

Global Routing Does Not Capture Every App

When someone says “V2Ray global proxy,” ask which layer they mean by “global.” Global routing in the client generally sends requests that have already reached the core through a proxy outbound. Apps that never reach the client won't change routes as a result. System proxy settings control the entry point; routing presets control the outbound. Configure and test them separately. Global routing is useful for a quick check of whether routing rules are the issue. For everyday use, also consider access to local services, devices on your network, and destinations that should connect directly.

Test Browsers and Other Apps Separately

If a website won't load in a browser, temporarily disable extensions that capture proxy traffic and check that the browser isn't configured to use a separate proxy. If the client log shows no new connection, check the entry point first. If the log records a request followed by a remote error, check the active server and handshake parameters. Close old tabs or start a new session before testing to avoid reusing an existing connection. Private browsing doesn't necessarily bypass network settings; it isn't an isolated proxy environment.

Command-line terminals and some developer tools may not follow the system proxy. If the browser works but the terminal doesn't, don't change a server that's already working. Check the tool's own proxy settings and use the actual listener address and port. An HTTP proxy entry isn't interchangeable with a SOCKS entry in every context, and the authentication method must match. For specific steps, see Troubleshooting Browsers and Terminals Separately. Keep a single entry point for now to make diagnosis easier.

Finish by testing recovery: clear the system proxy and confirm that normal direct access works. Restart the client, enable the system proxy, and confirm that the destination is accessible again. This catches leftover system settings and startup-order issues. Proxy setup is complete only when it works both ways: access works when enabled and recovers when disabled. If an app really can't use the standard entry, move on to the TUN chapter rather than changing the routes for the entire computer to support one app.

Stage 6 · Configure Outbound Routing

Routing Rules and DNS

Establish a Baseline with a Preset

Start with a routing preset provided by the client; don't import a large ruleset from an unknown source straight away. “Bypass mainland China” generally sends requests that match the relevant regional rules direct, while other requests follow the preset's proxy policy. “Global” applies the global policy to requests that enter the client. Preset contents may change, so review the actual entries in routing settings. A preset's name is only a summary; it doesn't mean every local-network destination, special domain, or app is handled appropriately.

The core selects an outbound based on routing rules and matching logic, so rule order matters. A broad rule placed too early may prevent later, more specific rules from taking effect. Requests that don't match any rule use the default outbound. When troubleshooting, check both the matched rule and the fallback behavior; don't just check whether a domain appears in the list. Before adding a rule, specify the target domain or network, whether it should connect direct or through a proxy, why it needs an exception, and how you'll test it.

Understand Domain Rules and IP Rules Separately

Domain rules rely on the client receiving the relevant domain information. IP rules match the destination address or a related resolution result. If an app connects directly to an IP address, domain-only rules may not apply. And when a domain uses multiple addresses, relying on just one is unreliable. DNS resolves names; it doesn't automatically determine the outbound for every connection. Routing policy, DNS behavior, and the address actually used by the connection must work together. Changing DNS doesn't simply mean changing the route out.

The following is a core-level rule snippet showing how the fields relate. It isn't a complete, standalone configuration and must not be entered as a subscription URL. It sends the example domain and its subdomains to the outbound named direct, which must already be defined. A graphical client may regenerate its configuration, so make routine changes through its routing interface rather than repeatedly editing runtime files. The example domain is for illustration only; it shouldn't be added to real-world rules by default.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:example.com"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

Diagnose a Routing Issue One Destination at a Time

If a website won't open, temporarily switch to global routing and test the same destination. If it works globally but not with the original preset, focus on rule matching, the direct route, and DNS. If both fail, check the server or the destination service itself. Start a new connection after each change so an old connection doesn't keep its previous outbound. Don't change DNS, the server, and routing at the same time; even if access returns, you won't know which change fixed it.

For a router admin page, printer, or local development service, check that private addresses and local domains are routed direct. A remote proxy server usually can't reach an address that exists only on your local network. Conversely, don't route an unnecessarily broad range of public IP addresses direct just to fix one local destination. Sniffing may help recover domain information for some connections, but it won't identify all encrypted traffic and may affect app compatibility. Enable it only when needed, then test the result.

Keep rules clear and minimal. Document the purpose of custom entries, periodically check for outdated domains and overly broad matches, and retest key destinations after updating rule resources. When you switch networks, compare DNS results and local network conditions before changing long-term policy. You've completed this chapter when you can explain why a request uses a particular outbound and know what happens if no rule matches—not when you have the longest ruleset. Keep this verified routing baseline when you move on to TUN.

Stage 7 · Capture More Traffic

TUN Mode and Network Recovery

Confirm That You Need a Virtual Network Adapter

Consider v2rayN TUN mode when an app doesn't use the system proxy or you need more types of connections to enter the client. TUN routes traffic through a virtual network adapter; it isn't a faster server and can't fix an invalid remote configuration. First confirm that the same active server works with the standard proxy. Only then enable TUN. If the standard proxy isn't working yet, adding a virtual adapter introduces permissions, routing, and DNS as extra variables, making the original problem harder to diagnose.

Before enabling it, save your working configuration, note the current system proxy state, and pause other tools that modify system routes. Workplace networks, remote-access tools, and other virtual adapters may compete with TUN for the default route or DNS. Don't risk capturing all traffic over the only connection you can reach through remote desktop; prepare local access or an alternative connection first. Managed devices may block virtual network drivers or elevated permissions. Check whether your organization's policy allows them rather than repeatedly bypassing permission prompts.

Check Permissions, Routing, and DNS in Order

Find Enable TUN in the v2rayN main window and grant the required permissions when prompted. If startup fails, check the logs for insufficient permissions, adapter creation errors, or address conflicts, then address the specific issue. Changing servers won't help if the virtual adapter wasn't created. If the adapter is created but all traffic fails, check whether the system routes are active, the default route is correct, and DNS requests have a working path. Menu names may vary by platform; follow the interface you have.

For the first test, don't use both the system proxy and TUN to prove the same result. Depending on how your client works, temporarily clear any unnecessary system proxy entry, then test with an app that doesn't normally use the system proxy. If only the browser works, it may still be using the standard proxy. Check connection logs, destination access, and recovery after exit to confirm that traffic capture is actually working. Test UDP with an app that explicitly depends on it; a website loading does not prove UDP support.

Preserve Local Network and Special-Use Routes

Printer discovery, local file sharing, virtual machines, and container networks can all be affected by route changes. If a local service becomes unreachable, check its address and subnet, then review exclusion rules rather than routing all traffic direct. DNS capture can also change how internal domains resolve, so corporate networks may need their dedicated resolver to remain reachable. To sign in to a public Wi-Fi captive portal, you can temporarily disable traffic capture, complete sign-in, then re-enable it and test again.

Don't treat MTU as a default speed boost. Consider changing it only when the basic connection works, some connections consistently fail with large packets, and you have a specific test to support the change. Random values can hide the real route or protocol issue. After sleep, switching Wi-Fi networks, or connecting to a hotspot, try reconnecting or restarting TUN first, then compare route changes. Issues on different networks may have different causes, so record each environment separately.

To recover, turn off TUN and exit the client, then check that no system proxy settings remain. If the issue persists, check other network tools and system DNS settings, and reconnect to the current network if needed. Don't delete every network adapter or reset all network settings without first identifying the problem. Reliable everyday use means your common apps, local network access, sleep and wake, and recovery after exit all pass testing. If the standard proxy meets your needs, stay with it and reserve TUN for situations where it serves a clear purpose.

Stage 8 · Keep Your Setup Maintainable

Updates, Backups, and Troubleshooting

Handle Three Types of Updates Separately

Treat client updates, core updates, and subscription updates as separate tasks. Client updates affect the interface and configuration management; core updates affect protocol handling and runtime behavior; subscription updates sync remote entries. They aren't the same thing, and a problem doesn't mean you need to run all three. Record the working state first, update one component as needed, and verify access before moving on to the next. If compatibility issues appear, this makes it easier to identify where the change occurred.

Before using an option such as Check for Updates, read the prompt and keep a configuration backup. If you need a different installer, choose one for your platform from the download page. Don't overwrite your only working copy just to get the latest features, especially if it has custom routing or complex DNS settings. Your backup should include subscription sources, independent server details, routing rules, and notes on essential parameters. Data locations vary by OS and installation type, so confirm them in the client's data management settings.

A Useful Backup Is One You Can Restore

Configuration files may contain user IDs, subscription credentials, and connection passwords; store them somewhere access is restricted. Before syncing across devices, review the sync service's permissions. Don't upload a complete configuration to a public share. Record the client edition and key settings, then test a restore in a separate directory or controlled environment. Copying only the app doesn't usually preserve user settings, while screenshots can't accurately reproduce hidden fields. Neither replaces a complete backup.

For everyday use, keep one recently verified working configuration and one pre-update backup; there's no need to accumulate an unlimited history of credential-bearing files. When moving to another computer, restore the basic subscription and active server first, then add routing and TUN. System proxy settings, driver permissions, and local ports belong to the device environment; don't assume they migrate successfully with the configuration file. Once the new device works, revoke old device access or clean up old data as needed.

Use Logs to Narrow Down Problems Instead of Reinstalling

If V2Ray won't connect, note when it happened, the app and destination involved, active server, proxy entry point, and most recent change. Then check the logs for the same period. For a resolution failure, check DNS and the domain. A connection refusal may involve the port or service status. For a security handshake error, check the time, server name, and security parameters. For an authentication failure, review the identity details. A single failed log entry doesn't necessarily mean the whole service is down; compare it with actual access and repeat tests.

Troubleshoot slow speeds layer by layer: try another working server in the same group, compare different times and destinations, then check local resources, network capture conflicts, and routing settings. Low latency alone doesn't guarantee high throughput, and a remote destination's speed limit isn't a local port issue. Use the layer-by-layer slow speed troubleshooting guide to keep test notes. Change one variable per round and roll it back if it fails. That's usually more effective than piling up unverified tweaks.

Redact logs before sharing them: hide subscription URLs, identity details, passwords, and full browsing records; include only the context needed to understand the error. Temporarily increasing log detail can help with diagnosis, but overly detailed logs kept long-term consume disk space and expose more private information. Restore an appropriate level when you're done. Check service validity, automatic update results, and backup availability regularly instead of waiting for your primary server to stop working.

Follow a simple maintenance order: check that the source is still valid, confirm the active server, verify the proxy entry and routing, then check the system environment. Reinstall only when the app or its configuration is genuinely damaged and you have what you need to restore it; it's not the first step for every network issue. Keep custom settings minimal and document why each one is there. That makes it easier to recover after changing devices or networks.

Stage 9 · Build Your Configuration Skills

Next Steps and Configuration Checks

Understand the Configuration Before Trying Complex Setups

After completing the first eight stages, learn the structure of core configurations: inbounds, outbounds, routing, DNS, and logs. The goal isn't to replace the graphical interface with hand-written files, but to understand generated output and where each setting takes effect. A graphical client manages and generates runtime configuration; edits to a temporary generated file may be overwritten on restart or server change. First distinguish persistent user settings, custom configuration, and runtime files, then decide where to make a change.

When reading a configuration, trace a single request: which inbound receives it, what destination information it carries, which rules it matches, and which outbound is selected. Then inspect how names reference one another, especially whether the outbound tag used by a routing rule actually exists. Valid syntax doesn't guarantee correct behavior, and parseable JSON doesn't mean the remote service accepts the parameters. Check syntax, core startup, and destination access as three separate acceptance tests. This avoids mistaking “file saved successfully” for a working setup.

Learn Protocols and DNS as Needed

Start learning a protocol with the capabilities your existing service requires. With VLESS, understand the distinct roles of the user ID, transport type, and security layer. For features such as REALITY, check each requirement against the provider's instructions; don't combine parameters from a different configuration. Core support and default behavior can vary, so verify actual capabilities before migrating. If you encounter an unfamiliar option, read the relevant core's documentation and test it in a separate entry rather than overwriting your primary configuration.

For advanced DNS, trace the resolution path: which component sends the query, whether it goes direct or through a proxy, how the returned address affects routing, and whether the app bypasses system resolution. Encrypted DNS isn't a switch that automatically fixes privacy and connectivity issues; it still needs a working network path and may conflict with corporate internal domains. Don't change the resolver, domain policy, and routing resources all at once. Keep a working baseline and verify the expected change at each layer.

Validate the Complete Setup with a Scenario Checklist

Don't validate your setup with just one website. Test a standard browser, an app that needs its own proxy settings, local network destinations, and any UDP scenarios you actually need. Then test exiting the client, system sleep, network changes, and restart. Define the expected behavior for each case: what should use the proxy, what should stay direct, and whether connections recover after disconnecting. If a scenario isn't relevant yet, mark it untested rather than assuming one successful test proves everything works.

For multiple devices, import a legitimate source separately on each device and test it for that platform. Only look into listening on a local network if you explicitly need to share this device's proxy entry. Broadening the listener may let other devices access the proxy service, so consider authentication, firewall rules, network trust, and service terms. Don't treat Allow LAN Connections as a routine speed boost, and don't expose a local management interface to an untrusted network.

Choose articles by the problem you're trying to solve: for the interface, read the main window guide; for imported data, read subscription and share formats; if you’re mixing up the entry point and routing, return to this guide’s proxy mode and routing chapters. This site doesn't have a separate FAQ page. For common setup questions, continue with the verification steps in the user guide instead of looking for a menu or page that doesn't exist.

A complete setup should be understandable, repeatable, and recoverable: know where the configuration comes from and what permissions it needs, how apps reach the client, why rules select a particular outbound, and how to roll back a failed update. Keep one simple primary setup and use a separate configuration for experiments. When new protocols, networks, or apps come along, follow the same path—concepts, entry point, outbound, verification—instead of guessing every parameter from scratch.