V2Ray Advanced Configuration Guide

Why establish a configuration baseline

The actual connection result in v2rayN depends on several layers working together: subscriptions provide server details, the client selects the active server, routing determines which outbound receives traffic, DNS controls how domains are resolved, and the system proxy or TUN determines which application traffic enters the core. A change at any layer can appear as a website failing to load, only some applications working, or different results after switching servers. If routing, DNS, and traffic capture are changed at the same time, it becomes difficult to identify the cause.

Start with a minimal working baseline: keep one confirmed-working subscription group, select a fully configured server, use the client’s basic built-in routing mode, leave DNS at its default, and begin with the system proxy. Visit a few everyday websites and check the v2rayN log for connection establishment, domain resolution, and outbound selection. The goal is not a sophisticated setup, but a complete working path between the client, core, server, and local network.

Record configuration relationships rather than transient test values. Note the active group, server alias, system proxy state, routing mode, whether DNS is handled by the client, whether TUN is disabled, and the approximate time of the last successful connection in the log. Do not copy server addresses or credentials into public notes. For migration, use the client’s configuration export feature and store the file in a controlled location.

Change one variable at a time

Work from the baseline and change only one configuration area per round. For example, finish subscription grouping and filtering first, verify that updates and selection work, then move to routing rules. Adjust DNS only after routing is stable, and enable TUN or FakeDNS last. After each round, verify at least three things: the client log shows no persistent errors, the expected application can connect, and traffic that should not be captured still follows its original path. If a change fails, you can undo the latest step instead of resetting the entire setup.

Temporarily raise the log level to info while troubleshooting, and use a more detailed level only when you need to inspect routing matches. Keeping verbose logs enabled permanently makes them harder to read and can bury useful errors under connection records. Restore your normal level after testing and remove temporary rules created for diagnosis. The first error in the log is usually more useful than repeated follow-up errors, which are often downstream effects.

Create a reversible working copy

Before making major changes, export the current configuration in v2rayN or copy the existing routing set, then give the copy a descriptive name such as “Office base routing” or “Test-TUN-DNS.” Name it for its use case rather than “New configuration” or “Config 2.” If the client supports multiple routing sets, keep one untouched baseline set. Updating a subscription is not a substitute for this backup: subscriptions mainly store server entries and may not include local routing, DNS, system proxy, or custom outbound settings.

When validating a configuration, distinguish between the client not capturing traffic and traffic entering the client but failing on its outbound path. For the former, check the system proxy, TUN, and the application’s own proxy settings. For the latter, check the server, routing, DNS, and outbound chain. The quickest approach is to look for the target domain or connection in the log. If there is no related record at all, start at the capture layer; if it appears and is followed by a resolution or connection error, continue with DNS and outbound checks. For other common symptoms, consult the Help Center so application issues are not mistaken for core issues.

Group by source, not by temporary status

v2rayN can store manually added servers alongside multiple subscriptions. A reliable structure is one group per subscription, with manual configurations kept in a separate group such as “Self-managed nodes.” Updating one source then will not accidentally remove entries from another, and you can quickly tell whether a server field came from a subscription or was entered locally. If the same provider offers subscription URLs for different purposes, name them separately and include the purpose instead of guessing the source from server aliases after an update.

Keep group names short and specific, such as “Work subscription,” “Mobile backup,” or “Self-managed nodes.” Do not put an expiry date, a one-time latency result, or the current active server in the group name; those details change too often. Subscription notes should state the source and intended scope, while the client can track update times. If you need the same server sources across devices, see Three ways to sync V2Ray configurations across computers and phones; subscription syncing and transferring individual nodes are different use cases.

Understand the difference between updating, cleaning up, and merging

When you update a subscription, the client refreshes the corresponding group from the returned content. Whether old entries remain depends on the client settings and update method, so confirm the selected group first. If a subscription removes a server but an old record remains locally, a retention option may be enabled, or an identically named entry may belong to another group. Do not delete all same-named servers immediately. Show the group column or switch to a group view first to confirm each entry’s actual source.

“Clean up old servers” is useful after major changes to subscription content, but it can remove notes you edited manually in that group. If those local changes matter, copy the required entries to a manual group before refreshing the subscription. Merging several subscriptions may reduce the number of groups, but it removes source boundaries: when an update fails, it is harder to identify the affected subscription, and duplicate names are more likely to overwrite one another. Unless the provider already offers a unified subscription, keeping independent groups is usually safer.

Use filter expressions to narrow the list

Server filtering is mainly for cases where there are many entries but only a small set is used regularly. Common approaches include keeping aliases with certain keywords, filtering by protocol name, excluding keywords, or combining conditions. Filtering changes the displayed list or candidate set; it does not repair server settings or alter the original subscription. Before creating filters, check that server naming is stable. If aliases change format on every update, name-based rules must be maintained too.

Filters usually support plain keywords or regular expressions. Plain keywords are easier to maintain and work well with simple naming schemes; regular expressions are useful for matching several fixed terms, but require attention to escaping and case sensitivity. The expressions below keep entries containing “Office” or “Backup” and exclude entries containing “Test.” The exact input location depends on the client’s server-filter settings.

Keep expression:
Office|Backup

Exclude expression:
Test

If you use regular expressions, start with a simple combination rather than writing a long one-line pattern immediately. For names such as “Office-Shanghai-VLESS” and “Backup-Tokyo-Trojan,” use ^(Office|Backup)- to match the fixed prefix. Escape regex metacharacters such as parentheses, plus signs, and periods when they appear in names. If the filtered result is empty, first clear the exclusion condition temporarily instead of reimporting the subscription. Once the entries return, add conditions back one at a time to find the overmatching rule.

Understand top-to-bottom rule matching first

After a connection enters the Xray or V2Fly core, the routing module looks for matching rules based on domains, destination IPs, ports, network type, inbound tags, process information, and other conditions. Normally, the first matching rule determines the outbound, and later rules are not evaluated. Put specific exceptions first and broad catch-all rules later. For example, if one domain must use the proxy while its broader domain category is normally direct, place the specific domain rule before the category rule.

Common outbound tags include proxy, direct, and block; the actual names depend on the configuration generated by the client. Custom rules must use outbound tags that really exist in the current configuration. A spelling mismatch prevents the rule from reaching the intended outbound. The GUI labels “Proxy,” “Direct,” and “Block” are usually converted into these tags; when importing complete JSON, keep the routing rules aligned with the tag values in the outbounds array.

The roles of domain and IP rules

Domain rules work while a connection still carries domain information, making them suitable for full domains, subdomain suffixes, or built-in domain categories. IP rules apply when the target has already been resolved to an address or when you need to handle LAN and reserved ranges. With domain sniffing enabled, some connections that initially contain only an IP may regain domain information and participate in domain routing. Sniffing is not guaranteed to recover domains for every protocol or application, so critical rules should not depend on a single path.

domain:example.com typically matches the domain and its subdomains, while full:api.example.com matches only the complete name and regexp: applies a regular expression. When a full domain or suffix is sufficient, there is no need for regex. IP rules can use CIDR notation; for example, 192.168.0.0/16 represents a LAN address range. Example domains illustrate syntax only; replace them with the business domains you actually need to control.

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

domainStrategy determines when routing resolves a domain to an IP. AsIs keeps the domain whenever possible and does not proactively resolve it for IP rules; IPIfNonMatch resolves it when no domain rule matches and then tries IP rules; IPOnDemand resolves it earlier when a rule may require an IP. Start with the client default. Do not switch to a more aggressive strategy merely because it looks more complete: it changes when DNS requests appear and can make troubleshooting harder.

Validate the order with a small rule set

When creating a routing set, start with three categories: a few domains that must use the proxy, LAN addresses that should go direct, and a final default outbound. Save and apply it, visit a matching domain in a browser, and confirm the matched outbound tag in the log. Add domain categories, ports, or process rules only after that works. Importing hundreds of custom rules at the start makes it easy for a broad condition to catch an exception and harder to tell whether built-in data matches the current core.

Interpret port rules together with network type. For example, specifying only 53 may affect both TCP and UDP DNS traffic; if you need to control UDP only, specify the network condition as well. Process rules depend on the client, operating-system permissions, and capture method, so capabilities differ by platform. They are useful for a small number of application exceptions, but should not replace domain and IP rules as the main traffic-splitting method. Application updates can change executable names and invalidate older process rules.

A website may use several resource domains, so routing only its main domain can leave the page visible while images or APIs fail. Find the failed resource domain in developer tools or the client log, then add the relevant suffix instead of sending all traffic through the proxy. For questions about choosing between VMess, VLESS, Trojan, and Shadowsocks, read A side-by-side comparison of proxy protocols. The protocol determines how a connection is established; routing determines which outbound receives it. They are separate settings.

Separate system DNS from core DNS

System DNS is the resolution path used by the operating system and ordinary applications by default. Core DNS is the DNS module configured in Xray or V2Fly, mainly serving connections entering the client, routing decisions, and domain-specific policies. With the system proxy enabled, some applications may resolve locally and pass the resulting IP to the proxy, while others may send the domain through the proxy. With TUN enabled, DNS requests may also be intercepted by the core. If you do not first identify where the query originates, changing core DNS may have no effect on the actual problem.

During troubleshooting, check whether the log contains a resolution record for the target domain. If the browser has already resolved the domain to an IP and sniffing did not restore it, routing can see only the address and domain rules may not match. Conversely, if the core receives the domain and resolves it, inspect the selected DNS server, query type, returned address, and subsequent route. Do not attribute every resolution failure to the server; spelling, system cache, app-provided secure DNS, routing blocks, and incomplete UDP capture can produce similar symptoms.

Give each DNS server a clear role

An easy-to-maintain setup usually contains only a few DNS servers with clearly defined scopes. A default server handles ordinary queries, a designated server handles specific domains, and a fallback is added only when necessary. Addresses may use traditional UDP DNS or HTTPS-based queries, depending on the current core and client configuration. Prefer services that work reliably with your existing routes rather than stacking several addresses with the same role.

When a DNS server is specified by domain name, startup depends on resolving that server name first. Common solutions are a host mapping, a directly reachable address, or a bootstrap DNS used to resolve the server name. If custom outbounds are present, confirm whether DNS queries go direct or through a proxy. The query path and the target domain’s traffic path may differ, but that difference should be intentional.

{
  "dns": {
    "hosts": {
      "router.local": "192.168.1.1"
    },
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": [
          "domain:example.com"
        ],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

In the example, hosts provides fixed local domain mappings; the server with domains handles only its matching scope; the final entry serves as the ordinary query path. skipFallback prevents queries matching that server from entering fallback evaluation, which is useful when the result source must be predictable. The example address dns.example shows structure only and must be replaced with a usable service. If split-domain resolution is unnecessary, use a simple server list; shorter configurations are easier to troubleshoot.

Understand query types and caching

queryStrategy controls whether queries request IPv4, IPv6, or both. If the network has no usable IPv6 path, resolving an IPv6 address and then failing to connect may cause a delay before fallback. In that case, choose IPv4-only queries based on actual network capability instead of excluding IPv6 throughout the routing rules. If both the system and outbound path have stable IPv6, keeping dual-stack behavior is more appropriate. Reconnect after changing the setting and clear the application’s own cache so old results do not distort the test.

DNS caching reduces repeated queries, but it also means configuration changes may not produce new results immediately. Restarting the v2rayN core usually clears core-side state, while browsers and operating systems may retain their own caches. Test with a previously unused subdomain or wait for the cache to expire. Do not repeatedly refresh one long-open page as your only test: the browser may reuse a connection or resolution result, or a background service may handle the request.

System proxy and TUN capture scope

The system proxy works well for browsers and desktop applications that follow the operating system’s proxy settings. It is simple to configure and easy to disable, but some programs ignore it, and UDP support depends on the application. TUN mode receives a broader range of IP traffic through a virtual network interface, making it useful for command-line tools, applications with independent network stacks, or environments that need consistent TCP and UDP handling. Once capture scope expands, interactions with LAN access, development tools, virtual machines, and other network utilities become more complex.

Before enabling TUN, confirm that the same server works under system-proxy mode and that routing correctly separates proxy, direct, and blocked traffic. Otherwise, TUN only spreads existing configuration errors to more applications. For the first test, disable other software that creates virtual adapters or changes the default route, record the local LAN range and default gateway, and enable a basic TUN configuration in v2rayN. Restore other network components one at a time and watch for route conflicts.

Understand the virtual interface, routes, and strict mode

After TUN starts, the client creates a virtual interface and uses system routes to direct target traffic into it. Auto-route adds the required routes, while strict routing reduces opportunities for traffic to bypass the virtual interface. Strict mode helps keep the path consistent but may affect LAN discovery, container networks, or special virtual adapters. If printers, router admin pages, or development devices become unreachable, first add direct rules for LAN addresses, then decide whether strictness should be reduced.

MTU is the packet size the virtual interface can carry. A value that is too large may cause fragmentation or packet loss on some paths; a value that is too small increases packet count and overhead. Without clear evidence, use the client default. Typical MTU problems allow a connection to start but cause a particular page to stall, uploads to fail, or some protocols to behave abnormally. Lower the value gradually and repeat the same test, changing only one step at a time while confirming that the issue is not caused by the server or DNS.

Diagnose TUN startup issues by symptom

If TUN cannot create an interface, first check the log for permission errors, an interface-name conflict, or a driver component issue. On Windows, the client may need to be started with the required privileges; on macOS and Linux, confirm that the system allows the client to create a virtual interface. Do not repeatedly switch servers when the log clearly indicates insufficient permissions, since the server does not control interface creation. Before reinstalling, confirm that you are using the correct platform version from the download page.

If TUN starts but every connection fails, check whether the default route points to the virtual interface, whether the core receives traffic, whether DNS works, and whether the proxy outbound is being sent back into TUN and creating a loop. Clients generally include exclusions or safeguards for their own connections; custom launch methods, external cores, or complex routes can break them. If the log shows repeated connections or targets pointing to the local virtual address, investigate a loop before adding more routes.

If only LAN access fails, check whether geoip:private or explicit private ranges are routed direct, and confirm that LAN-sharing settings have not changed the listening scope. Common private ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Corporate or lab networks may use additional ranges, which should be added based on the actual network. Local services addressed by hostname also depend on local DNS; an IP-only direct rule is not enough.

If the network does not recover immediately after disabling TUN, stop the core normally from the client, then check whether the virtual interface and default system route have been removed, and reconnect to the current network. Force-quitting the process may skip cleanup and should not be the normal way to shut down. If the issue persists, use the Help Center and follow the “client exited but the network is abnormal” path to check the system proxy, virtual interface, and DNS instead of only restarting the browser.

How FakeDNS works

A normal DNS query returns the target server’s real address, and the application then connects to that address. If a connection enters the core with only an IP, domain routing may need sniffing to recover the original name. FakeDNS instead returns a virtual address from a dedicated pool and stores a domain-to-address mapping inside the core. When the application connects to that virtual address, the core uses the mapping to recover the domain, then performs domain routing and actual resolution. Its main value is preserving domain context, not improving server performance.

FakeDNS is commonly used with TUN because TUN can receive connections to virtual addresses and return them to the core. If FakeDNS is enabled without correctly intercepting DNS requests, the application may still obtain a real address through another resolver. If DNS is intercepted but virtual-address traffic does not enter the core, resolution succeeds but the connection fails. The DNS entry point, FakeDNS address pool, TUN routes, and core mapping must therefore form a complete loop.

Address pool and mapping capacity

Choose a FakeDNS address pool that will not conflict with the local LAN, corporate network, container network, or other virtual interfaces. Client defaults usually account for common cases, so do not change them without a clear conflict. Typical symptoms include a real internal network becoming unreachable after activation or the system sending virtual addresses to the wrong interface. Check the system routing table and compare the FakeDNS pool with existing network ranges.

Mapping capacity determines how many domain records can be retained at once. If it is too small, older mappings may be replaced frequently, causing inconsistency on pages that load many domains; if it is too large, there is usually little benefit. The client default is normally sufficient. If an application reuses old DNS results for a long time, it may continue connecting to an invalid virtual address even after the core mapping is cleared. Restart both the application’s connections and the core instead of repeatedly refreshing the page.

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "1.1.1.1"
    ],
    "fakedns": [
      {
        "ipPool": "198.18.0.0/15",
        "poolSize": 65535
      }
    ]
  }
}

The example shows a common FakeDNS structure: a selected domain category uses virtual resolution while other queries go to ordinary DNS. 198.18.0.0/15 is often used for this type of mapping, but suitability still depends on the local network. Different core formats may place fakedns at different levels, and v2rayN may generate related fields through its interface. Do not paste the fragment over the entire configuration; compare it with the current structure exported by the client first.

When not to enable it first

Office systems that depend on local DNS for internal addresses, LAN device names, or split-DNS environments require care with FakeDNS. These domains should generally use local DNS and go direct rather than receive virtual addresses. Use domain rules, suffixes, or local hosts mappings to bypass FakeDNS. If internal domains have no stable suffix, collect actual query records first and build an explicit list instead of using a broad exclusion.

Some applications validate DNS-returned addresses, use their own DNS, cache for a long time, or compare the target address again during connection setup. Their interaction with FakeDNS may be unreliable. When one application misbehaves, route its related domains through ordinary resolution before disabling the entire TUN setup. If the problem cannot be isolated by domain scope, return to the baseline without FakeDNS and confirm whether virtual mapping is actually responsible.

FakeDNS and domain sniffing can complement each other, but enabling both indiscriminately is unnecessary. FakeDNS preserves mappings for controlled DNS queries, while sniffing handles connections that bypass the mapping but expose a domain in their protocol. When enabling sniffing, watch the target override setting: replacing the original target with the sniffed domain can change routing. Let FakeDNS handle the main TUN traffic first, then use the log to decide whether IP-only connections still require sniffing.

Use logs to verify the mapping path

For testing, choose a domain that has not been cached. Check that FakeDNS returns a virtual address, then verify that the following connection record shows the original domain. Confirm the outbound tag selected by routing and check whether the connection succeeds. If there is a DNS record but no subsequent connection, the virtual address may not be captured by TUN or the application may not have started the connection yet. If a connection appears but the domain cannot be recovered, check whether the mapping was cleared or the request came from a different core instance.

Define a purpose and priority for each subscription

Multiple subscriptions do not mean every server should be placed in one candidate pool. A more controllable approach is to define a purpose for each subscription—daily primary use, work backup, a specific device, or testing—and create separate groups. Make everyday selections within the relevant group, switching groups only when changing sources. This avoids confusion between identically named servers and reduces unexpected changes caused by automatic selection across sources.

Subscription names should contain stable information, not server counts or update times. Use a format such as “Purpose—Source” and note the intended devices, whether automatic updates are allowed, and whether special routing parameters are included. If a subscription URL contains an access token, keep it only in the client’s subscription settings; do not copy it into screenshots, public logs, or shared documents. To transfer it to another device you own, use a controlled method and remove the old configuration from devices that no longer need it.

Stagger updates and preserve failure context

Updating every subscription at once may save a step, but a failed source can make the log difficult to read. During initial setup or troubleshooting, update them one by one: select a group, run the update, confirm that the returned content parses correctly, then continue. Once stable, scheduled updates are fine, but the interval should not be too short. Subscription content rarely changes minute by minute; overly frequent updates only increase requests and list rebuilds.

When an update fails, keep the current group instead of deleting and re-adding it immediately. Determine whether the failure is a network connection issue, an invalid URL, an invalid response format, or empty content. If the URL is reachable but parsing fails, the subscription format may not match what the client expects. If the update fails only through the current active proxy, temporarily change the outbound path used for subscription updates. Subscription updates and ordinary web traffic may use different settings, so confirm in the log whether the request went direct or through a proxy.

When an update returns empty content, the client’s retention policy matters. The safer approach is to prevent an empty response from overwriting existing servers until the source is confirmed to be working again. If the client has already cleared the group, restore it from a configuration backup instead of rebuilding every server from memory. After a successful update, spot-check the protocol, address, port, transport, and security fields. Seeing a server name does not mean every field is usable.

Handle duplicate entries and name conflicts

Different subscriptions may contain the same server, and their aliases may be identical. Deduplicating by name alone can delete entries with different settings; deduplicating by address and port alone can miss differences in protocol or user identity. Unless the relationship between sources is clear, avoid automatic cross-group merging. If the list contains too many duplicates, use group views to hide them without damaging the original subscription structure.

If you truly need a unified candidate set, keep the original groups and create a curated manual group containing only a few frequently used entries. A curated group does not inherit subscription updates, so review it manually after upstream changes. It works for a small, stable set of servers, not as a mirror of every subscription. When server fields change, copied entries are not corrected automatically—an often-overlooked maintenance cost of manual groups.

The boundary between automatic and manual selection

Limit automatic selection to candidates with consistent configurations and the same purpose. If servers with different protocols, purposes, and sources share one automatic pool, a selection change can alter both connectivity and routing behavior. During advanced configuration, fix the server manually first; enable automatic selection only after DNS, routing, and TUN have been verified. This removes “the active server just changed” as a variable when troubleshooting.

Do not treat a single latency test as a permanent ranking. Network paths and connection conditions change, and a server that responds quickly to a test may not suit every workload. Consider stability, complete protocol fields, target-application behavior, and whether switching requires existing connections to be rebuilt. For an overview of the v2rayN interface, groups, server list, and log location, read A quick tour of the v2rayN main interface.

An outbound consists of a protocol, settings, and a tag

Every outbound in the core contains at least a protocol type, protocol settings, and a tag used by routing references. v2rayN generates the primary proxy outbound from the selected server and usually creates direct and block outbounds as well. A custom outbound can connect to an existing local SOCKS service, provide special direct behavior, or serve as one link in a chained connection. Whatever the use, tags must be unique and stable because routing rules, DNS servers, and other outbounds may reference them.

Before adding a custom outbound, map the traffic path: which inbound receives traffic, which route matches, where the custom outbound connects, and whether that outbound itself must pass through another proxy. If the path cannot be explained in one or two sentences, the configuration is probably too complex. Chained outbounds add failure points; unavailable DNS, authentication, listen addresses, or network access at any link can cause the final connection to fail. Validate each segment instead of looking only at the end of the chain.

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

This example defines the local SOCKS service at 127.0.0.1:1081 as local-socks while retaining direct and block outbounds. Before using it, confirm that the port is actually listening and will not send traffic back into v2rayN’s current inbound, which could create a loop. The example contains no authentication fields; if the local service requires authentication, add the structure supported by the core and never expose real credentials in public documents or screenshots.

Use routing to send limited targets through a custom outbound

After creating the outbound, do not make it the global default immediately. Start with a rule matching only a test domain and set outboundTag to the new tag. Confirm the match in the log, then check whether the local SOCKS service receives the connection. Expand the scope gradually after it works. If the rule does not match, inspect its conditions or order; if it matches but the local service sees no connection, check the outbound address, port, and loop; if the service receives the connection but the final request fails, troubleshoot the next link.

{
  "type": "field",
  "domain": [
    "full:test.example.com"
  ],
  "outboundTag": "local-socks"
}

When an outbound tag is renamed, update every reference to it. Commonly missed locations include routing rules, the DNS server’s outboundTag, proxySettings in proxy chains, and custom templates saved by the client interface. If the core reports “tag not found” at startup, search the entire generated configuration rather than checking only the outbounds array. If the client regenerates the configuration on every launch, direct edits to a temporary JSON file may disappear the next time settings are applied; use the client’s supported custom-configuration entry point instead.

How to validate the configuration file

Before saving, check JSON syntax: object and array brackets must be paired, no trailing comma may follow the final member, and strings must use double quotes. Valid syntax only means the file can be parsed; confirm that the current core supports the fields as well. After startup, inspect the beginning of the log for the configuration load result. If the core exits immediately, the first error usually identifies a field path or tag name. Reload after fixing one error; later errors may have been hidden by the first.

Once the configuration starts, validate it in this order: inbound → routing → outbound → target. Confirm that the test connection enters the expected inbound, that routing selects the target tag, that the outbound is established, and finally that the application behaves correctly. For DNS-related outbounds, separately confirm that resolution requests use the intended tag. Do not rely only on whether a browser page opens; caching, connection reuse, and application fallback can conceal configuration problems.

Control long-term maintenance costs

A durable advanced configuration should answer three questions: why each custom rule exists, which group or outbound it depends on, and how to roll it back if it fails. Record purposes in rule names or local notes, but not sensitive connection details. Periodically review unused subscriptions, duplicate servers, obsolete filter terms, expired domain exceptions, and outbound tags with no references. Disable an item and observe before deleting it permanently, ensuring that no hidden dependency remains.

After updating the client or core, do not immediately retune every old setting. First verify basic connectivity with the existing configuration, then review new or changed options in the interface, especially TUN, DNS, routing data, and configuration generation. If something breaks, restore layers using the baseline created at the beginning of this guide. v2rayN is the preferred desktop client; on Android, choose v2rayNG or v2flyNG according to core requirements. Platform entries and details for all three clients are collected on the client download page.

When an issue occurs on only one device, compare the capture method, system DNS, LAN ranges, and application proxy behavior instead of assuming the subscription differs. Importing the same subscription on multiple devices keeps the server source roughly consistent, but does not synchronize local routing, TUN permissions, system proxy settings, or DNS caches. Listing these device-side variables and comparing them one by one is usually more effective than repeatedly importing the subscription.

The goal of advanced configuration is not to make the file longer, but to make the traffic path fit the actual need. Prefer client presets whenever they solve the problem; add a targeted rule only when logs and tests show that the preset is insufficient. Keep changes small, tag meanings clear, and validation steps consistent so that changes in subscriptions, network conditions, or usage scenarios still leave the affected layer easy to identify.