Complete V2Ray Guide: From Beginner to Advanced

1. Core Internals: Understand the Boundaries Between Clients, Cores, and Configuration

A GUI Client Is Not the Proxy Core

The easiest mistake to make when learning V2Ray is treating the GUI client, proxy core, node configuration, and system proxy as one thing. They are separate layers. v2rayN, v2rayNG, and v2flyNG provide windows, subscription lists, node selection, logs, and toggles. The Xray or V2Fly core parses configuration, creates transport connections, matches routing rules, and exposes local proxy ports. A subscription or individual share link supplies the server address, port, user identifier, protocol, and transport parameters. The system proxy and TUN determine how application traffic enters the local core. Browser and application requests follow the intended path only when all four layers are configured correctly.

So, a client showing “running” only proves that the local process has started. It does not by itself prove that the subscription is valid, the node is reachable, or application traffic is using the proxy. Troubleshoot layer by layer along the data path: first verify that the client recognizes the configuration, then confirm that the core starts, that a local listening port exists, and finally that the system or application is actually using it. Separating these stages is faster than repeatedly clicking Connect.

How Inbounds, Outbounds, and Routing Work Together

Core configurations commonly contain three key parts. An inbound receives requests from local applications, such as a local SOCKS or HTTP proxy port. An outbound defines how a request is handled after leaving the device, typically through a remote proxy, a direct connection, or a block action. Routing sits between them and selects an outbound based on the domain, IP, protocol, or process. GUI clients package these concepts as options such as “system proxy,” “routing mode,” “bypass LAN,” and “block specific connections,” but the underlying flow remains receive, decide, and forward.

DNS resolution also has its own place in the chain. An application may resolve a domain through the system first and pass the IP to the proxy, or it may send the domain directly to the local proxy for the core to resolve according to its configuration. These paths affect whether domain rules can match and how traffic is routed. Beginners do not need to change complex DNS settings immediately; just remember that when a seemingly correct domain rule does not work, check whether the request enters the core as a domain or has already become an IP.

Keep Protocol Names and Transport Parameters Separate

Names such as VMess, VLESS, and Trojan generally describe the proxy protocol layer. TCP, WebSocket, and gRPC are transport methods, while TLS and REALITY concern connection security and handshake characteristics. A share link compresses parameters from multiple layers into one string; after import, the client expands it into configuration the core can read. Two nodes cannot be assumed interchangeable just because they use the same protocol: the transport, hostname, path, security options, and server-side settings must match. When editing a node manually, avoid filling in values based on guesswork. Confirm missing information with the configuration provider.

After this chapter, you should be able to describe a request as one clear chain: the application sends it, the system proxy or TUN captures the traffic, the local inbound receives it, routing selects an outbound, and the core establishes a connection using the node configuration. Every later setting can be understood within this chain.

2. Choose a Client: Decide by Platform, Core, and Maintenance Needs

Choose v2rayN First for Desktop Platforms

For desktop use on Windows, macOS, and Linux, v2rayN is the recommended starting point. It brings subscription groups, server lists, the system proxy, routing, logs, and TUN together in one interface, making it suitable for progressing from basic use to rule management. On Windows, choose the newer desktop interface or the classic WPF version according to your preferences and workflow. On macOS, select the package matching your processor architecture. On Linux, choose deb or rpm according to your distribution. The download page lists the current entry points and filenames; this handbook does not hard-code version numbers.

The same subscription usually provides the same node content across desktop systems, but system proxy behavior, permissions, certificate storage, startup settings, and firewall behavior differ. When migrating, you can reuse the subscription URL and the approach to custom rules, but do not assume that every local setting transfers directly. TUN mode in particular depends on each system’s virtual network interfaces and permission model, so troubleshooting must account for the current platform.

On Android, Choose Between v2rayNG and v2flyNG

On Android, v2rayNG is the recommended choice. It uses the Xray core and suits configurations that need broad protocol and transport support. v2flyNG uses the V2Fly core and is an alternative for users who prefer the V2Fly ecosystem. Both support subscription imports, node switching, and local VPN capture, but their core capabilities, setting names, and compatibility with some configurations may differ. If a subscription depends on a specific core feature, first verify that the client’s core supports it rather than comparing interface appearance alone.

You also need to choose the package architecture. Most newer Android devices use arm64; the universal build is better when the architecture is unknown or wider device coverage is needed. Architecture only determines the native code included in the package and does not change subscription content. If the system says the package is incompatible, try the universal build first instead of creating a new subscription.

Do not use node count as a substitute for compatibility testing

The key question when choosing a client is not how many records it can import, but whether its core can parse the configuration completely and whether system traffic can be handed to the core reliably. A subscription list showing nodes only means that the text format or share links were recognized. Connections can still fail because transport parameters are missing, the core lacks support, the system clock is inaccurate, or the network is unreachable. A more reliable test is to use a confirmed working configuration and check whether the core starts, whether the logs report configuration errors, and whether the local proxy can process requests.

If you use both desktop and Android devices, they can reference the same subscription URL, but maintain each client’s local settings separately. Desktop setups commonly use the system proxy and detailed routing, while mobile devices more often rely on the system VPN interface; background execution, battery policies, and LAN access also differ. A subscription synchronizes remote configuration, not each device’s traffic-capture policy.

After choosing a client, stick with one primary client for the rest of your learning. Constantly switching between clients makes interface differences look like configuration failures. Starting with v2rayN on desktop and v2rayNG on Android provides a clearer path.

3. Installation Checklist: System Architecture, Permissions, and First-Launch Tests

Confirm Your System and Processor Architecture Before Downloading

Before installation, confirm three things: the operating system, the processor architecture, and whether the current account has permission to install software or change network settings. Windows users also need to choose between the newer desktop interface and the classic WPF interface. macOS users must distinguish Apple Silicon from Intel. Linux users should confirm whether their distribution uses deb or rpm packages and distinguish x64 from arm64. Android users can choose arm64 when the device architecture is known; otherwise use the universal build. A wrong architecture usually causes installation or startup failure, not a node connection error.

Open the client downloads page from within the site. It organizes packages by platform and explains the relevant architectures. Filenames may change with updates, so do not put an old filename in long-term notes. A more durable record includes the client, platform, and architecture—for example, “v2rayN, macOS, arm64”—so you can return to the appropriate platform panel when reinstalling.

Check Storage and Permissions on First Launch

Desktop clients typically need to store Subscriptions, logs, routing rules, and interface preferences. If the program is placed in a read-only directory or the current account cannot write to its configuration directory, settings may not persist, subscriptions may disappear after a restart, or the core may fail to unpack. After first launch, change a non-critical interface option and restart to confirm that it is retained. If the client provides a log-directory entry, verify that it can create files there.

The permissions needed to modify the system proxy, start at boot, and use TUN are not identical. A normal system proxy usually changes only the current user’s proxy settings; TUN creates a virtual network interface or changes the routing table and often requires elevated privileges. During the foundation stage, use the system proxy to establish a connection. Do not enable TUN, complex routing, LAN sharing, and custom DNS all at once. Introduce one variable at a time so errors are easy to undo.

1. Install the client. Choose a package matching your operating system and processor architecture, then complete the installation steps required by the system.
2. Launch it and check write access. Confirm that the client can save settings, create logs, and shut down normally.
3. Confirm that the core starts. Do not import a large number of configurations yet; check the logs for missing components, port conflicts, or permission errors.
4. Record the default local ports. You will need to know the SOCKS, HTTP, or mixed port later when configuring application proxies or investigating conflicts.

Understand Local Listening Ports

After starting, the core typically listens on one or more local ports at the loopback address, commonly written as 127.0.0.1. A SOCKS inbound suits applications that support SOCKS proxies; an HTTP inbound suits applications that support HTTP proxies; a mixed port may accept both kinds of requests. Use the ports shown in the client settings rather than copying someone else’s numbers. If another program is using a port, the core usually cannot start, and the logs will report a failed bind or an address already in use.

You can use network-status tools on desktop systems to confirm that a port is listening. The commands below only inspect local listening state; replace the example port 10808 with the value shown in the client interface. Run the first command in a Windows terminal, and the second on macOS or Linux:

netstat -ano | findstr 10808
lsof -nP -iTCP:10808 -sTCP:LISTEN

If there is no output, check the client logs before changing the subscription. If another process occupies the port, close the conflicting program or select an unused port in the client, then update applications where a proxy was configured manually. When the client manages the system proxy, it will usually follow the port change; browsers, developer tools, and terminals with manual proxy settings will not update automatically.

The goal of installation is not to turn on every feature at once, but to establish a reproducible minimum environment. Record the client name, system architecture, local ports, and configuration-directory location; upgrades, migrations, and troubleshooting will then be much more straightforward.

4. Subscriptions: Import, Update, Group, and Identify Formats

Subscription URLs vs. Individual Share Links

A subscription URL usually returns a set of configurations. When updated, the client fetches the set again and replaces or merges the contents of that group. An individual share link represents only one node and does not automatically track changes to a remote list. For long-term use, put the subscription URL in its own clearly named group. Place temporary test links in a separate group so it remains clear which entries are managed remotely and which were added locally.

Subscription content may be a base64-encoded list of share links, or native JSON or another structure that the client can parse directly. base64 is an encoding method, not an encryption protocol, and it does not determine whether a node uses VMess, VLESS, or Trojan. When format detection fails, do not repeatedly change proxy modes. First confirm that the response is complete, that the client supports the format, and that copying the URL did not introduce spaces or line breaks. For the relationship between formats, see Subscription Formats Explained.

Build a Maintainable Group Structure

Groups are not just for organizing a list; they also isolate update policies from local rules. At minimum, separate “daily subscription,” “temporary tests,” and “manual configurations.” Keep automatic updates for the daily subscription, update tests as needed, and protect manual configurations from remote overwrites. If the same URL is added to multiple groups, updates can create duplicates and make testing, sorting, and selecting the active node more confusing. When duplicates appear, inspect the subscription list first instead of deleting nodes one by one.

Before updating a subscription, the client must reach its URL. The request may use the current network directly or, depending on the client settings, go through an existing proxy. If the current node has expired and updates are configured to use the proxy, you can end up in a loop: you need an update to obtain a working node, but the update depends on the old node. Temporarily use a direct update or a confirmed working configuration, then restore the original policy after the update succeeds.

• Add the Subscription URL
• Name the Group
• Run the Update
• Check Node Fields
• Select the Active Configuration

What to Check After an Update

“Update complete” does not mean every configuration works. Check the result in three steps. First, confirm that the group contains nodes; if it is empty, focus on the response format and filters. Second, open a random configuration and check that the address, port, protocol, transport, and security options are not obviously missing. Third, select a configuration, start the core, and look for parse errors in the logs. Do not judge content by node names alone: names are notes and do not affect the connection.

The automatic update interval should not be so short that it repeatedly interrupts use. Set it according to the provider’s change frequency while keeping a manual update option. On long-running desktop devices, periodic checks are practical; mobile background restrictions may delay automatic tasks, making a manual refresh more reliable. Whether updates are automatic or manual, know when the last successful update occurred so you can tell whether a failure comes from an old configuration or the current network.

Layered Troubleshooting for Failed Subscription Updates

A failed update usually has one of four causes: the URL has changed, the current network cannot reach the subscription service, the response is in an unsupported format, or the client’s direct/proxy update policy is unsuitable. First confirm that the link is complete without exposing it, then switch the retrieval method and review the update log for HTTP status, parse messages, or timeouts. If the response succeeds but parsing fails, the problem is at the format layer; if there is no response, it is at the network or URL layer. See Steps for Handling Failed Subscription Updates for a complete workflow.

Reliable subscription management rests on three habits: isolate sources by group, keep the update path switchable, and verify update results. With this routine, remote list changes will not disrupt local custom rules or temporary test configurations.

5. Proxy Modes: System Proxy, Application Proxy, and Global Selection

Which Programs Does the System Proxy Control?

The system proxy writes a proxy address into the network settings provided by the operating system. Browsers and desktop applications that follow those settings send requests to the client’s local port, but not every program reads them. Some command-line tools, games, virtual machines, containers, and software with its own network stack may ignore the system proxy. If a browser works but one application does not, first determine whether that application follows the system proxy instead of assuming the node is unstable.

Options such as “clear system proxy,” “automatically configure system proxy,” and “leave unchanged” control operating-system settings; they are not core routing modes. The system proxy answers whether traffic enters the core, while the routing mode answers which outbound it uses afterward. These switches are often confused. The correct order is to confirm that traffic enters first, then assess direct, proxied, or blocked routing.

Use a Manual Application Proxy for Precise Testing

Applications with proxy settings can use 127.0.0.1 and the local port shown by the client. This affects only the target application and does not modify the whole system, making it useful for testing whether the local inbound works or for giving a development tool its own proxy. The proxy type must match the listening port: point SOCKS settings to a SOCKS inbound, and HTTP settings to an HTTP or compatible mixed inbound. If the type is wrong, the port may accept the connection while the protocol handshake still fails.

Terminal programs often read HTTP proxy settings from environment variables. The examples below use a local address and sample port and apply only to the current terminal session; you usually need to set them again after closing the terminal. Before using them, verify the client port and whether the target tool supports these variables.

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808

In Windows PowerShell, use environment variables for the current session:

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="socks5://127.0.0.1:10808"

What Global, Rule-Based, and Direct Modes Are For

Global proxy mode generally sends requests entering the core to the active proxy outbound first, making it useful for a quick connectivity check. Rule mode selects a proxy, direct, or block outbound based on domains, IPs, or other conditions and is the main choice for daily use. Direct mode sends requests entering the core straight to their destinations and is useful as a comparison test to determine whether a remote node is responsible. Mode names vary slightly between clients, but the logic is largely the same.

Troubleshooting can use the three modes as a comparison. If global proxy fails while direct access works, inspect the node and remote transport first. If global proxy works but rule mode fails, inspect routing matches. If an application still uses the proxy after the system proxy is disabled, it may have its own manual proxy setting or TUN may be enabled. Change only one switch at a time and restore the original settings afterward.

The key to proxy modes is not which one covers the most traffic, but which capture method matches application behavior. The system proxy suits ordinary desktop traffic, a manual proxy gives precise control, and TUN should wait until the basic path is stable.

6. Traffic Routing: Rule Order, Domain Matching, and IP Matching

Routing Rules Match in Order

Traffic routing selects a proxy, direct, or block outbound based on request characteristics. Most rule systems evaluate rules in a fixed order and stop after the first match, so correct rule content can still produce unexpected results when ordered incorrectly. A broad rule placed too early can swallow more precise rules that follow it; narrow exceptions should generally come before the corresponding general rule. Before editing, record the current mode and rule order so you can roll back quickly if testing fails.

Common match conditions include full domains, domain suffixes, IP addresses or ranges, ports, network types, and process names. Domain rules are readable and work well for stable domains. IP rules suit known address ranges but are costlier to maintain when services use dynamic addresses. Process rules depend on client and system support and may break when a program updates or moves. Begin with domains and reserved address ranges, then add more complex conditions after the logic is confirmed.

Why Domain Matching May Fail

Whether a rule can see a domain depends on what information accompanies the request when it enters the core. If the application resolves DNS first and passes only the IP to the proxy, a domain-only rule may not match directly. The core may recover the domain through sniffing or another mechanism, but this does not work for every type of traffic. Conversely, when an application passes the domain to the core through SOCKS, domain matching is usually more direct. During troubleshooting, inspect the target form in routing logs instead of focusing only on the rule text.

Domain-suffix rules also require clear boundaries. A suffix rule for example.com generally covers its subdomains, but it should not mistake another domain containing the same string for the same site. If the client offers full-domain, domain-suffix, and keyword matching, choose the most precise semantic type. Keyword matching is broad and useful for temporary tests, not as the foundation of long-term rules.

How to Read a Minimal Routing Configuration

The JSON below shows the basic structure of the routing section. The first rule sends LAN and reserved addresses directly; the second sends the example domain through the proxy; later default outbound handling covers the remaining traffic. direct and proxy must correspond to outbound tags that already exist in the complete configuration. This fragment explains field relationships and cannot run independently of inbound, outbound, and DNS configuration.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com",
          "full:api.example.net"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

AsIs means that the routing stage prioritizes the request’s original destination and does not proactively resolve every domain for IP rules. Different strategies change how domain and IP rules cooperate, so no single value is always better in isolation. If the current client rules are stable, do not change the strategy merely to make the parameters more complex. Adjust it alongside DNS settings and logs only when domain and IP matching clearly differs from expectations.

Design Rules Around Default Behavior

Before building a rule set, decide what should happen when no rule matches. A proxy-by-default design suits rule sets built mainly from direct exceptions; a direct-by-default design suits setups that proxy only a few clearly defined destinations. Both approaches work, but mixing them makes rules difficult to read. Document the default outbound and give each rule group a clear purpose, such as “direct LAN,” “proxy specified domains,” or “block a specific protocol,” rather than using ambiguous numbers.

Test rules against repeatable targets and observe the outbound tag actually matched in the logs. A page loading does not prove that routing is correct because a destination may allow both direct and proxied access. If the client offers routing debug logs, raise the log level temporarily, complete the test, collect the result, and restore the normal level. When changing multiple rules, enable and test them group by group rather than importing a complete rule set at once.

A reliable routing system has explicit default behavior, matching ordered from precise to broad, recognizable outbound tags, and repeatable test targets. Rule count is not a measure of maturity; explainability and reversibility are.

7. TUN Mode: Virtual Interface Capture, Permissions, and DNS Paths

The Fundamental Difference Between TUN and the System Proxy

The system proxy requires applications to read the operating system’s proxy settings. TUN uses a virtual network interface and routing table to capture a broader range of IP traffic. It is often more effective for programs that ignore system proxy settings, but it also introduces permissions, virtual interfaces, route conflicts, DNS paths, and LAN access as additional variables. TUN is therefore not a universal fix for a failed basic connection; it is a separate way to expand traffic capture after the basic proxy is stable.

After TUN is enabled, applications may still be unaware that a proxy exists. The operating system sends traffic into the virtual interface, and the client converts it into connections the core can process before applying routing. Because this happens at a lower layer, browsers, command-line tools, and some applications without proxy support can be handled consistently. Virtual machines, containers, other VPN software, and security tools may also modify the routing table, so multiple active components can create priority conflicts.

Establish a Baseline Before Enabling TUN

Before enabling TUN, use the system proxy to confirm that the current node, subscription, and routing rules work, and record the behavior with TUN disabled. Then turn off manual proxies inside applications so the same request does not enter a manual proxy and get captured by TUN again. After enabling TUN, check in order: whether the virtual interface was created, whether the logs show permission errors, whether the default route changed as expected, whether LAN access works, and whether DNS resolution returns results. Only after each step passes should you test programs that previously ignored the system proxy.

If the client requests elevated privileges, complete the authorization through the operating system’s normal process. Insufficient permissions often appear as virtual-interface creation failure, route-write failure, or a mode that turns off immediately. These errors are unrelated to the node protocol, so changing subscriptions usually does nothing. On desktop systems, also check for other active virtual network interfaces. On Android, confirm the system VPN capture state and background-execution restrictions.

1. Disable duplicate entry points.Clear manual proxies inside applications and keep one explicit traffic entry point.
2. Enable TUN and complete system authorization.Check whether the client successfully creates the virtual interface.
3. Check basic networking.Test domain access, direct IP access, and access to LAN devices separately.
4. Verify rule matches.Confirm that existing direct, proxy, and block rules still behave as expected under TUN.
5. Test the target application.Finally, check programs that could not previously be captured through the system proxy.

DNS Is Central to TUN Troubleshooting

If TUN can reach an IP address but not a domain, the connection path usually exists while DNS is failing. Possible causes include DNS requests taking an unexpected path, conflicts between client DNS settings and system settings, routing rules blocking resolution requests, or other network software still capturing DNS. Check the client logs for resolution timeouts first, then compare results with TUN disabled. Do not change the node, DNS server, and routing rules simultaneously, or you will not know which change helped.

Another possibility is that the domain resolves but rules match the wrong target. In a TUN environment, the core may recover the domain through sniffing or see only the resolved IP. Use the current routing strategy to determine whether rules match domains or IPs. If domain-based routing is essential, ensure that the DNS and traffic-capture paths preserve enough information. If the destination is stable, explicit IP or range rules can supplement the setup, but account for the maintenance cost of address changes.

LAN and Sleep/Resume Issues

After TUN changes routes, local printers, storage devices, or development services may be sent through the proxy by mistake. LAN and reserved addresses should normally go direct and appear before broad proxy rules. If LAN access works only with TUN disabled, check private-range rules and bypass settings rather than changing the entire rule set to direct. Test device names and LAN IPs separately: names involve local DNS resolution, while IPs primarily test routing.

After sleep, a network switch, or moving from wired to wireless, an old virtual interface or route state may not refresh immediately. The client may still show as running while new requests time out. Turn TUN off and on in the client to rebuild the interface; if that does not help, restart the core and inspect system routes. Leave a full system restart until last, because it erases the most useful error context.

A successful TUN setup is not defined by a switch staying on. The virtual interface, DNS, routing rules, LAN, and target applications must all produce explainable results. Validating the basic proxy and TUN in separate stages can greatly reduce troubleshooting time.

8. Routine Maintenance: Updates, Logs, Backups, and Layered Troubleshooting

Keep Client, Core, and Subscription Updates Separate

Routine maintenance involves three kinds of updates: the GUI client itself, core components, and subscription content. They solve different problems. A client update may change the interface, system integration, or configuration management; a core update affects protocol parsing, transport capabilities, and runtime behavior; a subscription update changes only the remote configuration list. When something breaks, identify which layer changed most recently. Do not treat a failed subscription update as proof that the client needs upgrading, and do not update every component at once when a node fails.

Before updating, record a working configuration, proxy mode, and important custom rules. Afterward, run a baseline test with the previous configuration before checking new capabilities. If you import a new subscription, change routing, and enable TUN immediately after updating, you will not know what caused a failure. For a stable long-term setup, maintenance is about controlled change, not chasing every available setting.

Read Logs as a Timeline

Logs commonly include client actions, core startup, configuration parsing, DNS, routing, and connection errors. Start by noting the exact time of the triggering action, then inspect only a small window around that point. During startup, focus on configuration paths, field parsing, port binding, and permissions. During connections, focus on DNS resolution, handshakes, timeouts, and routing outbounds. For subscriptions, focus on request status and content parsing. Do not isolate the final line; the root cause often appears earlier.

Raising the log level provides more detail but can quickly generate a large volume of records. Raise it temporarily before reproducing a problem, collect the result after one clear test, and restore the normal level immediately. When sharing logs publicly, keep only error types, timing, and necessary fields; hide subscription URLs, node addresses, user identifiers, and personal names in local paths. Logs reconstruct an event; they are not configuration backups.

Back Up What Can Be Restored

Useful backups include subscription group structure, custom routing rules, client preferences, local manual nodes, and essential configuration notes. The subscription URL can restore remote nodes, but not every local change. Store backup files in a controlled location and do not share them publicly. If the client supports configuration export, first check what it includes: some exports contain only nodes, some include routing and interface settings, and some reference local paths.

Do not overwrite all existing configuration at once during recovery. A safer process is to install and start the client, confirm the core baseline, import the subscription, restore routing, and handle TUN and startup settings last. Start once and inspect the logs after each step. Even when a backup comes from another system or an older environment, this makes it clear where incompatibility begins.

Create a Minimal Reproduction Configuration

Reduce a complex failure to one client, one subscription group, one known-good configuration, the system proxy, and default routing. Disable automatic selection, complex DNS, process rules, LAN sharing, and TUN, then reproduce the issue. If the minimal setup works, restore advanced settings one at a time. If it still fails, check configuration fields, the network, and core logs. Minimal reproduction does not mean permanently removing features; it means reducing variables temporarily.

Choose nodes based on real connection results, not only the latency value shown in the list. Latency usually measures the round-trip time of a particular probe and cannot fully represent destination access, transport handshakes, or sustained traffic. See How to Choose Nodes for a practical approach, focusing on real availability, protocol compatibility, and the target use case.

The core of maintenance is variable control. Layer updates, read logs chronologically, restore backups in stages, and reduce failures to a minimal configuration. These four habits cover most long-term usage problems.

9. Advanced Path: From Using a Client to Explaining Configuration

Stage One: Explain the Complete Data Flow

Advanced work does not mean immediately hand-writing a large configuration. First, learn to explain the complete path from an application to the remote server and identify how to observe each stage: whether the application reads the system proxy, whether the local port listens, whether the core starts, which outbound routing selects, whether node transport parameters are complete, and where DNS resolves. Once you can answer these questions, a vague “it won’t connect” becomes a specific layer to investigate.

Practice with one confirmed working configuration. Test the system proxy, a manual application proxy, and TUN separately, recording the differences in the logs. Then add one explicit domain rule in rule mode and watch how the outbound tag changes. The goal is not to create a complex environment, but to connect each operation with its corresponding log behavior.

Stage Two: Read Client-Generated Configuration

A GUI client ultimately has to translate interface options into core configuration. When exporting or viewing generated configuration, find the four sections— inbound, outbound, routing, and DNS—then map each one back to the interface settings. The example below shows a SOCKS inbound that listens only on the local machine. It illustrates the fields and contains no usable remote outbound, so it is not a complete configuration.

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

tag references the object within the configuration, listen restricts the listening address, port is the local port, and protocol specifies the inbound type. If you change the listening address to all network interfaces, other devices on the LAN may reach the port, changing the security boundary. Unless sharing is intentional, keep the loopback address. When learning configuration, understand existing fields before adding parameters of unknown origin for the sake of “optimization.”

Stage Three: Compare the Boundaries of the Xray and V2Fly Cores

Xray and V2Fly are both part of the broader Project V ecosystem, but their maintenance directions and feature sets are not identical. The client is only the container; the core and the client’s configuration adapter determine whether a protocol extension or transport capability works. When the same share link behaves differently across clients, check which protocols and security features it uses, then verify support in the target core instead of attributing the difference to the platform alone.

Compare cores around actual requirements: which protocols the subscription uses, whether it depends on VLESS, REALITY, or XTLS capabilities, whether the client generates the corresponding configuration correctly, and whether its logs provide enough troubleshooting detail. If the current configuration uses only standard capabilities supported by both, choose the client that best fits the platform and your maintenance habits. See Xray vs. V2Fly Core Differences for a detailed comparison.

Stage Four: Build a Testable Rule System

A mature routing system is not defined by its rule count. It has clear default behavior, group purposes, and a way to verify results. Start with three groups: direct LAN and reserved addresses, a set of explicit domains routed according to need, and a default policy for everything else. Prepare one repeatable test target for each group and inspect matched tags after every change. Before adding a rule, state the problem it solves; a rule with no clear purpose should not enter a long-term configuration.

DNS changes should also address a specific problem. Modify the query method and routing relationship only after confirming that the resolution path causes failed matches, timeouts, or inconsistent results. Changing DNS, sniffing, routing policy, and TUN into one complex arrangement may happen to work briefly but will be hard to maintain. Advanced skill means narrowing the scope of a change and explaining why it is needed.

Stage Five: Create a Personal Operations Guide

A personal operations guide need not be long, but it should list the client and platform, package architecture, configuration directory, local ports, subscription groups, custom rules, whether TUN is enabled, update methods, and rollback steps. Add two minimal tests: one for the system proxy and one for routing matches. After migrating or upgrading a device, restoring the setup from this checklist is more reliable than relying on memory.

When a new problem appears, update the guide with the symptom and resolution before adding extra rules. Over time it becomes a stable baseline suited to your own devices and applications. Changes to the client interface then matter less because the core checks still revolve around inbound, outbound, routing, DNS, and traffic capture.

The path from beginner to advanced can be summarized as follows: establish a minimal working path before expanding traffic capture; understand rule matches before adding more rules; create a recoverable baseline before upgrading the client and core. When something breaks, return to the data flow instead of switching settings at random.