Advanced V2Ray Configuration Guide

Separate client settings, core configuration, and system network state

The most common problem with advanced configuration is not a completely incorrect parameter, but changing several layers at once. The v2rayN interface handles subscriptions, server selection, the system proxy, the TUN switch, and configuration generation. The Xray or V2Fly core executes inbounds, outbounds, DNS, and routing. The operating system determines the default route, network interfaces, name-resolution order, and whether applications bypass the proxy. These layers affect one another, but they must be separated during troubleshooting. Seeing “client started” only means that the process is running; it does not prove that system traffic has entered the core as intended.

Before making changes, keep a known-good system proxy configuration for rollback. Choose a server that connects normally, use the default routing mode, disable TUN and FakeDNS, and confirm that both a browser and a commonly used desktop application can reach the target site. Then record the current subscription group, active server, system proxy state, DNS settings, and routing mode. This creates a control case: if something breaks after enabling a feature, you can immediately return to the baseline instead of testing among several unknown variables.

Understand configuration files by responsibility. In a typical structure, inbounds receive traffic from the system proxy or TUN, outbounds define proxy, direct, and blocking exits, routing.rules determine which exit receives traffic, and dns controls how domains are resolved. Each routing rule's outboundTag must exactly match an outbound's tag; DNS server selection can also be affected by routing rules. Copying only one section while ignoring related tags usually produces a configuration that loads but behaves incompletely.

Use minimal changes to narrow the problem

Proceed in this order: subscription cleanup → routing → DNS → TUN → FakeDNS → custom outbounds. Subscription and server filtering only affect the available server set and are relatively low risk. Routing and DNS change where requests go, while TUN covers a broader range of traffic, and FakeDNS depends on TUN or a transparent proxy chain. If you reverse the order, a problem with name resolution or network interfaces makes it difficult to tell whether the root cause is the server, routing, DNS, or virtual adapter.

After each change, run at least three types of checks. First, test a domain by opening a known webpage to verify HTTP and TLS connectivity. Second, test a direct IP connection to distinguish DNS failures from transport failures. Third, check application coverage by testing a program that follows the system proxy and one that does not. If the domain fails but the IP works, check DNS first. If the browser works but another application fails, determine whether that application uses the system proxy or TUN. If everything fails, check the active server, outbound tags, and core logs.

Log inspection should have a clear purpose. During startup, look for configuration parsing, occupied ports, permission issues, and virtual-adapter errors. During connections, check the domain, destination port, matched outbound tag, and upstream handshake result. During shutdown, confirm that the system proxy and routes are restored. Do not leave the log level at its most verbose setting indefinitely: large volumes of normal connection records can hide important errors. After troubleshooting, restore the usual level and keep only a short context window around the incident.

Keep subscription sources separate from their intended use

Subscription groups answer “where do these servers come from?”, while server filters answer “which servers do I need to see right now?” Do not combine these concepts in one name. Group names should describe a source or purpose, such as “Daily,” “Testing,” or “Backup.” Server names should retain the original region, protocol, or provider details. This keeps the overall structure intact even when a subscription update changes server names. Keep group names short and stable rather than packing them with expiry dates, temporary statuses, and long notes.

When adding subscriptions in v2rayN, create a separate group for each link and update one group at a time. Do not select everything during the first import: one malformed subscription can make the result difficult to interpret. After the update, check whether the server count is as expected, then open a few entries at random to verify that the address, port, protocol, and transport fields are complete. A subscription only delivers server configuration; it does not decide your routing policy, system proxy mode, or DNS strategy.

Filters work best when server names contain stable markers. Common approaches include including or excluding keywords—for example, showing only entries whose names contain “low multiplier” or a region abbreviation, or excluding non-connection entries such as “maintenance” and “traffic remaining.” Regular expressions are more flexible but also more prone to false matches. Narrow the list with ordinary keywords first, then use a regular expression only if necessary. Chinese parentheses, full-width symbols, spaces, and case differences can all affect matching.

Include any matching keyword
HK|SG|JP

Exclude status-style names
Maintenance|Expired|Traffic remaining|Official site

Match a region marker at the start of the name
^(HK|SG|JP)[-_ ]

The expressions above illustrate the filtering approach; use names from the current subscription in practice. Filtering does not modify the servers themselves—it only changes the list view or the scope of bulk actions. If the filtered list is empty, clear the condition first and check whether the names use different abbreviations. Do not manually rename large numbers of servers just to make a filter work: the next update may regenerate the list, and manual names may no longer correspond to the source data.

Handling updates, duplicates, and stale entries

The same server may be supplied by multiple subscriptions. Do not judge duplicates by display name alone; compare the address, port, protocol, and transport parameters as well. Identical names can represent different entry points, while different names can point to the same connection details. The safest approach is to preserve source boundaries by group and avoid large-scale cross-group merging after import. For a simpler daily list, use a filtered view or pinned favorites instead of damaging the updateable subscription structure.

If a server disappears after an update, first determine whether the source removed it, a filter hid it, or it moved to another group. If no entries remain after updating, check that the subscription link is complete, the network request succeeded, and the returned content is recognizable by the client. Review the basic steps in the beginner's guide if needed. If only a few servers fail to connect, treat that as a server-configuration or network-path issue rather than repeatedly deleting and re-adding the entire subscription.

Server sorting should also have a clear purpose. Sort by name when region markers are consistent, or by group when you need to distinguish sources. Speed-test results reflect the test time and target, not every real-world workload. Before testing, make sure the system is not handling large downloads, and compare servers using the same method. A failed test does not necessarily mean the server should be deleted: ICMP, TCP probing, and real protocol connections take different paths, so a server may ignore one type of probe while still establishing normal connections.

On Android, v2rayNG and v2flyNG organize their interfaces differently from the desktop client, but the principles are the same: keep subscription sources separate, confirm the target group before updating, and check afterward that the selected configuration still exists. Mobile devices also require attention to background restrictions. An interrupted subscription update and a connection stopped in the background are two different problems. For VpnService authorization and battery-optimization exceptions, read the v2rayNG Android tips.

Separate primary, backup, and experimental sources

The goal of managing multiple subscriptions is not to collect as many as possible, but to prevent different sources from overwriting or confusing one another. At minimum, separate them into primary, backup, and experimental roles. The primary subscription handles daily connections and should change least often. The backup is used when the primary source has problems. The experimental subscription is for observing new protocols or temporary configurations and should not be mixed into the daily server list. Once roles are defined, update, filter, and delete by group.

Every subscription should have a stable name and a clear purpose. You can include a source abbreviation and role in the group name, but never record access credentials, complete links, or other sensitive data there. Keep the subscription link only in the client's subscription settings; do not copy it into screenshots, public logs, or shared configuration examples. When migrating to another device, add the subscription again on the new device instead of copying an entire data directory containing local state, historical logs, and interface preferences.

Plan updates around source stability. Refreshing manually again and again will not make a line faster and may overwrite good results when the source service is briefly unavailable. For daily use, update the primary subscription alone first and confirm that the response is normal before updating other groups. If the client supports retaining the pre-update content, enable that failure safeguard. If it does not, export local server settings without subscription credentials or record the currently working entries before important changes.

Handling duplicate names, renames, and source migration

When a provider changes its naming rules, favorites, filters, and manual notes may stop working. Re-identify servers using stable fields such as the address, port, protocol, and transport combination rather than relying only on display names. Once you confirm that the connection is the same, update the filter conditions. If an entire source moves to a new subscription link, add the new link as a new group and complete one update first. Disable the old group only after confirming that the servers work, so a rollback path remains available.

When the same connection is supplied by multiple groups, do not immediately assume they are redundant. Subscriptions may have different update schedules, parameter details, or usage scopes. Hide duplicates with name filters first, then decide whether to remove a source after several updates confirm that the content is identical. Before deleting a subscription configuration, distinguish between deleting the subscription entry and deleting already imported servers; some clients handle these separately.

Limit the group before performing bulk actions. Bulk speed tests, deletions, and edits can easily affect another source, especially while a filter is active: the visible range may not equal the actual operation scope. Confirm the current group, filter conditions, and selected count before proceeding. Bulk edits to transport parameters are generally discouraged because the path, host name, TLS, REALITY public key, and short ID in a subscription correspond to server-side settings and cannot be swapped based only on similar names.

Keep a maintainable change log

In a multi-subscription setup, a simple change log is more useful than a complicated backup. Record only the date, the module changed, the state before and after, and the validation result. For example: “Enabled region filtering for the primary group; routing unchanged; browser and desktop application connections work normally.” When something breaks, you can quickly identify the last change with a broad impact. Never store complete subscription links, server keys, or reusable authentication fields in the log.

When the server list suddenly grows or shrinks, compare each group's update time and response status before checking filters. If only one source has a problem, pause its automatic updates instead of rebuilding the entire configuration. If no source can update but existing servers still connect, the issue is more likely in the subscription request, system proxy, or DNS path. If updates succeed but every server fails simultaneously, check the local network, active outbound, and system clock.

Start with the entry, conditions, and exit

Routing rules answer three questions: which entry receives the traffic, what conditions it meets, and which exit ultimately handles it. Common conditions include domains, IPs, destination ports, network types, inbound tags, and process information. Exits generally include at least proxy, direct, and block. The client reads rules from top to bottom, and the first match determines the exit. Put specific rules first and broad fallback rules later.

Domain rules work only when the core can obtain the domain name. If an application resolves the name locally and submits only an IP to the proxy, a domain-only rule may not match. Conversely, IP rules require a resolved address or a direct IP target. domainStrategy determines whether and when the routing module supplements a domain with an IP lookup. A common approach is to use domain rules first and resolve only when IP matching is needed. If you always process by IP alone, some of the readability and control offered by domain rules is lost.

Design rules around business goals rather than piling up lists. First define local and private addresses that must go direct, then add domain groups that clearly require the proxy, followed by specific IP ranges, and finally set the default exit. Use block rules only for targets or protocol types that should not establish a connection. The more rules you have, the more important it is to keep names, comments, and order stable; otherwise, you will not know why traffic matched a particular exit.

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

domain: generally matches a specified domain and its subdomains, while full: is used for an exact domain match. The precise behavior of ordinary string rules depends on the core's format. Use an exact match for one clearly identified host and a domain-suffix match for multiple subdomains of a service. Avoid very short keywords for broad matching: a single common word may match many unrelated domains.

Expand gradually from a simple three-part setup

At the first stage, keep only three rules: “private addresses direct, explicitly listed domains through the proxy, everything else through the default exit.” After confirming the result, add business domains that should be direct or specific UDP handling. If the client provides a predefined routing scheme, copy it before editing instead of repeatedly overwriting the only version. Every rule should have a clear validation target. For example, after adding an exact-domain rule, test that domain and one control domain that should remain unaffected.

Process routing depends on the capabilities of the client, core, and operating system, so it should not be treated as a universal cross-platform foundation. Process names can also change with installation methods or child-process structures. If an application supports its own proxy settings, configure them explicitly inside the application first. Consider TUN and process conditions only when you need to handle an application that ignores proxy settings. Per-app proxying on Android is part of system VPN interception and is not the same implementation as desktop process routing.

Port rules suit scenarios with clearly defined protocols, but do not infer an application's behavior from “common ports.” Modern applications may reuse 443 or use dynamic ports, so a port alone cannot reliably identify a service. Do not block all UDP either: DNS, real-time communications, and some transports use it. If a rule lets webpages open but breaks media, voice, or login features, check whether UDP, QUIC, or related domains were handled incorrectly.

Do not judge routing only by the exit IP. A more reliable method is to combine the target, rule condition, and outbound tag shown in core logs. If the log sends the target to the wrong exit, check rule order and tags. If there is no corresponding connection record, the traffic may not have entered that inbound. If you see only an IP and no domain, continue by checking the application's resolution method, sniffing settings, or the FakeDNS path. Routing and DNS are closely connected, so continue to the next section only after routing is stable.

Determine which component resolves the domain

The first step in DNS troubleshooting is not immediately changing servers, but determining where resolution happens. A browser may use its own encrypted DNS, the operating system has a system resolver, and the client core can use an independent DNS configuration. If all three are active, the actual request may bypass the layer you just changed. Temporarily unify the path during testing: disable the browser's independent resolver or record its state explicitly, route the test domain into the client core, and then inspect query and response results in the logs.

DNS failures commonly appear as domains that will not open, direct IPs that connect successfully, or different results for the same domain in different applications. A connection timeout does not automatically mean DNS is at fault. If the domain resolved correctly but the target failed during TLS or transport, continue checking the server and routing. Conversely, receiving an address does not mean it is suitable for the current network; caches, a faulty upstream, or a split-resolution path can all send the connection to an unexpected address.

Split upstreams by purpose instead of placing multiple addresses into an unordered list. System DNS can handle LAN hosts and local-network domains. A designated regular DNS server or DoH can handle other queries. When upstream selection depends on the domain, give each server a clear domains scope. DNS queries themselves also need the correct exit: a direct upstream should be reached through the direct exit, while an upstream that requires the proxy should be sent to the proxy exit by routing rules.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "https://dns.example.com/dns-query",
        "domains": [
          "domain:example.net"
        ],
        "skipFallback": true
      },
      "localhost"
    ]
  }
}

The domains in the example only illustrate the structure; replace them with usable DNS service addresses in a real configuration. queryStrategy controls whether to query IPv4, IPv6, or both, and should match the capabilities of the current network. If the network has no stable IPv6 path but IPv6 results are preferred, an application may wait for a failed connection before falling back, making the first connection slow. Disabling one address family is not always the answer; first confirm that the system has a usable route, then choose the query strategy.

How split resolution, caching, and fallback interact

The goal of split resolution is to send different domains to suitable upstreams through the correct exits. Keep domain rules as precise as possible and avoid overlapping ranges that send the same domain to multiple upstreams. Fallback servers are for cases where the primary match returns no result or configuration allows another query; they are not random load balancers. If you configure skipFallback, confirm that the relevant domains can truly be handled only by the current upstream, or a temporary primary failure will not fall back to another server.

Caching can make a changed result appear unchanged. The core, operating system, and browser may each cache DNS results. After changing the configuration, reload or restart the core, clear system and application caches, and then use a recently unvisited subdomain as a control. Do not switch between several upstreams repeatedly in a short period while testing only one domain; it is difficult to distinguish a new result from an old cache.

DoH places DNS queries inside an HTTPS connection, which standardizes the transport, but it still needs to resolve the DoH server's domain. This creates a bootstrap-resolution problem. Common solutions are to provide a directly reachable bootstrap address for the DoH service or let the system resolver resolve that host first. If routing sends the DoH host into a loop that depends on the same DNS service, the core may wait indefinitely. Check whether the DNS server address, routing rules, and outbound tags create a recursive dependency.

For a deeper look at split resolution inside and outside mainland China, DoH, and pollution troubleshooting, read V2Ray DNS configuration explained. Base actual changes on the current network and core logs rather than mechanically copying one set of upstream addresses to every device. Desktop broadband, mobile networks, and enterprise networks impose different resolution constraints; stable solutions usually come from clear separation of responsibilities, not from adding more servers.

TUN and the system proxy solve different problems

A system proxy depends on applications actively reading proxy settings, making it suitable for browsers and most desktop software that follows the operating system proxy. TUN mode receives a broader range of IP traffic through a virtual network interface and can cover applications that ignore system proxy settings. These are not simply “standard” and “enhanced” modes; they are two different ways to intercept traffic. If you only need browser proxying, the system proxy is easier to maintain. Consider TUN when you need to handle an independent network stack, a game launcher, or command-line software.

Before enabling TUN, confirm that the regular system proxy is stable, the current server connects normally, and DNS and routing work independently. Then disable other virtual-adapter software that could conflict, and record the system's existing default route and DNS state. v2rayN may need operating-system permission to create a virtual interface, configure routes, and adjust DNS. If permission is denied, the interface switch may appear to change even though the virtual interface was never created successfully. Check both the client status and the system network interfaces.

TUN receives network-layer traffic, which the core still needs to translate and pass to routing and outbounds. Common settings include the interface address, MTU, auto-route, strict-route, and protocol-stack implementation. Auto-route directs target traffic to the virtual interface; strict-route reduces bypass paths but can also affect LANs, containers, and virtual machines. Keep the defaults for the first activation and change them only when a specific compatibility issue is confirmed.

Handling LANs, virtual machines, and containers

LAN addresses should normally go direct and should appear before broad proxy rules. Otherwise, printers, router administration pages, file shares, and local development services may be sent to the proxy exit. Common private ranges can be handled with the core's geoip:private rule, but also watch for special ranges, virtual-machine bridge networks, and container networks used locally. Enterprise networks may use additional internal addresses and domains; add them according to the actual environment.

A virtual machine using NAT, bridged, or host-only networking has different traffic entry points and source addresses. The host's TUN does not necessarily intercept all traffic from a bridged virtual machine, and container traffic should not be assumed to follow the same path as desktop applications. Test on the host first, then test DNS, the default route, and the exit inside the virtual environment. If the failure occurs only there, check that environment's own network configuration instead of immediately expanding host routing rules.

When the MTU is unsuitable, small pages may open while large files, images, or TLS handshakes stall at a particular stage. Do not lower the MTU as soon as a connection feels slow. First confirm whether the issue occurs only with TUN or only on a particular network, then adjust gradually with small changes. Afterward, test webpages, downloads, and UDP applications rather than checking only one site.

Windows: inspect interfaces and routes
ipconfig /all
route print

macOS: inspect interfaces and the default route
ifconfig
route -n get default

Linux: inspect addresses and routes
ip address
ip route

These commands observe system state; they do not directly repair the configuration. Confirm that the virtual interface exists, the default route is as expected, LAN routes remain reachable, and related entries disappear or recover after TUN is disabled. Do not manually delete the entire routing table without understanding its purpose. If the network is still broken after the client stops, fully exit the client, reconnect to the current network, and then check for leftover interfaces and DNS settings.

Prevent traffic loops and proxy-process interception

The most important TUN boundaries are the proxy process itself and the connection to the server. If traffic used to reach the proxy server enters TUN again and is routed back to the same proxy outbound, a loop forms. Mature clients usually bypass server addresses, processes, or interfaces automatically, but custom rules can break that protection. If the connection drops immediately after startup, logs repeat connections to the same target, or traffic grows rapidly, check for a loop first.

DNS can form a similar loop: TUN sends DNS requests into the core, while the core needs to access a DoH server whose name depends on the unresolved DNS path. Define the bootstrap resolution, DNS exit, and TUN exclusions explicitly. Do not enable several system-level VPN or transparent interception tools to “improve compatibility”; they compete for the default route, DNS, and virtual interfaces, producing unstable results.

VpnService on Android also provides system-level interception, but its operation, permission model, and desktop TUN behavior are not identical. The first connection in v2rayNG or v2flyNG requires system authorization, and per-app proxying can be configured when needed. If the connection stops frequently in the background, check battery restrictions instead of changing desktop TUN parameters.

Why assign virtual addresses to domains

Some applications resolve domains themselves and then pass only the destination IP to the system network. Once the traffic enters TUN, the core sees an IP and the original domain is gone, making domain-based routing difficult to match. FakeDNS returns a virtual address for the query while storing a mapping between that address and the original domain. When the application connects to the virtual address, TUN captures the traffic, allowing the core to restore the original domain and apply domain-based routing.

FakeDNS is therefore neither a replacement for ordinary public DNS nor a performance switch that works by itself. The complete path includes at least: the application's query enters the core DNS, FakeDNS returns a virtual address, the application starts a connection, the connection enters a controlled inbound, the core recognizes the virtual address and restores the domain, routing selects the actual outbound, and the outbound performs real resolution or establishes the connection. If any step bypasses the client, the virtual address cannot be restored or domain rules will fail.

TUN and regular DNS must each be stable before FakeDNS is enabled. Then choose a virtual address pool that does not conflict with LANs, virtual machines, containers, or enterprise networks. The pool is used only for local mappings and should never be sent onto the real network. If routing mistakenly sends virtual addresses direct, applications will keep timing out. The pool must cover the number of active domains, but there is no reason to expand it blindly into ranges that overlap the existing network.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns",
      "localhost"
    ]
  }
}

198.18.0.0/15 is commonly used for benchmarking networks and can serve as an example virtual address pool, but still check whether the range is already in use. Configuration fields vary with the core's configuration method, so use the structure generated by the client as your basis instead of inserting fragments into an incompatible configuration. FakeDNS also depends on DNS server order: not every domain needs a virtual address. Local domains, LAN hosts, and applications that explicitly require real IPs can keep ordinary resolution.

Identify virtual-address leaks and mapping failures

If an application receives a virtual address but the connection does not enter TUN and is sent directly over the physical network, a virtual-address leak has occurred. The domain may appear to resolve successfully while the connection continually times out, with no corresponding request in the core logs. Do not keep changing upstream DNS. Check whether the application is covered by TUN, whether per-app rules exclude it, whether auto-route is working, and whether another route takes precedence over the virtual address range.

Mappings can fail after a core restart, retained caches, or reuse of an address pool. The application may still have an old virtual address while the new core no longer has its mapping, so the domain cannot be restored. Reload the configuration and clear application and system DNS caches so the application queries again. If the issue appears only after long runtimes, also check pool capacity, cache lifetime, and whether there are many short-lived domain requests.

Some applications validate returned addresses, use built-in DNS, connect directly to fixed IPs, or establish an encrypted resolution path internally. Such traffic may not suit FakeDNS. When one application misbehaves, remove it from the FakeDNS test scope, use real resolution, and handle it with IP or process rules. Do not force every domain onto a more complicated path for the sake of one exceptional application.

Whether FakeDNS is worth enabling depends on whether you truly need to preserve domains in a TUN environment. When a regular system proxy can already pass domain names through, enabling it usually adds little benefit. After configuration, test LAN hosts, common webpages, long-lived connections, and wake-from-sleep recovery to ensure virtual mappings do not interfere with real local resolution. Stability matters more than feature count.

Start with direct, block, and local proxy exits

Custom outbounds describe how traffic leaves the core. The basic setup usually includes proxy, direct, and block outbounds. The proxy outbound generated from a subscription is maintained by the client; local rules only need to reference it by tag. New outbounds must have unique, meaningful tags and should not conflict with tags generated automatically by the client. Names such as direct, block, and local-socks describe responsibilities clearly; avoid tags like “line one” or “temporary two” that become hard to understand over time.

A direct outbound passes traffic to the local network and remains subject to system routing and DNS capabilities. A block outbound explicitly rejects matching traffic. A local SOCKS outbound can pass traffic to another proxy service running on the same machine or on a trusted LAN. Chained custom exits add failure points and should be used only when the upstream role is clear and can be tested independently. If a regular subscription server already meets the need, there is no reason to add multiple forwarding layers.

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    },
    {
      "protocol": "socks",
      "tag": "local-socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    }
  ]
}

The local port in the example works only when another SOCKS service is actually listening on 127.0.0.1:1081. After adding it, check the listening port first, then create a routing rule that matches only a test domain and sends it to local-socks. If you switch all default traffic to it immediately, every connection will fail when the upstream is not running, making it difficult to tell whether the problem is the rule or the upstream.

Understand DNS and loops in outbound chains

When a custom outbound accesses a domain, resolution is still required. Determine whether it is performed by the local system, the core DNS, or the upstream proxy. If you want the upstream proxy to resolve the domain, preserve the domain form and use a connection method that supports remote resolution. If the core resolves it first, routing and DNS policy affect the resulting address. Document this distinction in the configuration so you can avoid “the route matched the correct tag, but the connection used the wrong address.”

Local chained proxies are especially prone to loops. For example, v2rayN may point an outbound to local port 1081 while the same configuration's inbound occupies 1081, or traffic from the upstream application may be captured by TUN and sent back to the current outbound. During troubleshooting, inspect the process that owns the port, the inbound listening address, and the TUN bypass scope. One port can have only one stable listener, and inbound and outbound targets must not form a closed loop.

The protocol, transport, TLS, and REALITY parameters for a server outbound must come from the actual server configuration or subscription content. Do not construct parameters based only on the protocol name. VLESS, VMess, and Trojan organize authentication and transport differently, while WebSocket, gRPC, and TCP transports may carry paths, service names, or host information. For the relationship between REALITY and XTLS Vision, see REALITY and XTLS Vision explained; configuration values must still match the server side field by field.

Locate faults along the “entry—resolution—routing—exit” path

Systematic troubleshooting should always follow the direction of traffic. First check the entry: does the application read the system proxy, or has the traffic entered TUN? Second check resolution: does the log retain the domain, and did DNS return a usable result? Third check routing: which rule and outbound tag matched? Fourth check the exit: can the upstream address, port, protocol, and transport establish a connection? Do not start at the final step by repeatedly changing servers; if the entry is not intercepting traffic, changing servers will not change the symptom.

If the core cannot start, restore the most recent working configuration first, then check JSON syntax, tag references, port conflicts, and permissions. If it starts but records no connections, focus on the system proxy, TUN, and application settings. If connections appear but rules are wrong, temporarily reduce routing to the three-part setup. If routing is correct but DNS fails, switch to a simple upstream and disable FakeDNS. If resolution and routing are correct but the outbound fails, verify the server configuration, system clock, and local network.

After troubleshooting, restore temporary log levels, test rules, and test outbounds to the daily configuration. Keep one baseline, one current setup, and a short change log; there is no need to accumulate many nearly identical configuration copies. When you need to choose another client or install the version for a particular platform, visit the client download page. Use v2rayN on desktop platforms, and choose v2rayNG or v2flyNG on Android according to the core you need.