V2Ray from Beginner to Advanced: Installation, Subscriptions, Routing & TUN

Understand Cores, Clients, Nodes, and Subscriptions

The core handles connections; the client provides the interface

V2Ray is not a single installer. It is a technology stack that brings together protocols, transports, routing, and connection management. In practice, the core reads the configuration and establishes network connections, while the graphical client turns subscription imports, node switching, system proxy settings, and log viewing into clickable controls. v2rayN, v2rayNG, and v2flyNG are graphical clients that call the relevant core to connect. When troubleshooting, distinguish between “the interface setting did not take effect” and “the core failed to connect”: the former usually requires checking the client status and system proxy, while the latter requires checking node parameters, the network, and core logs.

A node is a set of connection parameters, not a subscription

A node describes at least a server address, port, protocol, and authentication credentials. Some protocols also include a transport, TLS settings, server name, path, or service name. The node determines where the client connects and how the connection is established. A subscription is a link used to distribute nodes and group information in bulk. After updating a subscription, the client parses the returned content and builds a node list; an update does not guarantee that every node works, nor does it replace connectivity testing. If the node list is empty, first confirm that the subscription parsed successfully instead of repeatedly switching proxy modes.

System proxy settings and traffic forwarding are separate layers

A running core only means that the local proxy port is listening; it does not mean application traffic is passing through it. Browsers and other applications that follow system network settings usually enter the client through the system proxy. Applications that ignore system proxy settings may need their own proxy configuration, or may require TUN mode to take over traffic at the network layer. To confirm a working connection, check three things in sequence: the client core is running, the system or application is sending traffic to the local proxy port, and the selected node can reach the destination. A tray icon or a single page loading cannot accurately identify which layer is failing.

What protocols, transports, and routing each control

Names such as VMess, VLESS, and Trojan belong to the connection protocol layer. TCP, WebSocket, and gRPC are transport methods, while routing rules decide whether a request goes direct, through the proxy, or is blocked. These layers can be combined, but they cannot replace one another. For example, a node using VLESS does not determine whether a website connects directly; that is decided by the routing configuration generated by the client. Conversely, precise routing rules cannot fix an incorrect server address or authentication parameter. When troubleshooting, split the configuration into connection parameters, transport parameters, and traffic destination, then verify each group separately rather than changing the entire configuration blindly.

Logs are verifiable facts, not optional details

Client logs usually record configuration loading, port listening, DNS queries, connection attempts, and failure reasons. For a timeout, first check network reachability, node status, and the route. For a resolution failure, check the domain and DNS. For an invalid configuration field, return to the node details and verify the protocol, transport, and security options. The order of events in the log also matters: if a configuration error appears first, later connection failures may only be consequences. Once these components are clear, move on to client selection and installation; every later switch will then have a defined purpose.

Choose a Client by Platform and Core Requirements

Choose v2rayN first for desktop platforms

For Windows, macOS, and Linux desktops, v2rayN is the preferred choice. It brings subscription management, node lists, system proxy settings, routing rules, and TUN mode into one consistent workflow, making it suitable for both first-time setup and custom split tunneling. Windows users can choose between the desktop edition and the classic WPF edition: the desktop edition uses a cross-platform interface and suits users who want a similar workflow across desktop systems, while the classic WPF edition feels more like a traditional Windows desktop program. Their goals are the same; there is no need to install both. Choose one as your regular working environment.

On Android, choose between two core approaches

v2rayNG is the primary Android choice and uses the Xray core, making it suitable when broad protocol and transport support is needed. v2flyNG uses the V2Fly core and is an alternative when the V2Fly ecosystem is specifically required. Both clients support subscription imports, node switching, routing settings, and local VPN takeover, but their fields and menu locations may differ. Do not migrate back and forth between the two apps whenever a connection fails. First confirm that the subscription’s protocols are supported by the current client, then use the logs to decide whether a different core path is necessary.

The architecture and package format must match

Choosing the right client is only the first step; also confirm the processor architecture and package format. On macOS, check the chip type in About This Mac: choose arm64 for Apple silicon and x64 for Intel processors. Most recent Android devices use arm64; if the architecture is unknown or unusual, choose the universal build, though it is often larger. Linux requires both an architecture choice and a package-family choice: Debian and Ubuntu use deb, while Fedora and RHEL-based systems generally use rpm. A mismatch commonly causes the installer not to launch or the system to report that the package is unsupported.

Do not substitute feature count for actual requirements

Before choosing a client, list the operations you actually need: system proxy support, applications that ignore system proxy settings, custom domain routing, or LAN sharing. Ordinary browsers and office apps generally need only subscriptions, node switching, and the system proxy. Consider TUN only when more application traffic must be covered, and move to custom routing only when you need precise control over traffic destinations. More features mean more configuration layers and more possible failure points. Start with the smallest working configuration, add capabilities one at a time, and keep a verifiable result for each change.

Preserve configuration sources before switching clients

Before changing devices or clients, record at least the subscription source, current routing mode, and custom rules. When nodes come from a subscription, there is no need to copy them one by one: import the subscription again in the new client, then restore the routing and proxy modes. Manual nodes require every protocol field to be preserved; recording only the server and port is not enough. Store configurations containing credentials in a controlled location rather than posting them publicly. The client comparison on this site further outlines the use cases for the three clients; choose one before moving on to installation.

Complete Installation and Create a Reversible Baseline

Disable takeover in older clients before installing

You can keep multiple clients on one device, but do not let them control the system proxy or TUN at the same time. Before installation, exit the old client and confirm in the system network settings that no manual proxy address remains. If an older program exited unexpectedly, the system proxy may still point to a local port that is no longer listening, making every webpage fail to connect. Disable the system’s manual proxy first, then start the new client. The goal is not to delete the old configuration, but to ensure that the first test has only one traffic entry point, making it easier to tell whether the problem comes from the new client or leftover settings.

Windows: choose the installation form and permissions

When using v2rayN on Windows, start in the Windows section of the download center and choose either the desktop edition or the classic WPF edition. After installation, launch it from the Start menu. On first run, confirm that the main window opens, the program can read the core directory, and the logs show that a local port is listening. Ordinary system proxy features generally do not require running as administrator continuously; the client may request elevated permissions only for features involving system network drivers or route changes. Do not treat “always run as administrator” as a universal fix, since it can hide directory-permission or configuration-path problems.

macOS: choose the chip build and confirm system authorization

When installing v2rayN on macOS, identify the processor type first and select the matching dmg. After opening the disk image, move the app into the system Applications directory instead of running it long-term from the read-only image. If the first launch requires source confirmation, follow the prompts in the system security settings. System proxy and TUN require different permissions: the system proxy mainly changes the proxy configuration for the current network service, while TUN may require additional network access. During initial setup, configure only the system proxy and leave TUN off so that the subscription and node connection can be verified first.

Linux: match the distribution and check the desktop session

Linux users should choose deb or rpm according to the distribution and confirm the processor architecture as well. After installation, launch the client from the desktop application list. If no interface appears, run the application command directly in a terminal to inspect startup errors. Desktop environments do not all read system proxy settings in the same way: some applications follow the desktop proxy, while others use their own network configuration. Therefore, “the client is running” does not mean that every application is covered. For initial verification, use a browser known to follow the system proxy, then configure applications that require their own proxy settings.

sudo apt install ./v2rayN-linux-x64.deb

# Use the matching package for rpm-based distributions
sudo rpm -Uvh v2rayN-linux-x64.rpm

Android: keep only one active local VPN

After installing v2rayNG or v2flyNG on Android, the first connection requests permission to establish a local VPN. This is the system-required step that hands application traffic to the client. Only one app can maintain this takeover state at a time, so disconnect other network tools before testing a new client. After importing a subscription, choose one node, keep the default routing settings, and tap Connect. A connection indicator in the status bar only confirms that system authorization was established; use the logs and real-world access to verify that the node connected successfully.

Five checks after first launch

First, confirm that the client window and tray menu open normally. Second, confirm that the core starts without configuration errors. Third, record the local HTTP, SOCKS, or mixed proxy port to avoid conflicts with other programs. Fourth, check whether launch-at-startup matches your workflow; leave it off for now if you do not need it. Fifth, confirm whether exiting the client automatically restores the system proxy. Complete these five checks before importing a subscription. If an error has already appeared during installation, do not continue configuring the subscription on top of it; later logs will mix multiple layers of problems and make troubleshooting much harder.

Import Subscriptions, Update Nodes, and Interpret Parsing Results

Name subscriptions after their identifiable source

When adding a subscription in the client’s subscription manager, use a name that describes its purpose or source, such as “Daily routes” or “Test routes,” rather than generic labels like “Subscription 1” or “New group.” The name does not affect connectivity, but it directly affects update and troubleshooting efficiency. Copy the link in full, without leading or trailing spaces, and do not mistake visible webpage text for the subscription URL. Save it, run one manual update, and review the notification and logs. The import is complete only when the node list actually grows or refreshes; saving a subscription record alone does not mean parsing succeeded.

Classify update failures by the stage that returned an error

A subscription update generally has four stages: fetching, decoding, parsing, and writing. Fetch failures usually appear as timeouts, network errors, or abnormal server responses; first confirm that the current network can reach the subscription URL. A decoding failure means the response is not in the format expected by the client, possibly because the link was copied incompletely, the subscription expired, or the server returned an informational page. Parsing failures are often related to node field formats, encoding, or the client’s supported scope. Write failures require checking configuration-directory permissions, disk space, and the state of the old configuration. Distinguishing the stage is more effective than repeatedly clicking Update.

Compare the node list before and after an update

Updating a subscription may add, remove, or modify nodes. If the node in use is removed, the client may switch to another node or retain an old record that is no longer linked to the subscription. After updating, confirm that the selected node still exists and that custom groups remain as expected. If the client offers options such as “clear old nodes” or “overwrite from subscription,” check whether manually added nodes will be affected before enabling them. Keep manual and subscription nodes in separate groups so their sources remain clear during updates.

Latency tests answer only a specific question

A node latency test usually checks whether a target address responds within a given time. It is not a real download-speed test and does not represent access quality for every website. Some nodes may not respond to a particular probe while still working as proxies; others may show low latency but deliver poor throughput because of congestion. First use the client test to eliminate clearly unreachable nodes, then compare access to a fixed webpage or file under consistent local network conditions. If results vary widely, repeat the test at different times instead of immediately changing protocol parameters.

Set subscription updates according to actual change needs

There is no need to update a subscription repeatedly every time the client opens. When the node source is known and the list is stable, update manually when nodes stop working, a configuration change is announced, or a maintenance cycle begins. Do not set automatic updates too frequently; repeated requests do not improve node quality and only fill the logs with duplicate entries. If everything stops working after an update, preserve the logs and check whether all nodes were replaced, then follow the subscription parsing failure checklist to inspect the link, response content, and update channel.

Verify every field on manual nodes

When adding a manual node, do not check only the server and port. The protocol, user ID, encryption or flow control, security layer, transport, server name, path, and service name must match the provider’s configuration. Empty fields can be meaningful: when a field should remain blank, do not fill it with a presumed default. Before editing a node, make a copy for rollback, and change only one field group at a time. After the connection works, name the node based on its purpose rather than including sensitive parameters. The subscription and node layer is now complete; next decide which application traffic should enter the local proxy.

Understand System Proxy, Global Mode, and Application Differences

The system proxy is the main entry point for most desktop applications

After v2rayN starts the core, it listens on local proxy ports. Enabling the system proxy points the operating system’s proxy address to those ports. Browsers, office software, and some system components read this setting and hand their requests to the client. When the system proxy is off, the core can continue running, but applications that follow system settings no longer enter the proxy automatically. When troubleshooting “the client connects normally but the browser is unchanged,” check both the client’s tray status and the system network settings, confirming that the proxy points to the local machine and that its port matches the client’s current configuration.

Global mode is a traffic-selection policy, not connection strength

Global mode generally sends traffic entering the client through the current proxy exit. Modes that bypass LAN and mainland China traffic use domain and IP data to decide whether to connect directly or use the proxy, while custom mode matches user-defined rules. Global mode does not make a node faster or fix invalid subscription fields; it simply reduces routing decisions and is useful for comparison testing. If a destination fails in rule mode but works in global mode, the node is probably usable and the issue is more likely routing or DNS. If both modes fail, return to the node and network layers.

Applications read proxy settings differently

Browsers usually follow the system proxy, but some applications have their own proxy options, some command-line tools read only environment variables, and others open network connections directly while ignoring system proxy settings. The result from one application therefore cannot represent the entire device. Start testing with a browser known to follow the system proxy, then handle other applications individually. When needed, set proxy environment variables temporarily for command-line programs, replacing the port with the actual value shown by the client rather than copying the example.

# Use an HTTP proxy for the current terminal session
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# Use SOCKS5 and resolve domains through the proxy
curl --proxy socks5h://127.0.0.1:10808 https://example.com/

Confirm local port conflicts from the listening state

If the core reports at startup that the address is already in use, another process is listening on the same port. Exit other proxy clients and start again. If the conflict remains, change the local port in the client settings and update every application where that port was entered manually. Do not change only the system proxy port without changing the core’s listening port; the two must match. The port number itself does not determine speed, so changing it repeatedly at random is pointless. LAN sharing also involves the listening address and firewall and should be configured separately from the local system proxy.

Restore system state when closing the client

Before exiting the client normally, disable the system proxy or confirm that the client is configured to restore it on exit. If the program is forcibly terminated, the proxy setting may remain active, causing every application that follows system proxy settings to connect to a stopped local port. A typical symptom is that the network itself works but the browser immediately reports a proxy connection failure. Open the system network settings, disable the manual proxy, then restart the client and check again. Adding this step to your daily troubleshooting checklist quickly rules out many “no internet after exit” problems.

Use application logs to interpret mobile connection status

Android clients take over traffic through the local VPN interface provided by the system. After tapping Connect, first confirm that system authorization succeeded, then check the client log for a completed node connection. Some applications have their own DNS, network acceleration, or private connection settings, which can change test results. During initial setup, keep routing and DNS at their defaults and verify with one node. Once the basic connection is stable, add per-app policies or custom routing only as needed, rather than changing the node, DNS, and application rules all at once.

Control Traffic Destinations with Domains, IPs, and Rule Order

Routing handles traffic that has already entered the client

Routing does not take over applications on its own; it only handles requests that enter the core through the system proxy, an application proxy, or TUN. Each rule generally contains a matching condition and an outbound action: conditions may include a domain, IP, port, protocol, or source, while actions are usually proxy, direct, or block. If an application never passes through the client, even a precise routing rule will not apply. Before configuring split tunneling, confirm in the logs that the target request appears, then check which rule and exit it matches.

Domain rules are suited to describing service boundaries

An exact domain match applies only to the specified hostname, while suffix rules can cover a domain and its subdomains. When using domain:example.com, confirm how the current client or core defines that syntax. full:api.example.com targets one specific host, while geosite: rules reference maintained domain sets and are suitable for covering a service category. The broader the rule, the greater the risk of unintended matches. Do not change an entire top-level domain and all its subdomains to the same exit just to fix one subdomain.

IP rules depend on resolution results and destination addresses

IP rules can match a single address or a CIDR range; for example, 192.168.0.0/16 represents a private network range. LAN addresses should usually go direct so printers, router admin pages, and file shares are not sent through a remote exit. Whether a domain request reaches IP rules also depends on whether the core obtains the resolved destination IP and how the current domain strategy is configured. If you write only IP rules without checking the DNS flow, a rule may look correct but never match.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:intranet.example.com",
          "domain:office.example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      }
    ]
  }
}

Rule order determines which rule wins a conflict

Most routing implementations evaluate rules in order and stop after the first match. Specific rules should therefore come before broad rules. For example, if an office subdomain must go direct while its parent domain uses the proxy, put the direct subdomain rule first and the parent-domain proxy rule second. If the order is reversed, the broad rule captures the request first. After editing rules, do not check only that the configuration saved successfully; restart or reload the core and confirm in the logs that the new rules loaded. For syntax and matching precedence, see how to write domain, ip, and geosite rules.

Keep DNS and routing aligned with the same destination logic

Split tunneling often depends on both domain and IP decisions, so DNS results affect subsequent routing. If a domain resolves to an unexpected address range, IP rules may send it through the wrong exit. During troubleshooting, record the domain, resolution result, matched rule, and final exit instead of simply replacing the DNS server. If the client supports multiple DNS groups, separate direct and proxied queries when appropriate, but first understand which exit sends each query. Until the baseline is stable, the default DNS configuration is usually easier to verify than several layered rule sets.

Validate routing with a minimal test set

Prepare three fixed test targets: one LAN address, one domain that must go direct, and one domain that must use the proxy. After each routing change, test them in order and record the exit used. If the LAN target fails, check private-address rules first. If a domain uses the wrong exit, check rule order and domain syntax. If no request appears in the logs, return to the traffic-entry layer. Do not use random webpages as your only test, because a page may load resources from many domains; a successful main page does not mean every resource used the same exit. After validating rule mode, decide whether TUN is needed to broaden traffic takeover.

Enable TUN only after basic proxying is stable

TUN handles applications that ignore the system proxy

TUN mode receives more system traffic through a virtual network interface and passes it to the core for routing and forwarding. It is useful for desktop programs that ignore system proxy settings, command-line tools that need unified takeover, and setups where configuring each application separately is undesirable. TUN is not a node-acceleration switch and does not improve protocol performance. Enabling it while the basic node connection is unstable adds three variables—virtual adapter, DNS, and routing table—so first verify that subscriptions, nodes, and rule mode work normally through the standard system proxy.

Record the current network baseline before enabling it

Before starting, record the current network adapters, DNS acquisition method, client local port, and system proxy status, and close other programs that may create virtual adapters. Then enable TUN in v2rayN, complete any required permission prompts, and wait for the core to reload. After startup, check the logs for virtual-interface creation, route installation, and DNS initialization. If the client switch is on but the logs report that interface creation failed, address the permission or driver issue first instead of changing node parameters.

Understand the boundaries of strict and automatic routing

Automatic routing sends suitable system traffic into TUN, while strict routing further restricts paths that bypass the virtual interface. The exact switch names may change with the client interface, but the principle is consistent: enable only the minimum necessary options, test a browser, command-line tools, and the target application, then add restrictions only if traffic leaks. On enterprise networks or systems with virtual machines, containers, or multiple network adapters, automatically generated routes may overlap existing ranges. Check the routing table first rather than switching directly to global proxy mode.

DNS problems are the first TUN troubleshooting priority

If IP addresses remain reachable after enabling TUN but domains do not, check DNS first. Confirm that the client DNS module is running, that queries enter the expected path, and that local security software is not blocking them. If only some domains fail, record their resolution results and matched rules. If every domain fails, check the DNS listening port, the system DNS target, and port conflicts. Do not enable multiple DNS takeover mechanisms at once, or queries may loop among the system, the client, and other network software.

Preserve direct LAN paths in multi-adapter environments

After enabling TUN, printers, network storage, router admin pages, and other private addresses should still use the local network adapter directly. Confirm that routing includes private address ranges and check whether the current LAN uses an uncommon custom subnet. When a device has wired, wireless, and virtual adapters at the same time, also confirm which adapter actually carries the default route. If problems appear after switching networks, turn off TUN first, wait for the virtual interface and routes to be removed, then reconnect to the network and start the client again.

Decide whether it really needs to stay enabled

If the applications you use every day reliably follow the system proxy, there is no need to keep TUN enabled just to make the setup more complex. TUN has clear value when it must cover specific applications that ignore proxy settings. A stable setup should recover after reboot, rebuild routes after network changes, preserve LAN access, avoid persistent DNS errors, and restore system networking after the client closes. Add TUN to the startup workflow only after meeting these conditions; otherwise, keep the system proxy as the simpler daily option.

Build a Repeatable Workflow for Updates, Backups, Speed Tests, and Layered Troubleshooting

Separate scheduled maintenance from event-driven maintenance

Scheduled maintenance checks client updates, subscription status, custom rules, and old configuration. Event-driven maintenance is performed when all nodes fail, the network environment changes, or the operating system is upgraded. There is no need to clear the configuration or reinstall the client every day. Under normal conditions, update the subscription, review node changes, and run a small set of repeatable connection tests. Before upgrading the client, record the current settings. Afterward, verify core startup, the system proxy, and one familiar node before restoring TUN or complex routing.

Back up what cannot be regenerated

Subscription nodes can usually be fetched again. The items worth backing up are manual nodes, custom routing, DNS settings, group organization, and LAN-sharing parameters. Store backup files in a controlled directory because they may contain connection credentials. When restoring, do not overwrite every new setting immediately; first confirm that the client configuration structure is compatible, then import each category. If you are changing devices, reinstall the client and import the subscription first, then restore rules manually. This avoids carrying over old system paths, port conflicts, and network-interface details.

Check speed issues at the node, route, and local layers

At the first layer, switch among a small number of nodes from the same subscription to determine whether the issue is limited to one node. At the second, test the same node at different times to see whether congestion is time-dependent. At the third, check the local network, proxy mode, DNS, TUN, and security software. Keep the website, file, and device consistent during testing; do not change nodes while also switching Wi-Fi networks. If every node is slow, inspect the local network and overall subscription status first. If only one node is slow, reinstalling the client is unnecessary. See layered troubleshooting for slow V2Ray speeds for the detailed process.

Collect logs that cover the moment the problem occurs

Troubleshooting logs should include at least three stages: starting the core, reproducing the problem, and stopping the test. Capturing only the final error often misses an earlier configuration-loading failure. Before reproducing the issue, clear excessive old logs or note the current time, then perform one action only, such as updating a subscription, connecting to one node, or visiting one fixed domain. Before sharing logs, remove sensitive data such as server addresses, user IDs, and subscription content, while keeping the error type, event order, and component names. This explains the problem without exposing connection parameters.

The first check for common symptoms

If the client will not open, check the package architecture, runtime environment, and configuration directory first. If a subscription update fails, check link retrieval and parsing logs. If every node times out, check the local network and subscription status. If the browser reports a proxy connection failure, check core listening and the system proxy port. If only one domain is affected, check DNS results and routing matches. If the entire network fails after enabling TUN, disable TUN first and inspect the virtual interface and default route. Find more symptom-based answers in Troubleshooting.

Maintain clear boundaries when sharing over a LAN

Once LAN connections are allowed, the local proxy port serves more than the current device. Confirm the listening address, system firewall, router isolation, and the proxy address configured on the other device, and use sharing only on a trusted LAN. If the computer’s IP changes, update the proxy address entered on phones or TVs as well. When sharing fails, first test from another device whether the computer’s LAN address is reachable, then check that the port is allowed, and finally confirm that the client permits external connections. See the v2rayN LAN-sharing steps for the complete procedure.

The maintenance goal is one known-good baseline

Before every major change, preserve one working combination of node, default routing, and system proxy. If the change cannot be diagnosed quickly, restore that baseline and redo the steps one at a time. Do not replace the subscription, DNS, routing, TUN, and local port all at once; even if connectivity returns, you will not know which change fixed it. A repeatable maintenance process is more reliable than frequent reinstalls and gives advanced configuration a clearly defined foundation.

Move from a Stable Baseline to Custom Rules and Multi-Device Management

Advanced work starts with explaining the current configuration

After basic use is working, do not immediately import a large rule set. First make sure you can answer five questions: which protocol and transport the current node uses, how application traffic enters the client, which path DNS queries take, which routing rule matches the request, and which exit is ultimately used. If any answer is unclear, adding more rules only increases uncertainty. The goal of advanced configuration is not more settings, but clear, verifiable conditions that send different traffic to the intended exits.

Establish naming and grouping conventions first

Subscription names, node notes, outbound labels, and rule names should use consistent meanings. For example, name node groups by “source—region—purpose,” use proxy, direct, and block for outbound purposes, and make custom rule names state both the target and the action. Consistent naming improves log readability and reduces migration effort. Do not include full credentials or subscription URLs in names. When sharing rules across devices, keep one general version without device paths or local ports, then add local differences on each device.

Give custom rules a test, release, and rollback process

Before adding a rule, state the expected behavior, such as “the office subdomain goes direct while other services under the same domain follow the default policy.” Add the smallest rule, verify its match in the logs, and only then expand the domain or network range. Before releasing rules into daily use, test a LAN target, a direct target, a proxied target, and DNS. Keep a copy of the old order when changing rule precedence. If something breaks, roll back the latest change instead of layering on more patches. During long-term maintenance, remove entries that are obsolete or already covered by broader rules.

{
  "rules": [
    {
      "name": "private-network-direct",
      "match": [
        "geoip:private"
      ],
      "action": "direct"
    },
    {
      "name": "office-domain-direct",
      "match": [
        "full:portal.example.com",
        "domain:corp.example.com"
      ],
      "action": "direct"
    }
  ]
}

The snippets above illustrate rule-design methods; they are not complete files that can be used to overwrite a client configuration. Actual fields must follow the current core’s routing structure and the client’s export format. Before importing, confirm that the labels match existing outbounds; otherwise, a rule may match but still have no available exit.

Separate shared configuration from device-specific differences

Windows, macOS, Linux, and Android can use the same subscription source, but system proxy settings, TUN permissions, package architectures, and LAN interfaces are device-specific and should not be copied blindly. Shared elements include subscription groups, core routing intent, and test targets. Device-specific elements include local ports, startup behavior, system permissions, and application takeover methods. During migration, restore the shared elements first, then configure each device individually. This preserves logical consistency without carrying one platform’s network-interface settings to another.

Advanced DNS configuration must be driven by observable results

Split DNS paths are necessary only when the default DNS clearly causes resolution failures, incorrect exits, or contamination for specific domains. Before designing one, record which DNS group resolves each target domain, which exit carries the query, and which routing rule uses the result. After adding caching, fallback queries, or domain-based DNS routing, verify first-lookups and cache hits separately. If intermittent failures appear, simplify to a single path first and restore features one at a time. DNS settings cannot replace domain routing or repair an unreachable node.

Organize the learning path into three cycles

The first cycle is connection: understand protocol fields and confirm that one node is stable. The second is takeover: learn the boundaries of system proxy, application proxy, and TUN. The third is routing: understand domains, IPs, DNS, and rule order. Run each cycle as establish a baseline → add one item → verify the result → record rollback steps. When a new problem appears, identify its cycle and return to the relevant chapter instead of reinstalling from scratch. For quick operations, return to the Getting Started guide. Check client packages and platform requirements in the download center, and look up specific symptoms in Troubleshooting.

The final configuration should be simple enough to reproduce

A mature configuration is not necessarily the one with the most rules; it is the one that can be rebuilt from records on another device. Document six things: the subscription source, why the client was chosen, the proxy entry point, routing targets, when TUN is used, and the maintenance cycle. Remove switches and rules whose purpose cannot be explained, and periodically confirm that the subscription still matches the custom configuration. This completes the loop from core concepts to advanced management: establish the connection, bring traffic in, control where it goes, and use logs, backups, and a baseline to keep the setup maintainable over time.