V2Ray User Guide

Core concepts: traffic capture, matching, and outbound routing

Clients, cores, and servers

V2Ray usually refers to the proxy technology and tools associated with Project V, not a single graphical application. A client stores server details, imports subscriptions, manages settings, and displays logs. The core establishes connections, identifies traffic, applies routing, and handles protocols. The server runs remotely, accepts protocol connections, and reaches the requested destination. Each has a distinct role: an open client window only confirms that the application is running—not that its core started successfully or that the remote connection works.

V2Fly and Xray are separate core projects in the same ecosystem. They share some configuration concepts, but their feature sets, protocol extensions, and parameter details are not identical. v2rayN can manage different cores, depending on the distribution you use; v2rayNG primarily uses Xray, while v2flyNG uses V2Fly. If a field is rejected, first check which core is running, then consult its configuration documentation. The client’s name alone doesn’t tell you what it supports.

How a connection flows

Breaking a request into four stages makes problems easier to isolate: an application sends traffic to a local entry point; the core selects an outbound based on its rules; the proxy outbound connects to a remote server; and the server reaches the destination. HTTP proxy, SOCKS proxy, and TUN are different ways to capture traffic. Labels such as direct and proxy identify outbound choices. Changing the remote protocol won’t fix a capture failure, and repeatedly changing the local listening port won’t fix incorrect routing.

Server details usually include an address, port, protocol, identity, transport, and security layer. The protocol defines how the client and server communicate; the transport describes how data is carried; and settings such as TLS or REALITY provide connection security. VLESS is not a transport, and WebSocket is not an encryption protocol. Check each layer after importing a profile. Matching server addresses don’t make two configurations equivalent: paths, service names, server names, and other fields can all affect whether a connection succeeds.

How DNS resolution relates to routing

DNS resolves domain names to addresses, but a domain name doesn’t necessarily disappear before traffic reaches the client. Some applications send the full domain through the proxy; others resolve it locally and send an address. The information the core receives determines which rules it can match. If a domain rule doesn’t match, check the capture method and the destination type in the logs before assuming the rule data is broken. Different applications can route differently to the same site because they resolve names at different points.

Routing and DNS lookups are separate operations. A domain-resolution strategy may trigger a lookup so the core can match address-based rules, but that doesn’t mean all DNS requests from applications use the selected route. With TUN, account for the system resolver, DNS interception by the client, and built-in browser resolution. Map the actual request path before changing settings; this is usually more effective than enabling several DNS options at once.

Establish a verifiable baseline

For an initial setup, use one server profile from a known source, one capture method, and a routing setup that’s easy to explain. Start by accessing a site in your browser through the system proxy, then check the connection log for the destination and expected outbound. Avoid enabling TUN, custom DNS, per-app proxying, and complex routing all at once—you won’t know which change caused a failure. A useful baseline isn’t just simple; each step can be compared with the previous state.

The configuration snippets in this guide explain individual fields; they don’t include complete server connection details. Make changes in the graphical settings where possible, then inspect the generated configuration. Direct edits to runtime files may be overwritten when the client restarts, switches servers, or updates a subscription. By the end of this chapter, you should be able to describe a request in terms of where traffic enters, which rule matches, and which outbound handles it. For terminology, see the glossary.

Client Choice: platform, core, and profile compatibility

Start with v2rayN on desktop

For desktop use on Windows, macOS, or Linux, start with v2rayN. Its graphical interface brings server profiles, subscription groups, routing, and runtime logs together in one place, making it easier to follow a repeatable workflow. Windows offers a desktop edition and a classic WPF edition: the desktop edition uses a cross-platform interface, while the WPF edition retains the traditional desktop experience. Choose based on your system and preferences; there’s no need to run both for the same connection.

Before choosing a macOS installer, check the chip listed in About This Mac: Apple Silicon uses arm64, while Intel uses x64. On Linux, check the package format as well as the architecture: choose deb for systems that use deb packages and rpm for systems that use rpm packages. Architecture determines whether the program can run on your processor; package format determines how your package manager handles its files. Both must match, so don’t rely on the filename extension alone.

Android: primary and alternative clients

For Android, start with v2rayNG, which primarily uses the Xray core. Consider v2flyNG when you need compatibility with V2Fly configurations. Both are graphical clients, but their protocol support isn’t necessarily identical. If a profile depends on a core-specific extension, first confirm that the client’s core supports it, then choose an import method. Successful import doesn’t prove compatibility: parsing a link and establishing a working connection are separate steps.

Choose an Android package architecture based on the device’s OS and processor support. Most recent devices work well with arm64, but a supported processor doesn’t guarantee a compatible system environment. If you’re unsure, consider a universal package, which is usually larger. If the installer reports incompatibility, recheck the device details and package choice rather than repeatedly installing the same file. Find the available options in the Android download section; there’s no need to assemble installation files from multiple sources.

Check against your requirements, not the name

Before choosing, clarify three requirements: the server’s protocol and transport, which apps need coverage, and whether TUN is required. Desktop use focused on a browser can usually start with the system proxy. Apps that ignore system proxy settings need per-app configuration or TUN. On Android, understand VPN capture and per-app inclusion or exclusion lists. More features don’t automatically mean a better fit; choose a combination that meets your needs and is easy to maintain.

Check subscription compatibility separately. A subscription URL might return a collection of protocol links, an encoded list, or a proprietary configuration file. Support for a protocol doesn’t mean a client supports every subscription format. If you already have a profile, check the provider’s recommended client and import instructions before downloading anything. If the format doesn’t match, get the correct original link instead of submitting a private subscription URL to an unknown online converter.

Keep a rollback path when migrating

When moving from another device, create a separate subscription group in the new client and test just one server first. Don’t immediately copy all your routing, DNS, and capture settings. System proxy behavior, permissions, and network interfaces vary across platforms, so settings that worked on the old device may not transfer as-is. Once the basic connection works, migrate rules one at a time and note how each change affects your apps.

Running multiple clients at once can cause conflicts over proxy ports, system proxy settings, or VPN capture. Before trying an alternative, stop traffic capture in the old client, then start the new one. Keep the old configuration for rollback, but don’t let both clients manage system traffic simultaneously. For a detailed comparison of the three clients, see Client cores and platform comparison. Once you’ve chosen a client, move on to installation and first launch.

Installation and setup: permissions, directories, and listeners

Choose where files and data will live

Choose a platform- and architecture-specific option on the client downloads page. Before installing, quit any existing instance and make sure you’ve selected the client you intend to use, not a package for another platform. Follow the installer wizard when one is provided. If the release comes as an archive, extract it fully to a separate folder before launching. Running the program from an archive preview can hide required files and cause problems with updates and saved data.

The application directory and configuration data directory may be separate. Some releases store data in your user folder; others let you choose a dedicated data directory. After first launch, check the settings or backup options to see where subscriptions and routing settings are saved. If you plan to migrate, back up the data supported by the client rather than just copying a desktop shortcut. Avoid placing the application in a shared, writable folder or a temporary location that’s routinely cleared.

Complete the first desktop launch

After installing on Windows, start the client as a standard user and check that the interface and logs appear normally. If the WPF edition reports a missing runtime component, install the environment required by that release or choose an installer suited to your system. Don’t respond to a launch failure by running the client as administrator indefinitely. Regular proxy use and operations that create a virtual network adapter require different permissions; grant access for the latter when prompted.

On macOS, move the app to its intended location before opening it rather than repeatedly running it from a temporary mount. If macOS displays a security warning, first confirm the file’s source, package type, and compatibility with your system, then follow the system’s app security process. On Linux, install with the appropriate package manager, launch from the application menu, and check the logs. Address specific desktop component or permission errors directly; don’t broadly change system directory permissions to work around them.

Android permissions after installation

On Android, grant only the permissions needed for the installation source you’re actually using, and revoke them later if appropriate. On first launch, import one profile and start the connection. The system’s VPN connection prompt allows the client to capture traffic locally; granting permission doesn’t confirm that the remote server works. Check the profile and test access separately. If another VPN app is active, disconnect it first to avoid conflicts over the VPN interface.

To separate installation problems from background restrictions, keep the app in the foreground with the screen on for your first connection test. Test screen-off and background behavior afterward. If the connection drops only when the screen locks, check battery optimization, background limits, and the device manufacturer’s task management settings instead of reinstalling. See Android permissions, battery settings, and per-app configuration for more.

Check the core and local listener

After opening a desktop client, check the logs or status area to confirm that the core actually started. A missing executable, configuration parse error, and occupied port are different problems: check the installation files for the first, undo recent changes for the second, and look for an old instance or another process using the same port for the third. Don’t test browser proxy settings before the local listener is running; the browser will simply report that the local connection was refused.

Once you’ve confirmed the listening address, port, and proxy protocol, decide how apps should connect. System proxy settings must point to the client’s actual listener. When configuring an app manually, use the correct HTTP or SOCKS endpoint. There’s no single required port number; use the one shown in the current settings. After changing it, update app settings too. Don’t leave an app pointing to the old port or mistake the remote server’s port for the local proxy port.

During initial setup, leave startup automation and automatic traffic capture disabled. First complete a full cycle: start the core, connect an app, stop capturing traffic, and quit the client. Confirm the system network works normally after quitting, then enable automation. This makes it clear which system settings the client changes. If access still fails after quitting, check whether the system proxy setting was left behind before resetting the entire network. For common troubleshooting paths, see the FAQ.

Importing subscriptions: groups, updates, and profile checks

Identify the profile type and access scope

A subscription URL is an update endpoint, not a single server connection. It may return several server profiles and add or remove entries on later updates. A protocol share link describes one connection; a QR code is simply a way to carry a link. Before importing, identify whether you have a subscription URL, a single share link, or a complete configuration file, then choose the matching import option. Pasting a subscription URL into a single-server address field usually creates a profile that can’t connect.

A subscription URL may contain a token that grants access to private profiles, so protect it like a connection credential. If you need help troubleshooting, don’t share the full URL or post its QR code publicly. The response format, error type, and client name are usually enough for an initial diagnosis. If the URL was exposed, replace it using the provider’s account management options; deleting chat messages or browser history isn’t enough.

Create an update link in a group

In v2rayN, open subscription group management, add a group, enter a recognizable label and the subscription URL, then save and update it. Use one group per source so it’s easy to see what each update affects. The label is for local reference and doesn’t change connection behavior. After the first update, check whether server entries appeared, whether they belong to the correct group, and whether the logs report a parsing error. Don’t rely on a success message alone.

In v2rayNG or v2flyNG, open the subscription management option, add the URL, and update it; menu labels vary by version. For a single share link, use the appropriate clipboard import or QR code scanner. Check that the clipboard contains only the link, with no surrounding text. After scanning, verify the protocol, address, and label. When importing several QR codes, check for duplicates so you don’t accidentally select an older entry.

Separate network and format issues when updates fail

If an update fails, first check that the URL is complete, including its scheme, path, and query parameters; some copy methods omit the final characters. Then identify whether the error is a connection timeout, access denied, certificate error, or parsing failure. For timeouts and access errors, check the network path and endpoint permissions. For certificate errors, check the system clock and certificate environment. For parsing failures, confirm that the response is a subscription format the client supports—not a login page or error message.

Some clients can fetch subscriptions through a proxy. If a direct request fails, you can try this option when you already have a working connection. Without one, “update through proxy” can’t fix the problem by itself. First establish a working connection or ask the profile provider about an accessible update method. Don’t change the update path, DNS, and core all at once; you won’t be able to tell which change affected the result.

Check the imported profile, not just its label

Select a server profile and check its protocol, address, port, identity fields, transport, and security layer. For WebSocket, check the path and Host. For gRPC, check the service name. For TLS, check the server name and certificate validation requirements. Fields aren’t interchangeable across protocols. An empty field may be valid or may indicate incomplete profile details; check the server’s requirements.

Before updating, note the selected server and group; afterward, check the selection again. Some clients preserve the matching profile, while others may replace or remove it. A similar label in the interface doesn’t prove the underlying settings are unchanged. If a problem appears only after an update, compare the specific fields and core errors instead of deleting all your data. Keeping a verified standalone test profile helps distinguish subscription changes from local environment changes.

Subscription management is complete when the source is clear, groups are easy to identify, update behavior is understood, and at least one profile connects successfully. A server list test only reflects conditions at that moment; it doesn’t replace testing the apps you actually use. Next, connect a target app through a known capture method before optimizing routing. For a first-time setup, return to the quick-start guide. For questions about protocol fields, see the protocol and transport glossary.

Proxy modes: capture scope and traffic direction

System proxy controls how apps connect

The system proxy is a setting provided by the operating system for apps to use. When enabled, a desktop client typically sets HTTP and other proxy endpoints in the system configuration. Apps that follow those settings send connections to the client; browsers often do, but some games, command-line tools, and apps with their own networking components may not. If the system proxy is enabled but only some apps use it, that’s a capture-scope issue—not necessarily a problem with the remote server.

In v2rayN, start a working server first, then enable the system proxy and make a new browser request. Disable or check any browser proxy extensions that might override the system settings. Existing long-lived connections may keep using their original route, so reload the page or restart the app after changing proxy settings. A highlighted toggle alone doesn’t prove that new connections are reaching the client.

Global and bypass modes control routing after capture

Global proxy mode generally sends traffic captured by the client to a proxy outbound, except where necessary exception rules apply. It doesn’t automatically capture traffic from every app on the system. Bypass modes, such as bypassing mainland China, use domain and IP rules to send some destinations direct and others through the proxy. These modes control routing, which is separate from the system proxy. You can enable the system proxy with bypass rules, or use TUN to capture traffic and apply the same routing logic.

When troubleshooting with global mode, the goal is to reduce routing variables temporarily, not to ignore local network requirements permanently. LAN devices, loopback addresses, and connections to the remote server still need appropriate handling. Client presets may handle these exceptions differently, so “global” doesn’t mean every rule is removed. To see where a destination actually goes, check the active preset and runtime logs rather than inferring from the mode name.

Verify the path with one app

Choose an app that’s easy to test repeatedly and check whether it uses system settings or its own proxy configuration. If you set a proxy manually, use the local listening address and the correct protocol port—not the remote server address. Whether a SOCKS endpoint sends domain names to the proxy for resolution depends on the app’s options. Local and remote DNS resolution may lead to different routing matches. Record the original settings first and restore them after testing so you don’t leave a hidden override in place.

Check the app result and client logs together. If the connection fails and no destination appears in the logs, investigate capture. If there’s a log entry but the wrong outbound was selected, check routing. If the expected proxy outbound was selected but the connection fails, check the protocol and remote server. Raise the log level temporarily if you need more detail, then reproduce the issue once. A page loading or failing doesn’t identify the faulty layer on its own, and a cached page isn’t proof of a new network request.

Android per-app settings and desktop exceptions

Android VPN capture can use a per-app allowlist or blocklist. Depending on the setting, the list may mean “proxy only selected apps” or “bypass selected apps”—the effects are opposite, so read the option’s description first. After changing the list, reconnect and start a new connection in the app you’re testing. Apps excluded from capture won’t be brought into the client by changing global routing; their traffic never entered the client in the first place.

Desktop systems also have system proxy exception lists, browser-specific settings, and app-level network options. If a local admin page won’t load, check whether it’s being sent through an unsuitable proxy path. If an app always connects directly, check whether it ignores system settings. Don’t use repeated switches between global and bypass modes as a substitute for analyzing capture. For a full comparison, see System proxy and routing modes. Once capture is confirmed, move on to routing rules.

Routing: rule order, conditions, and outbound tags

Confirm which component applies the rules

The running core applies routing rules; the graphical interface generates or manages the configuration. Before making changes, confirm which core is running, which routing preset is active, and what kind of server configuration you’re using. Some custom configurations define their own routing and may not use the client’s standard rules page. If a change has no effect, first check whether your edits made it into the active configuration rather than repeatedly changing an unused preset.

Rules are generally evaluated in order, and the first match determines the outbound. Put specific business domains before broad categories, and LAN exceptions before general proxy rules, to reduce conflicts. Also check how conditions within a rule combine: in a common field-based rule, different condition types usually all constrain the match, while lists of the same type provide candidate values. Don’t mistake a rule containing both a domain and a port for two separate rules.

Understanding domainStrategy and tags

domainStrategy controls domain resolution for routing matches. AsIs doesn’t resolve domains proactively for address matching. IPIfNonMatch tries to resolve a domain after it fails to match, so address-based rules can still apply. IPOnDemand may resolve it as soon as an address-based rule is encountered. This isn’t a proxy protocol switch and doesn’t directly define how all client DNS requests are forwarded. Choose a strategy based on your rules and the cost of lookups.

outboundTag references an outbound tag that must exist. direct, proxy, and block are common names, but they only work when the corresponding outbound is defined. The snippet below shows routing only; it assumes the active configuration defines direct and proxy and has the required rule data files. Don’t save the snippet as a complete configuration or overwrite client-generated settings without checking the tags.

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

Rule data and exact domains

geosite references a domain list; geoip references an IP address list. Available lists and their contents depend on the installed data files. They aren’t definitive results from a live lookup, and classifications may change when the data is updated. A site may use several related domains, so matching only its main page may not cover sign-in, assets, and API requests. Check each destination in the logs instead of expanding the rule to an unrelated category.

When writing an exact exception, distinguish a full domain match from a suffix match. For example, full:example.com matches only that exact name, while domain:example.com usually includes subdomains. These example domains illustrate the syntax; use the actual domain for your service in real rules. Avoid vague keyword matches where a precise boundary is possible: other services containing the same string could be included, making the problem hard to spot.

Use logs to explain a rule match

Change one setting at a time when testing a rule. Save it, reload as required by the client, and start a new connection. Record whether the destination appears as a domain or an IP address, which condition matched, and which outbound was selected. If only an IP address appears, the core may not have enough information to match a domain rule. If an earlier broad rule matched, later specific rules never ran. Note a rule’s original position before moving it temporarily, then restore it after testing.

If some resources fail after routing changes, temporarily send that service through one known-working outbound, then narrow down its related domains. This helps distinguish incomplete rules from an unavailable remote service. Don’t start by adding large downloaded rule sets; each extra list makes the routing path harder to explain. A maintainable routing setup makes the purpose, order, and rollback method of every rule clear. Disable unclear entries temporarily and observe the result rather than keeping unexplained dependencies.

TUN mode: virtual interfaces, DNS, and routing loops

Prove that standard proxy capture works first

TUN captures system traffic through a virtual network interface. It’s useful for apps that can’t be configured directly or don’t follow system proxy settings. TUN changes how traffic enters the client; routing rules and a working outbound are still required. Before enabling it, confirm that a standard proxy can use the same server to reach the target. Otherwise, a failure after enabling TUN could come from the remote connection or the local interface. TUN can’t fix incorrect server details, and apps won’t necessarily behave identically.

A graphical client’s TUN support may rely on a particular core, helper components, and permission mechanisms. Its settings may not match ordinary Xray routing configuration. Don’t paste a full configuration from another implementation into your client. Read the current TUN settings first and understand options for auto-routing, DNS capture, excluded subnets, and the network stack. Keep sensible defaults unless you have a specific need; avoid changing everything at once.

Permissions and system routes

First-time setup may require administrator permission or installation of virtual network components. After granting access, check the core logs, confirm that the interface was created, and verify that system routes changed as expected. Seeing a virtual interface name doesn’t prove traffic is reaching the core; an enabled toggle doesn’t guarantee setup succeeded. If activation fails, keep the error details, check permissions and component status, and only then decide whether to retry. Don’t repeatedly create interfaces with unclear purposes.

Auto-routing affects how the system selects a network path, so pay special attention to traffic between the client and its remote server. If that traffic is captured and sent back through the same proxy, it can create a loop, causing repeated reconnects or loss of network access. Clients usually provide a built-in way to prevent this; use it where possible. Before adding network or process exclusions manually, identify the actual outbound interface and remote address. Avoid bypassing a wider range than necessary.

Verify DNS capture separately

A common TUN problem is that direct access by IP works but access by domain name fails. Check where DNS requests go, whether the client can reach its upstream resolver, and whether the returned addresses can be used for routing. Apps may use the system DNS resolver or create their own encrypted DNS connections. Configuring an upstream in the client doesn’t automatically capture every app’s DNS requests. Trace the actual request path rather than assuming setup is complete because an address appears in the settings.

Some implementations offer FakeDNS, which maps domain names to reserved addresses and restores the domain association later in the connection. This requires DNS and traffic capture to work together, so it isn’t a default solution for every situation. Cached results, traffic that bypasses capture, or apps using their own resolver can leave mappings out of sync. Without a specific need, start with a simpler DNS setup and test FakeDNS separately after the basic path is stable.

LAN access, dual-stack networking, and app behavior

Test websites, LAN services, sleep and wake, and network changes. If a printer, file share, or router admin page becomes unreachable, check whether local traffic is being sent through the proxy by mistake. Corporate networks may use unusual private subnets or dedicated DNS servers, so don’t rely only on home network assumptions. If internal name resolution must be preserved, consider both the DNS path and the traffic path; allowing an IP address alone may not fix a domain lookup.

Check IPv4 and IPv6 separately. If only one address family is captured, an app may prefer the other, producing a route you didn’t expect. If DNS returns an address from an unreachable family, the connection may stall before succeeding. During troubleshooting, check the actual destination address and system connection results instead of disabling an entire address family as a first step. On Android, also check settings such as always-on VPN and blocking connections that don’t use the VPN; these affect behavior after the client stops.

If only one app fails with TUN enabled, check how that app connects: does it use UDP, bind to a network interface, have its own proxy settings, or require LAN discovery? Testing each factor is more useful than blindly lowering the MTU. Router and gateway setups add routing and return-path considerations; see the router deployment guide. Don’t copy desktop TUN settings directly to a gateway.

Maintenance: updates, backups, and layered troubleshooting

Manage updates by component

The client app, proxy core, routing data, and subscription content are separate update targets. A client update may change the interface or how it generates configuration. A core update may change features and parameter support. Rule data updates may change classifications, and subscription updates change server profiles. If a problem appears after an update, first identify which layer changed. Updating everything at once saves clicks but makes regressions harder to isolate.

Before updating, use the client’s backup feature to save the data you need. Note the current capture method, routing preset, DNS settings, and verified server. Backups may contain sensitive connection details; store them somewhere access-controlled, not in a public sync folder. After updating, test the original minimal setup first, then try TUN and special rules. Don’t delete the old backup or keep changing settings just because the app opens successfully.

Troubleshoot by capture, core, and remote layers

If nothing can connect, pause traffic capture and check whether the underlying network works. If it doesn’t, check Wi-Fi, the gateway, and system network status. If it does but the proxy still fails, check the local listener and core logs. When a browser reports that the local connection was refused, start with the listening address, port, and process status—not the remote protocol. For configuration parse errors in the logs, undoing the most recent change is usually the fastest next step.

If a destination appears in the logs but the remote connection fails, distinguish name resolution failure, timeout, connection refused, and security handshake failure. For DNS errors, check the resolution path. For timeouts, check the address, port, and reachability. A refusal usually means the destination port isn’t accepting connections. For handshake failures, check the system clock, server name, transport, and identity parameters. Don’t hide the problem by disabling certificate verification; find out why validation failed.

Keep test conditions consistent when checking speed

Slow speeds don’t necessarily indicate a protocol problem. Use the same device, network, destination, and testing method within the same time window before comparing servers. The download host, Wi-Fi signal, carrier route, and background activity can all affect results. A single connection test offers only a snapshot, not proof of sustained throughput. Test several types of real-world traffic instead of repeatedly running the same list test.

If web browsing works but large downloads fail, check destination limits, connection reuse, and link stability. If only one app is slow, check its proxy and DNS settings; if every app is slow, compare the underlying network with the proxy path. With TUN, check whether another VPN or security app is also capturing traffic. See the layered guide to troubleshooting slow speeds. Don’t keep changing the entire configuration without evidence.

Keep only the logs needed to troubleshoot

Use a reasonable log level for everyday operation and temporarily increase detail when reproducing a problem. Recording the time, steps, capture mode, and exact error is usually more useful than sharing a full-screen server list. Before sharing logs, check for addresses, identity fields, subscription URLs, and personal domain names. Restore the normal log level when you’re done to avoid generating large files or casually circulating long-term browsing records as ordinary backups.

Quitting and migration are part of maintenance

Before quitting the client, turn off the system proxy or TUN as appropriate and confirm that network access is restored. After an unexpected exit, if the browser can’t connect, check whether the system still points to a stopped local listener. With TUN, check whether routes and DNS have recovered. Don’t switch capture between apps without cleaning up the previous state. Back up before reinstalling, and rebuild the configuration only if you’ve confirmed the data is damaged; reinstalling isn’t a fix for every problem.

After moving to a new device, restore only the data you need. Don’t immediately restore every startup and background option. Test subscription updates, core startup, app capture, routing matches, and network recovery after quitting one at a time; enable automation last. Long-term maintenance is about keeping a known-good rollback path, not accumulating more settings. Browse the FAQ by topic for common questions, or provide minimal reproduction steps to investigate a complex issue.

Advanced topics: minimal experiments and maintainable configuration

Expand from one specific problem

Advanced configuration isn’t about enabling more features; it’s about solving an observed problem. Start with a concrete requirement, such as “always route this domain directly,” “capture this app,” or “recover automatically after a network change.” Then identify whether it belongs to capture, routing, DNS, or runtime management. A clear category narrows the scope of changes. If the requirement is simply “make everything faster,” first define a repeatable test and describe the symptoms before deciding what to change.

Keep a baseline for every experiment. Copy the routing preset or create a separate server test profile instead of overwriting your everyday configuration. Record the inputs, expected result, how you’ll observe it, and how to roll it back. For example, after adding an exact domain rule, use a new connection to verify its outbound and check that other domains still match as before. A successful experiment isn’t automatically suitable for everyday use; check that it behaves consistently after restarts, subscription updates, and network changes.

Evaluate protocols, security, and transport separately

When evaluating VLESS, VMess, or Trojan, focus on compatibility with your server and core rather than judging performance by protocol name. The protocol defines the communication, TLS and other security mechanisms protect the connection, and transport behavior depends on server deployment and network conditions. A combination that works on one route may not behave the same on another. Client parameters only matter when the server supports them.

Keep both ends consistent when changing transport settings. Paths, service names, server names, and identity parameters serve different purposes; don’t substitute one generic string for all of them. If a share link omits a field, ask the source rather than copying it from another node. Troubleshooting also depends on whether a failure occurs before or after the security handshake. Understanding the stage shown in the logs is more useful than collecting a “complete list of standard settings” without context.

Make DNS and routing work together

For advanced DNS configuration, answer three questions: who requests the lookup, who performs it, and which connection uses the result? A domain rule may select an outbound without a lookup; an address rule may require one first; and an app’s own resolver may bypass the client. Track these paths separately to understand which part an upstream resolver setting affects. Don’t force every query through one upstream just to keep the settings page tidy if it can’t resolve internal network names correctly.

When splitting DNS traffic, verify both the route to the resolver and whether the returned addresses are reachable afterward. A successful DNS request doesn’t prove its answer is usable on the current network; a reachable address doesn’t prove that the domain was classified as expected. Start with a few clearly defined targets and record the domain, returned address, and outbound for each. Avoid introducing large rule sets, multiple upstreams, and complex caching policies all at once; inconsistent cache states make results harder to reproduce.

Understand generated configuration and track its source

Once you’re comfortable with the graphical interface, inspect the generated configuration and trace how inbound tags, routing conditions, and outbound definitions refer to each other. The goal isn’t to memorize every field but to identify which values come from server profiles, global settings, and routing presets. Runtime files may be regenerated, so make persistent changes through the appropriate management screen. If you need a custom configuration, be clear about which responsibilities it takes over and which graphical options no longer apply.

Validate each stage instead of doing everything at once

First establish a stable connection, then build explainable routing, then handle special apps and TUN, and finally explore multiple cores and complex DNS. Each stage needs a clear exit condition: reproduce a successful and failed connection; explain the selected outbound; restore normal system networking after capture; and rebuild a minimal setup from backup. Don’t add another layer until the previous one passes its checks.

After switching cores, retest protocol support, routing data, and DNS behavior; a successful startup doesn’t prove the configuration is equivalent. Keep one core and preset for everyday use, and use another only for a specific feature test to limit uncertainty. To restart the setup workflow, return to the user guide. For installation options, visit client downloads. Find terminology and troubleshooting help in the glossary and FAQ. The final setup should be easy to explain, verify, and roll back.