V2Ray from Beginner to Advanced: The Complete User Guide

What the client, core, and configuration each do

What people call a V2Ray client is usually made up of three parts: a graphical interface, a proxy core, and configuration data. The interface handles subscriptions, node management, mode switching, and log display. The core listens on local ports, creates outbound connections, and applies routing rules. The configuration describes how inbounds, outbounds, DNS, and routing relate to one another. When something fails, identifying the affected layer is more effective than reinstalling repeatedly. An interface that opens only proves the management layer is working, and a node marked “selected” does not prove that the outbound handshake succeeded. Confirm the actual result with a test request and runtime logs.

v2rayN is the primary graphical client for Windows, macOS, and Linux desktops, and can manage configurations for cores such as Xray and V2Fly. v2rayNG is designed for Android and commonly uses the Xray core; v2flyNG is another Android option built around the V2Fly core, suited to users with matching configurations or a preference for V2Fly configuration semantics. The terms “client” and “core” are not interchangeable: a protocol in a subscription can connect only when the active core supports it. Whether the interface displays a node is not the final compatibility test.

What happens during a web request

When a browser opens a webpage, the application first sends the domain to DNS for resolution. The request then either enters the local proxy entry point or bypasses it, depending on the system proxy, application proxy, or TUN state. Once inside the client, the routing module selects an outbound based on the domain, destination address, port, network type, or process. The proxy outbound uses the node parameters to connect to the remote service, then returns the response along the same path. Any stage can produce the symptom “the page will not open,” but the underlying fault may be completely different: a DNS failure leaves no usable destination, an inactive system proxy keeps the request out of the core, a routing mistake sends it to the wrong outbound, and a failed node handshake leaves connection or authentication details in the error log.

Troubleshoot from near to far along the data flow: confirm that the core is running and listening on a local port, verify that the target application is actually using that entry point, then inspect DNS and routing decisions, and only afterward evaluate the node and network path. Replacing connectivity checks with a speed test can obscure the real issue. A successful TCP test proves only that a port is reachable; protocol handshakes, DNS behavior, and destination routing still require a real request and the logs to confirm.

Keep the protocol, transport, and security layers separate

Names such as VMess, VLESS, and Trojan primarily describe proxy protocols and authentication; TCP, WebSocket, and gRPC describe how data is carried; TLS and REALITY affect the handshake and encryption layer. A subscription combines these parameters into a node, and the imported configuration must preserve the relationships required by the server. When editing manually, a mismatch in the address, port, user identifier, transport, hostname, path, or security layer can cause a timeout, handshake failure, or authentication rejection. Do not infer transport parameters from the protocol name, and do not change multiple fields at once in the name of optimization.

It is also important to separate subscription management from individual node configuration. A subscription is a set of node descriptions maintained by a provider; updating it may add, remove, or modify nodes. An individual node is the specific outbound currently available for selection. Renaming a subscribed node locally is usually harmless, but changes to its address, port, or protocol parameters may be overwritten on the next update. Long-term local routing, DNS, and proxy-mode settings belong in the client’s dedicated settings, not inside subscription content. With this layered model, each later action has a clear home: the download page covers software sources, subscriptions provide outbound information, the system proxy or TUN provides the traffic entry point, routing rules determine the destination, and logs reconstruct the entire path.

Choose by platform and core requirements

For desktop platforms, start with v2rayN. Windows users can choose between the desktop edition and the classic WPF edition: the desktop edition uses a newer cross-platform interface and suits users who want similar workflows across desktop systems, while the classic WPF edition is a good fit for users familiar with the traditional Windows interface. On macOS, choose the installer for Apple Silicon or Intel. On Linux, select deb or rpm according to the distribution and verify the x64 or arm64 architecture. All entry points are consolidated on the client download page; do not rename an installer for another platform and try to force it to run.

For Android, v2rayNG is the primary choice, especially when a subscription includes nodes using Xray features; v2flyNG is the alternative for the V2Fly core. Most current devices use arm64 packages. Consider the universal build only when the architecture is unknown or installation fails. Both clients can read common subscriptions and share links, but their core support is not identical. Check the protocols and transports actually included in the subscription before choosing a client instead of inferring compatibility from the interface name.

Identify the system architecture before installing

On Windows, view the system type under “Settings — System — About”; on macOS, check the chip name in System Information; on Linux, read the architecture from a terminal. The goal is not to choose the most elaborate package, but to avoid an installer that will not launch or software that cannot find the required components. Common Linux commands are shown below. Choose x64 for x86_64, and arm64 for aarch64 or arm64:

uname -m

# Check the package architecture on Debian, Ubuntu, and similar systems
dpkg --print-architecture

# Check the machine architecture when using the rpm package ecosystem
rpm --eval '%{_arch}'

Keep the installation or extraction directory stable and writable, and avoid moving it frequently. Clients usually store subscriptions, logs, routing rules, and interface settings as well. Moving to a new directory for every update without migrating the configuration can create the illusion that nodes have suddenly disappeared. After the first desktop launch, confirm that the interface shows the core status and log entry point; do not immediately import multiple subscriptions or enable TUN. On the first mobile connection, the system will request network connection permission so traffic can be handed to the client. After granting it, review battery management settings so background operation is not stopped prematurely.

Break the first launch into three checkpoints

The first checkpoint is whether the client opens normally, which catches architecture, runtime, and permission issues. The second is whether the core starts; even without a node, there should be no port conflict, configuration parse failure, or missing component. Only the third checkpoint asks whether a node can connect after import. This separation means an error in step two does not require suspicion of the subscription. On desktop systems, also check that the local listening port is not used by another proxy program; conflicts are especially common when several network tools run at once.

Before upgrading the client, stop the running core and back up the client configuration directory. After the upgrade, check that existing subscriptions and routes remain, then run a connection test in ordinary proxy mode. Do not replace the client, switch cores, rewrite DNS, and enable TUN on the same day; otherwise it becomes difficult to establish causality. If system policy blocks installation, first confirm that the downloaded platform and architecture are correct, then follow the operating system’s normal software authorization process. Do not bypass the error by modifying unknown system files.

The final installation check is simple: the client starts reliably, the core log shows no recurring startup errors, the local proxy port is listening, the configuration directory is known, and you know how to exit the client completely. Complete these basics before moving to subscriptions so software-installation issues are not mistaken for node failures. If you only need one initial connection, follow the quick-start path; if you need to manage multiple subscriptions long term, continue to the next chapter and establish naming, update, and rollback rules.

The correct order for importing a subscription

A subscription URL is essentially a configuration source that the client reads periodically. Add it in the client’s subscription manager, give it a local note that identifies its source and purpose, and then run an update. Once the update succeeds, the nodes appear in the relevant group; select one as the current server and start the connection. Do not paste the subscription URL into a browser address bar or show the complete URL in a public page or screenshot, because it may contain parameters used to identify the subscription.

A single client can manage multiple subscriptions, but importing many sources during first-time setup is not recommended. Use one subscription to complete the connection loop, verify that updating, selecting, starting, and testing all work, then add groups for work, daily use, or testing. Names should describe purpose rather than “Subscription 1” or “Subscription 2”; otherwise it becomes difficult months later to tell which rules and nodes belong together. Updating a subscription only synchronizes the nodes supplied by the provider—it does not prove that every node suits the current network.

Understand updates, overwrites, and local settings

When a subscription is updated, the client usually rebuilds the nodes in that group from the new content. Nodes removed by the provider may disappear, changed parameters may be replaced, and locally edited subscription nodes may revert to remote values. Do not store long-term routing policies or important notes only inside a subscription node. Keep durable content in the client’s separate routing configuration, DNS settings, or backup records. If a temporary node adjustment is necessary, copy it into a local configuration and document its purpose so an overwritten value can be identified later.

An unchanged node count after an update does not mean the update failed; the provider may have changed only an address, port, or transport parameter. Check the client notification and subscription-update log, then inspect a few nodes for their update time or key fields. If the log shows a failed network request, first confirm that the current network can reach the subscription source, then check the system clock, proxy state, and URL completeness. If the subscription must be fetched through the existing proxy, the current node must still work; otherwise you get a “must update to connect, must connect to update” loop. Temporarily switch to a known-working local node and update again.

Separate the goals of node testing

Common client tests include port reachability, protocol latency, real requests, and speed tests. Port reachability checks only whether a basic connection to the remote port can be established; it is quick but limited. Protocol latency includes more handshake steps and is closer to everyday use. A real request is also affected by DNS, the destination site, and routing rules. A single result describes only the conditions at that moment; a difference of a few milliseconds is not a long-term quality verdict. Stability, packet loss, peak-hour congestion, and protocol overhead may matter more than one latency number.

First eliminate nodes that fail consistently, then compare several working nodes through real requests. Keep the proxy mode, destination, and approximate test time consistent, and avoid changing DNS while switching nodes. For unusual speeds, use three-layer troubleshooting for nodes, network paths, and local settings to validate each factor separately. Do not run large concurrent downloads during testing, or the test itself will saturate the connection.

The boundary between manual imports and share links

A single share link is useful for temporarily importing one node; a QR code works for transferring a short configuration between trusted devices; a subscription is best for continuously syncing a group of nodes. When entering values manually, verify the address, port, user identifier, transport, TLS or REALITY parameters, hostname, and path one by one. Similar-looking text does not guarantee identical meaning: slashes in a transport path, capitalization in a service name, and the server-name indication field can all affect the handshake. If import immediately reports a configuration parse error, check the format first. If the client starts but the connection times out, check the address, port, and network. If the log reports authentication rejection, return to the user identifier and security parameters.

The goal of node management is not to accumulate as many entries as possible, but to keep sources clear, groups organized, and updates controllable. Periodically remove long-failed local test nodes, retain useful notes, and avoid manually editing the same configuration in multiple clients. Across devices, let each device update its own subscription and maintain its local routing and proxy mode separately; this is usually safer than copying the entire client data directory. By the end of this chapter, you should be able to answer three questions: which subscription group provides the current node, whether the last update succeeded, and whether the failure occurred while reading the subscription or during the protocol connection.

Separate the traffic entry point from the routing result

“System proxy” and “global proxy” are often used interchangeably, but they belong to different layers. The system proxy determines whether applications that follow the operating system’s proxy settings send requests to the client. Global mode in routing determines whether requests that have already entered the client all use the proxy outbound. The former is the entry point; the latter is the destination decision. Enabling global routing without sending application traffic into the client still allows direct access. Enabling the system proxy while routing classifies a destination as direct also avoids the remote node. Check both states separately when troubleshooting.

Browsers, desktop software, and command-line programs do not follow the system proxy equally. Some read system settings, some require an HTTP or SOCKS port in their own network settings, and some retain the old configuration read at startup. If an application does not change after the system proxy is modified, fully quit and restart it, then check for an independent proxy option. Do not use one browser’s result to assume that every program has been captured.

Three common operating modes

Rule mode is the best everyday default: requests entering the client are sent to a proxy, direct, or blocked outbound according to the domain, address, or other conditions. It avoids unnecessary remote connections, but depends on rule quality and DNS coordination. Global mode is useful for short diagnostic tests: when a rule may be misclassifying a destination, temporarily send all captured requests through the proxy outbound. If global mode works but rule mode fails, the issue is more likely in routing or DNS classification than in the node. Direct mode helps verify the local network without a proxy and can temporarily stop remote outbounds during maintenance.

Mode switching should help locate a fault, not become permanent trial and error. Recommended order: use rule mode by default; when one destination behaves abnormally, temporarily switch to global mode; if global mode also fails, check the node and DNS; once the cause is understood, return to rule mode. Staying in global mode hides faulty rules and may send local-network or local-service traffic to a remote node unnecessarily. Direct mode also does not mean the client has fully exited, since local ports and some capture capabilities may still be running.

Local ports and environment variables

After startup, the client usually listens on HTTP, SOCKS, or mixed ports bound to the local loopback address. Use the port shown in the interface. To proxy a command-line program, set environment variables for the current terminal session. The example below uses port 10809; replace it with the client’s current HTTP port before use:

# Current terminal session on Linux and macOS
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# Clear the variables after testing
unset HTTP_PROXY
unset HTTPS_PROXY

Environment variables affect only programs that read them and their child processes; they do not change the entire system. SOCKS and HTTP addresses are not interchangeable. When a program requires an HTTP proxy, enter the HTTP or mixed port; use the SOCKS port only when SOCKS5 is supported. If another process occupies the port, the core usually cannot bind to it and the log will show a bind failure. Exit the conflicting program or choose an unused port in the client, then reload the configuration.

How to prove that the proxy path is working

Do not rely only on the client’s tray icon. First check whether the core log shows the target request, then test one ordinary webpage and one command-line request separately. If the browser works but the command line fails, their entry points are probably different. If the log shows no new request at all, traffic has not entered the client. If it shows a request followed by failed to dial, a connection refusal, or a timeout, continue with the node and outbound checks. For common log fields, see How to diagnose V2Ray runtime logs.

When the client says it is connected but webpages do not open, do not interpret “connected” as proof that every stage is complete. It may mean only that the core is running or a node is selected. Check the system proxy, node availability, DNS, routing, and system clock one by one. See the troubleshooting order for a successful connection with no web access for a complete checklist. Once the difference between entry point and destination is clear, routing in the next chapter becomes much easier to reason about.

How routing rules match

The routing module receives connections that have entered the client and selects an outbound such as proxy, direct, or block. Common conditions include domains, destination ranges, ports, network types, and process information. Rules are normally evaluated in order, with the first match taking effect; unmatched traffic goes to the default outbound. As a result, changing the order of identical conditions can completely change the result. Broad rules should come after specific ones, or an early wildcard will capture requests before later rules can take effect.

Domain rules are suited to websites and service groups. Address rules are suited to LANs, reserved addresses, and explicit network ranges. Port rules describe only a service port and cannot represent a business category on their own. Process rules depend on client and platform support and may break when an application updates or changes path. Prefer stable, readable conditions and document the purpose of custom rules. Do not leave temporary test rules at the top of the list indefinitely.

Start with three rule layers instead of importing a huge list

A maintainable starting point can use three layers. The first handles local hosts, LANs, and reserved addresses and sends them direct. The second handles business domains that require a fixed outbound. The third is the default for everything else. When something fails, this structure makes it clear which layer matched. Direct rules for LAN devices, router admin pages, and local development services should come first so requests are not sent remotely and then unable to return.

Before adding a rule, answer “What specific problem does it solve?” If one domain fails in rule mode but works globally, inspect the target domain, resolved address, and matched outbound in the logs before deciding whether to add a domain rule or adjust DNS. If the domain has already been resolved to an address before routing and the rule matches only domains, behavior may differ from expectations. Check the relationship between sniffing, domain strategy, and DNS instead of repeatedly adding the same domain.

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

This configuration illustrates the structure; do not use it to overwrite the complete configuration generated by the client. domain:example.com matches the domain and its subdomains, full:service.example.net matches only the exact domain, and geoip:private identifies private address ranges. The final rule covers the remaining TCP and UDP traffic, so it must come after the specific rules. Actual clients may use graphical rule sets, predefined tags, or a different configuration-generation method. Apply the equivalent settings in the interface and confirm the result through the final runtime configuration or logs.

Observe DNS and routing together

Domain access has two stages: resolution and connection. DNS queries may have their own route, and the result then participates in address-based rules. If DNS goes direct while the connection uses a proxy, or if the resolved address differs from the remote environment, the result may be timeouts, partial resource failures, or unexpected rule matches. When changing DNS, define the goal first: fix resolution failures, avoid local resolution differences, or have a particular server answer selected domains. Do not enable multiple overlapping DNS schemes at once.

AsIs generally means preserving the domain for matching whenever possible, without proactively resolving it for routing rules. Other domain strategies may resolve the domain to an address under specific conditions and then apply IP rules. The right choice depends on the rule structure, not on a simplistic assumption about which is faster. If domain rules are primary, ensure domain information is retained. If address rules dominate, verify that the resolution source is stable. After changing the setting, test a few known destinations and check the matched rule and outbound label in the logs.

Keep a record of routing changes

For each change, address one clear goal and record the new condition, expected outbound, and test result. If something goes wrong, temporarily disable the most recently added rule and assess the result instead of adding more rules to the top. After updating a rule set, run regression tests for LAN access, an ordinary webpage, a destination that requires a proxy, and a UDP application. Testing one webpage cannot cover the entire routing setup.

Mature routing is not about having many rules; every rule should have an explainable source, order, and result. For old rules you cannot explain, move them to a disabled area and observe before deleting them. Keep a simple default configuration for rollback and run complex experiments in a copy. If an update causes connection problems, this makes it much faster to tell whether the node failed or the decision layer changed.

TUN solves a traffic-capture problem

TUN mode uses a virtual network interface to hand more system traffic to the client. It is useful for applications that ignore system proxy settings, certain UDP traffic, and situations that require routing rules to be applied consistently. It is not a new proxy protocol and cannot repair an unusable node. If the system proxy already covers browsers and common software, there is no need to enable TUN immediately just for broader coverage. The larger the capture scope, the more carefully you must define the relationships among DNS, LAN access, other network tools, and system routes.

Before enabling TUN, complete three baseline tests: the node works in ordinary system-proxy mode, primary destinations route correctly in rule mode, and the system network recovers after the client is closed. If any of these is unresolved, TUN will wrap the existing issue in a more complicated path. Once the baseline is stable, enable TUN without changing the node, DNS, or rules so you can attribute any difference to the virtual interface.

First-enable sequence

First exit other network tools that may create virtual adapters or modify the default route. Then enable the components and system permissions required by TUN in the client. After startup, check the log for interface-creation failures, route-write failures, or insufficient permissions. Test an ordinary webpage, a LAN address, and an application that ignores system proxy settings separately. Do not judge success from the tray status alone. If webpages work but LAN access fails, check direct rules for private addresses and strict-routing options. If every domain fails while direct address access responds, inspect DNS capture first.

After Android network traffic is taken over by the client, confirm that the intended configuration is active and review per-app proxy settings. Per-app proxy can capture only selected applications or exclude applications that should bypass the client; choose according to the goal. When rules are complex, validate a small number of apps first and expand gradually. Background operation is also affected by battery policies. If the connection drops after the screen locks, first check whether the client was stopped rather than assuming the node failed. See v2rayNG permissions, battery-saving, and per-app proxy settings for details.

DNS capture and virtual address mapping

In a TUN environment, the client may capture DNS queries and use virtual address mapping for domains, allowing later connections to recover the original domain for routing. This can help applications that expose only address-based connection information, but it requires DNS queries and connections to follow a consistent path. If an application has cached an old result, it may continue using the old address after a configuration change. Restart the application during testing and allow time for caches to expire when necessary. Do not switch repeatedly among several DNS modes and compare only one immediate result.

When some websites open but others time out, check whether failed requests include the domain, resolved address, and matched route. If the log contains only an address and no original domain, domain rules may not match as intended. If DNS queries never enter the client, check whether the system is still using another resolution path. If the query succeeds but the connection goes to the wrong outbound, return to rule order. DNS issues commonly mean no usable destination or an unsuitable address; node issues usually have a clear destination but fail during the handshake.

Handle conflicts and exit safely

Running several tools that modify system routes, DNS, or virtual adapters is a common cause of competing default routes. During troubleshooting, keep only one traffic-capture tool active, close the others, and restart the client. If the network is abnormal after waking from sleep, disable TUN and stop the core, then rebuild in this order: start the core first, enable TUN second. Force-killing a process can leave proxy or route state unrestored, so use the client’s normal exit flow whenever possible.

Acceptance after TUN setup is more than “the app can connect.” LAN access should still work, rule-mode matches should be expected, DNS logs should not show recurring errors, the connection should recover after sleep, and the system network should be restored after a normal client exit. If any item is unstable, return to ordinary system-proxy mode and solve issues one by one instead of adding more exceptions. TUN is valuable because it expands the controllable traffic scope, provided the entire path remains explainable and reversible.

Treat updates as three separate objects

Routine maintenance includes at least three kinds of updates: the client, the core, and the subscription. A client update can change the interface and configuration-generation logic; a core update can change protocol support and runtime behavior; a subscription update synchronizes node data only. Doing all three at once makes failures hard to attribute. A safer approach is to handle them in batches: record the current working state, update one object, complete startup, connection, routing, and exit tests, then move to the next.

A client update notice does not mean you must interrupt current work immediately. Read the change notes, confirm whether the features you use are affected, and schedule maintenance accordingly. Subscriptions can be updated more often, but keep one working node for rollback. Core changes deserve particular care because the same node parameters may have different support and defaults across cores. For the focus areas of Xray and V2Fly, see differences between the Xray and V2Fly cores.

What to back up and how to restore it

Useful backups include subscription-group information, local nodes, custom routes, DNS settings, proxy ports, interface preferences, and relevant log excerpts. Subscription URLs may contain identifying parameters, so keep backup files on controlled devices and never upload them to public storage. Copying only the installer cannot restore a working setup; configuration data determines behavior. When the client provides an export function, use it first and record the client type and operating system at export time.

To restore, first install a client matching the platform and architecture, import the basic configuration, and confirm that the core starts. Then restore the subscription and update the nodes. Finally restore custom routing, DNS, and TUN. Do not overwrite every old file in the new environment at once, because paths, permissions, and configuration structures may differ. Layered restoration takes a few more steps but reveals exactly where an error was introduced. Also check that local ports do not conflict with other programs on the new system.

Read logs in the order “time — entry — decision — outbound”

Start by narrowing the time range. Clear or mark the current log, then perform one operation that reliably reproduces the problem so old errors and background requests do not mix in. Next check whether the request entered the local entry point; if not, inspect the system proxy, application proxy, or TUN. Once it entered, identify the selected outbound label. Only after the outbound is correct should you inspect connection, handshake, and authentication results. This sequence is more reliable than searching an entire log for “error”.

failed to dial usually means that establishing the outbound connection failed; use the following timeout, refusal, or network-unreachable details to identify why. connection rejected may come from a remote refusal, a blocked route, or a service that is not listening. Authentication messages require checking the user identifier, time, and security parameters. A single error line cannot replace its context, so inspect the preceding and following request target, outbound, and retry behavior as well. For detailed field explanations, see how to diagnose common V2Ray log errors.

Use minimal variables to handle common failures

When a connection fails, switch back to a known-working node and ordinary system-proxy mode. Disable custom DNS, complex routing, and TUN, keeping only the shortest path. If the baseline recovers, enable routing, DNS, and TUN one at a time in that order. If it still fails, check subscription parameters, node status, the local clock, and the network environment. Change one variable at a time and record the result. Trying a dozen nodes without reading the logs usually proves only that the problem remains; it does not identify the affected layer.

Slow performance also requires separating handshake time, time to first byte, sustained throughput, and destination-specific limits. Test the same node at different times, then compare several nodes at the same time. Next disable experimental options that may add overhead and check local downloads, wireless networking, and system resources. Do not equate the lowest latency with the highest sustained speed. See step-by-step V2Ray speed troubleshooting for the full method.

Clean up periodically instead of resetting frequently

During maintenance, remove long-failed nodes, duplicate subscriptions, obsolete route copies, and very old logs—but first confirm that none is still needed for rollback. Frequent client resets destroy the evidence and allow the same configuration errors to recur. If a fault reproduces consistently, export the necessary settings and logs before running minimal tests. Rebuild the environment only after confirming that the configuration cannot be recovered.

A healthy configuration has a clear subscription source, a traceable current node, an obvious proxy entry point, explainable rules, an independently switchable TUN, and a system network that works after the client exits. The purpose of routine maintenance is not constant adjustment, but reducing unknown states. When the baseline, changes, and rollback path are all recorded, most failures can be isolated in a limited number of steps.

Stage 1: Explain the current configuration

Advanced work does not begin by adding more rules; it begins by explaining the configuration you already have. You should be able to identify the core in use, the source of the node parameters, the local entry points being listened on, how the system proxy or TUN sends traffic in, which outbound the default route selects, and who handles DNS queries. A simple data-flow diagram helps: the application creates a request, the entry receives it, DNS supplies an address, routing selects an outbound, and the node creates the remote connection. Any switch that cannot be placed on this path deserves investigation before it is enabled.

Practice this stage by creating a minimal configuration copy with one working node, default DNS, and three routing layers. In the copy, test the system proxy, in-application proxy, and TUN separately, and record the log differences. The goal is not complexity, but observable results for every switch. Once complete, you can rebuild the environment on another device from the data flow instead of relying on memory of the old interface.

Stage 2: Turn routing and DNS into test subjects

Choose several fixed test destinations representing the LAN, direct traffic, proxied traffic, TCP, and UDP. Run the same test set after every rule change and record the actual matched outbound. For domain rules, compare keeping the domain with resolving it to an address first. For address rules, observe whether resolution changes the result. For process rules, test behavior after the application updates or its path changes. This turns “routing feels wrong” into a reproducible set of conditions.

The key to advanced DNS work is understanding query direction, caching, and domain recovery—not stacking more servers. First confirm whether system queries enter the client, then identify the resolution path selected by the client, and finally see how the result participates in routing. When something fails, test domain resolution and the target connection separately so the two error classes are not confused. Every DNS change should have a defined goal and a way to restore the defaults.

Stage 3: Understand core differences and protocol boundaries

Xray and V2Fly both originate in the Project V ecosystem, but they differ in emphasis across protocol extensions, feature development, and configuration support. You do not need to memorize every implementation detail, but you should know that some node features depend on a particular core, and a client name cannot replace a core-compatibility check. v2rayN manages the corresponding core configurations on desktop systems, v2rayNG is commonly used in the Xray direction, and v2flyNG corresponds to the V2Fly direction. Before switching, confirm that the subscription’s protocol and transport are supported.

Break down a configuration in this order: “address and port — authentication — protocol — transport — security layer — routing”. Address and port identify the remote location; authentication identifies the user; the protocol defines message semantics; transport describes how data is carried; the security layer handles the relevant handshake; routing determines when this outbound is used. Checking errors at this level is more effective than copying an entire alternative configuration.

Stage 4: Build your own troubleshooting handbook

Organize real incidents into seven fields: symptom, environment, minimal reproduction, logs, cause, fix, and rollback. Describe observable results—for example, “the browser request does not appear in the log”—rather than “the proxy is broken”. Record the platform, client, and current mode without irrelevant detail. Keep only the steps needed to trigger the issue, and tie the cause to a specific point in the entry, resolution, routing, or outbound path. This is more useful for long-term work than collecting scattered tutorials.

When a problem cannot be solved immediately, restore a working state before continuing the analysis. If rule mode is failing but global mode works, keep the temporary working option and copy the configuration for investigation. If TUN is unstable, return to the system proxy; if a new core causes problems, return to the previous core direction. Rollback is not giving up—it protects the baseline. Experiments are meaningful only when a stable baseline exists.

A sensible order for continued learning

First become comfortable with client logs and routing matches, then go deeper into DNS, TUN, and protocol details. Logs provide facts, routing determines behavior, and DNS and TUN expand the variable set. Reversing this order makes it easy to face multiple system layers before understanding the basic request path. For specific issues, browse the news and troubleshooting articles by topic. To rebuild the shortest connection path, return to the quick-start guide. When changing platforms or reinstalling, use the client download page to verify the package type.

The end result of going from beginner to advanced is a stable engineering method: establish the basic path first, add features layer by layer, read the logs before forming a theory, save a baseline before experimenting, and change one key variable at a time. With this order, changing clients, subscriptions, or network conditions does not force you to guess from scratch. If you can trace a request from the application to the outbound and restore any stage to a known state, you have the core skills to maintain a V2Ray client environment independently.