Advanced v2rayN Configuration Guide: Subscriptions, Routing, DNS, and TUN

Configuration model and reversible change strategy

Start by separating four configuration layers

v2rayN's interface settings are ultimately combined into the core's runtime configuration. Before troubleshooting, separate the four layers: servers, subscriptions, client behavior, and core configuration. Server records contain the address, port, user ID, transport, and security parameters; subscriptions provide and update server records in batches; client behavior covers the system proxy, tray actions, automatic updates, and interface filters; the core handles inbound listeners, DNS, routing, and outbounds. A node passing a latency test does not prove that the system proxy, DNS, or routing is correct, because those steps sit outside the node connection itself.

In the graphical interface, the “current server” is usually just the source for the default proxy outbound. Routing rules may send some requests through direct or block outbounds, while TUN may capture programs that do not read the system proxy. Therefore, when checking whether a setting works, do not look only for a node color change or a different tray icon. Confirm the client state, proxy mode, target program's connection method, and rule-match result together.

Establish a minimal working baseline

Before making advanced changes, establish a repeatable baseline: keep one known-working server, simplify the routing rules, temporarily disable TUN and FakeDNS, enable only the system proxy, and use a browser to open a regular HTTPS page. Once this works, add settings one layer at a time in the order “subscription filtering, routing, DNS, TUN, FakeDNS.” Change only one layer at a time and retest immediately to sharply reduce the search space.

For each experiment, record four things: what changed, the previous value, the expected result, and the actual result. No special tool is needed; a local text file is enough. If the connection fails, first undo the latest change instead of switching nodes, changing DNS, reinstalling the client, and resetting the network all at once. Multiple simultaneous actions destroy reproducibility and make the real cause impossible to identify.

Understand the boundary between generated and hand-written configuration

v2rayN is well suited to maintaining common parameters through its interface, and interface-generated configuration is easier to update automatically when switching servers. Hand-written JSON is useful for additional outbounds, specialized DNS policies, or fine-grained routing, but you must consider whether regeneration by the client will overwrite your edits. If a capability is available through routing settings, DNS settings, or a custom configuration entry point, use that entry point instead of editing temporary runtime files directly.

Configuration snippets must remain valid JSON: use straight double quotes for property names and strings, separate array items with commas, and do not add a comma after the last item. Domains, paths, and regular expressions may also require backslash escaping. If the core exits immediately after saving, check the earliest parse error in the log first; later connection failures are often just consequences of that initial error.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Choose the troubleshooting entry point from the symptom

If the browser works but another program does not, first check whether that program reads the system proxy, then consider TUN. If a domain fails while a direct request to the target address responds, check DNS first. If only some websites fail, inspect rule order and domain matching. If nodes disappear after a subscription update, check the filter expression and group. If local network names fail after enabling FakeDNS, check the exclusions and the DNS interception boundary. Choosing the entry point from the symptom is more reliable than resetting everything.

After creating a stable configuration, keep an exported configuration or interface screenshot and note the mode in use. A configuration backup stores local settings; it is not the subscription service itself. If the subscription URL stops working, the backup cannot generate new server records. Treat subscription URLs, server credentials, and custom configuration files as sensitive information: do not place them in public documents or share unredacted runtime logs publicly.

Subscription groups and server filtering

Groups solve a management problem

Subscription groups separate servers by source, purpose, and update cadence; they do not change the underlying protocol. After importing multiple subscriptions, putting everything into one list makes duplicate names, inconsistent region labels, and multiplier notes difficult to interpret. A safer approach is to create one group per source, give each subscription a clear note, and use filters to create temporary views. Group names should describe the source or purpose rather than rely on a node count that may change.

Save subscription URLs through the client's subscription-group settings. After adding one, run an update manually to confirm that the server records parse correctly, then set an automatic update interval. If the first update fails, check that the URL is complete, that no spaces were added during copying, and that the network can reach the subscription endpoint. Do not create several identical groups after the first failure; later updates will produce duplicate servers and increase cleanup work.

Notes, group names, and server names serve different purposes

User-maintained group notes are useful for identifying a source; group names organize the list; server names are usually generated by the subscription provider and may change during updates. For long-term filtering, do not rely only on the full server name. Use relatively stable keyword combinations such as region abbreviations, protocol names, or purpose labels. If the provider changes its naming scheme, the filter results will change too, so verify after every large update that the filtered view still contains the expected servers.

Server filters generally fall into two types: include and exclude. Include conditions narrow the visible list, such as showing only records whose names contain a region marker. Exclude conditions remove maintenance notices, remaining-traffic messages, expiration notices, and other non-server entries. A filter changes the view without deleting the original records; deletion removes local servers directly. Before bulk deletion, confirm whether the current target is the filtered result or the entire group.

Start filter expressions with simple conditions

If the client supports regular expressions, start with ordinary keywords to verify the scope, then add combined conditions gradually. Parentheses, brackets, dots, and plus signs have special meanings in regular expressions, so copying a server name directly may change the match. To match several ordinary keywords, use a vertical bar to mean “any one,” for example HK|SG|JP. To exclude notices such as “remaining traffic” or “plan expiration,” test each keyword separately before combining them.

Include example:
HK|SG|JP

Exclude example:
Remaining traffic|Plan expired|Official site|Maintenance

Protocol filter example:
VMess|VLESS|Trojan

A filter condition should not be responsible for automatic server selection. It narrows the visible list, but does not continuously judge node quality or replace a real connection latency test. After filtering, run a real connection latency test within the target set, remove records whose handshakes fail, and then choose a server based on actual downloads or webpage access. See Understanding latency tests for the differences between ICMP ping, real connection latency, and download speed tests.

Update, overwrite, and removal strategies

Subscription updates usually refresh records by group. If many duplicates appear afterward, first confirm that the same URL was not imported into multiple groups, then check whether the client's update behavior overwrites old records or preserves manual edits. Renaming or changing parameters on subscription-generated servers may be overwritten at the next update. Manual servers that must be kept long term should go in a separate group rather than being mixed with an automatically updated subscription.

When removing a subscription, distinguish between deleting the subscription configuration and deleting the servers it generated. Deleting only the URL may leave old servers behind, and those records will no longer receive parameter updates; deleting only the servers while keeping the subscription will recreate them at the next update. To retire a source, stop automatic updates first, delete its servers, and then remove the subscription group. Afterward, check the active server so it is not still pointing to a deleted record.

In v2rayNG and v2flyNG, the subscription-management entry point is arranged differently from the desktop client, but the order is the same: add a note for the source, update it separately, confirm the parsed results, and then select the active configuration. When switching between mobile networks frequently, avoid an overly short automatic update interval. If an update fails, keep the existing servers and first determine whether the network is temporarily unreachable or the subscription URL itself has changed.

Routing rules in practice: match conditions, order, and outbounds

Rules determine the outbound in order

Routing's core job is to send a connection to a designated outbound. Common outbounds include proxy, direct, and block; custom configuration can add other proxy chains. A rule consists of match conditions and a target outbound: when the domain, address, port, network type, or inbound tag matches, the connection is sent to the corresponding outboundTag. Most implementations evaluate rules from top to bottom, so more specific rules should come before general ones; otherwise a broad condition earlier in the list will take over the request.

An easy-to-maintain baseline order is: block clearly unwanted targets first, send local and private addresses direct next, add business-specific domain or address rules afterward, and set the fallback behavior last. The fallback can be handled by the default outbound and does not need to be a rule covering every target. If a broad domain match is placed at the top, later split-routing entries will never take effect.

Domain matching and address matching are separate steps

Domain rules are clearest while the connection still retains domain information. For example, domain:example.com matches the domain and its subdomains, full:example.com matches the exact hostname, and regexp: is suitable when pattern matching is genuinely required. Regular expressions cost more to parse and maintain, so do not prefer them when an ordinary domain rule is sufficient. When a site relies on several static-asset domains, verify each one instead of assuming that every request follows the homepage domain.

Address rules apply after the target has been resolved to an IP address and can match a single address, a CIDR range, or a built-in category. geoip:private is commonly used to send private addresses direct, keeping local printers, storage devices, and router admin pages out of the proxy. DNS results can change over time and by region, so turning a dynamic site's current address into a permanent rule is usually unstable. Use a domain rule when the business condition can be expressed by domain.

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

How domainStrategy changes matching

AsIs keeps the original domain from the request and does not proactively resolve an address for routing; IPIfNonMatch resolves the address and tries address rules only when no domain rule matches; IPOnDemand triggers resolution earlier when rule evaluation needs an address. Choose the strategy together with the DNS configuration. If routing depends on address categories but the strategy never resolves an address, those rules may not match; resolving too early may add DNS queries or change the domain-routing path.

For general use, start with AsIs and switch to IPIfNonMatch only when you clearly need address-based evaluation after resolution. After changing it, check whether the same domain generates different DNS requests and reaches the expected outbound. Do not interpret these strategy names as speed settings: they change the matching stage and resolution timing, and no value is guaranteed to be faster in every network environment.

Validate rules by observing the complete request

Do not validate routing only by checking whether the homepage opens. A page may request the main site, images, APIs, and authentication domains at the same time, and different requests may use different outbounds. Start with one specific target and one rule, restart the core, and inspect the log for the target, match result, and outbound tag. Expand the domain scope only after the single rule works. If the log shows only an address and no domain, return to the DNS and sniffing settings to check whether domain information is still available.

When a rule has no effect, check these four items in order: whether the rule is in the right position, whether the matching syntax follows the core's format, whether the target outbound tag exists, and whether the current core actually handles the connection. A browser's built-in secure DNS, an application's own proxy, or an existing long-lived connection may bypass the path you just changed. Close and reopen the target program before testing, and clear its connection cache if needed instead of merely refreshing the page.

Keep routing rules readable. Dozens of scattered domains are harder to review and more prone to overlap than a small number of business-grouped rules. After finishing, go through the list from the top and answer for each entry: “What does it match, which outbound receives it, and why must it be here?” Entries without a clear answer usually need to be split, renamed, or removed.

DNS configuration optimization and resolution-path troubleshooting

First map out who is making the query

DNS failures are often mistaken for a dead node. The actual path may include the system resolver, browser secure DNS, the v2rayN core's DNS, TUN DNS interception, and remote resolution. Different programs may use different resolution entry points, so the same domain can return different results. Before optimizing, determine whether the target program uses the system resolver, whether the query enters the core, which server the core contacts, and how the result is used for routing.

With only the system proxy enabled, a browser may resolve domains itself or hand them to the proxy entry point, depending on the proxy type and application. With TUN enabled, system DNS requests are generally easier to intercept consistently, but the DNS address, routes, and exclusions must still be correct. If the browser has secure DNS enabled separately, its queries may be sent as ordinary HTTPS traffic, so traditional port 53 requests will not appear.

Core DNS servers and query rules

The core DNS configuration can define multiple servers and select among them by domain scope. Plain UDP DNS is simple, but the request path depends on the network and routing. DNS over HTTPS queries through an HTTPS connection, but the server domain's initial resolution must be solved first. Using a fixed address reduces startup dependencies but requires maintenance when the address changes. Choose based on reachability and dependency chains, not the server name alone.

DNS servers can also have domain filters. The usual purpose is to send specific domains to a designated resolver, not to distribute every query randomly among several servers. If server scopes overlap, define the precedence clearly. Let the default server handle domains without special requirements and keep dedicated servers limited to the necessary scope so the configuration is easier to verify.

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": ["domain:service.example"]
      },
      "1.1.1.1",
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

The domains in this example only demonstrate the structure; replace them with reachable resolvers in a real configuration. hosts is for a small number of fixed mappings, suitable for local devices or testing rather than maintaining many public domains. A wrong fixed mapping bypasses normal updates, so record its purpose after adding one. localhost returns to the system resolver. If that resolver sends the request back to the core, a loop may form; confirm the direction of the path before using it.

Query strategy and address families

queryStrategy controls which address types are returned. UseIP allows the environment to determine usable addresses, UseIPv4 requests IPv4 only, and UseIPv6 requests IPv6 only. A returned address is useful only when the network can actually connect through that address family. Obtaining an IPv6 address does not prove that the outbound path can reliably reach every IPv6 target. If some sites wait and then fall back, temporarily limit resolution to IPv4 to check whether the address family is involved.

Confirm address-family issues with comparative tests rather than permanently disabling one family as a general rule. Record the resolution result, connection target, and failure stage separately. If DNS returns an address but TCP or UDP setup fails, the problem is after resolution; if only one resolver times out, inspect that resolver's access path. “Resolution failed” and “connection refused” in the log refer to different stages and should be handled separately.

Use cache clearing only for verification

After changing DNS, the system, browser, and core may all retain old results. On Windows, run ipconfig /flushdns in a terminal to clear the system cache, but this does not clear the browser's own cache or terminate existing connections. A more reliable test is to save the configuration, restart the core, close the target program, clear only the necessary caches, and make a fresh request. Repeated cache clearing cannot fix a wrong configuration; it is useful only to confirm whether an old result is affecting the test.

ipconfig /flushdns

nslookup example.com

nslookup example.com 1.1.1.1

nslookup is useful for comparing the system's default resolver with a specified resolver, but it may not use the core DNS path that the application actually follows. If the command succeeds while the browser fails, continue checking the browser and proxy entry point. With TUN or FakeDNS enabled, ordinary query tools may show intercepted mapping addresses, so interpret them with the relevant section rather than judging them as traditional DNS results alone.

v2rayN TUN mode: interception scope and platform differences

Which programs does TUN help when they ignore the proxy?

The system proxy depends on applications actively reading the proxy settings. Browsers and many desktop programs support this, but some game launchers, command-line tools, background services, and applications with custom network stacks may connect directly. TUN mode captures system traffic through a virtual network interface so these connections can enter the core as well. It changes the traffic entry point, not the server protocol, and it cannot restore a node that is already unable to connect.

Whether to enable TUN should depend on application requirements. If you use only programs that correctly read the system proxy, system-proxy mode is simpler and easier to troubleshoot. Enable TUN only when a program clearly bypasses the proxy entry point or when TCP, UDP, and DNS must be handled consistently. Treating TUN as the default troubleshooting step introduces routing, permission, virtual-interface, and DNS issues all at once.

Confirm permissions and conflicts before enabling it

TUN must create or control a virtual network interface and adjust routes. On Windows, elevated permissions may be required; macOS and Linux also require the system to permit the relevant network operations. If the client reports that interface creation failed, check permissions and driver status first instead of repeatedly switching nodes. Corporate network-management software, other virtual networking tools, and similar proxy programs may modify routes at the same time, so keep only one traffic interceptor active during testing.

Before enabling it, record the system default gateway and DNS, disable other traffic-interception tools, and start v2rayN's TUN mode. After it succeeds, test an ordinary webpage first, then test the program that previously ignored the system proxy. If all networking stops immediately, turn off TUN to restore the baseline, then check whether the virtual interface was created, whether the default route changed, and whether DNS points to the expected entry point. Do not stack FakeDNS and complex routing onto a disconnected state.

Strict routing, automatic routing, and MTU

Automatic routing sends traffic that needs interception to the TUN interface; strict routing further limits paths that could bypass it. Option names vary between builds, but the principle is the same: start with default automatic routing to verify basic interception, then adjust strictness based on leakage paths or local-network needs. If local resources become unreachable after enabling strict routing, check that private ranges remain direct instead of adding a global proxy rule.

MTU determines the packet size the virtual interface can carry. If it is too large, some paths may show partial webpage loads, stalled uploads, or timeouts for specific connections; if it is too small, fragmentation and overhead increase. When a connection works but large requests fail, record the original value and test lower MTU levels comparatively. Do not rely on a single speed test; test at least a small webpage, a larger file transfer, and an application that maintains a persistent connection.

Exclude local-network and client traffic

TUN routing usually needs private ranges to remain direct; otherwise printers, gateway admin pages, and local services may be sent through the proxy by mistake. A geoip:private rule can handle common private ranges consistently. If the local network uses nonstandard ranges, add them based on the actual network. Local services addressed by name also depend on local DNS: direct access to the address is not enough if the name is resolved remotely.

The client's own connection to the proxy server must also avoid entering the same proxy outbound again, or a traffic loop will result. Standard configurations usually handle this, but custom routing or outbounds still require checking that the server address uses a direct path. If the core repeatedly reconnects after startup and the log shows the same server target over and over, check for a self-proxy loop.

Recovery checks after turning off TUN

When the client closes normally, the virtual interface and temporary routes should be removed as well. If networking remains unavailable after an abnormal exit, reopen the client and turn off TUN normally, then check whether the system default route and DNS have been restored. Rebooting may clear some temporary state, but it should not replace root-cause analysis. If remnants recur, check whether multiple network tools are managing the interface and whether the log reports an error during shutdown.

On mobile, v2rayNG and v2flyNG use the system's network-interception interface, so application exclusions, background restrictions, and battery-saving policies directly affect persistent connections. Desktop TUN settings cannot be applied unchanged to Android, but the routing and DNS analysis is the same: confirm that traffic enters the client, confirm the rule match and outbound, and then check whether the system terminates the connection in the background.

How FakeDNS works, when to use it, and its limits

FakeDNS preserves the relationship between domains and connections

After intercepting a DNS query, FakeDNS returns a temporary address from a reserved pool and records the mapping between that address and the original domain. When an application connects to the temporary address, the core restores the domain from the mapping and then applies domain routing and the remote connection. Its main value is preserving domain information for programs that resolve locally and then connect using only the address, giving domain rules a chance to work.

A FakeDNS address is not the target server's real public address, so it cannot be used independently of the core. The query and subsequent connection must enter the same interception path for the mapping to work. If the query goes through FakeDNS but the connection bypasses TUN, the application will try to reach the temporary address directly and fail. Conversely, if the connection enters TUN but the query uses another resolver, the mapping cannot restore the domain.

When FakeDNS is a good fit

When TUN is stable but logs show many connections only by address and domain routing is difficult to match, FakeDNS may be worth considering. It can also help when you want to reduce real local resolution and keep domains available for processing through the proxy chain. Before enabling it, confirm that ordinary TUN, DNS interception, and basic routing work; otherwise the added address pool and mapping layer will make failures harder to interpret.

In ordinary system-proxy scenarios, there is usually no need to enable FakeDNS just to make things “faster.” Many proxy entry points can already receive domains, so the domain information is not lost. FakeDNS is not a cache accelerator; its core function is mapping and restoration. Whether it improves connectivity depends on the original domain-handling problem, so it should not be treated as a performance option for every environment.

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

This example shows a common structure; actual support depends on the core and configuration entry point used by the client. 198.18.0.0/15 is a reserved range commonly used for benchmarking and can serve as a mapping pool, but confirm that the local network, other virtual networks, and corporate routes do not use the same range. A pool conflict may appear as specific internal services becoming unreachable or routes treating real targets as FakeDNS addresses.

Local networks, split routing, and exclusions

Local network names, printer discovery, and router-internal domains usually depend on local DNS and should not all be sent through FakeDNS. Send private domains and local suffixes to the local resolver and keep private addresses direct. If the local network uses a custom suffix, add it explicitly to the exclusions. Excluding private addresses alone may not be enough because name resolution happens before an address is obtained.

When FakeDNS works with domain routing, rules should be evaluated after the domain is restored. If connection logs always show only mapping addresses, the restoration path has not completed. Check whether DNS queries and connections are handled by the same instance, whether the address pools match, and whether TUN captures the target application. Do not hide the problem by adding proxy rules for the mapping range; that sends every temporary address through the proxy while still losing the value of the original domain rules.

Cache lifetime and testing method

FakeDNS mappings have capacity and a lifetime. If an application keeps an old mapped address while the core has restarted or replaced the mapping, the old connection may fail. When testing configuration changes, restart the target program and clear its DNS cache if necessary so the query and connection are rebuilt in the same run. Restarting only the core while keeping the application's old connection can produce inconsistent results.

For verification, choose a test target with a clear domain rule. Before enabling FakeDNS, record how the target appears in the log. Then start a completely new connection after enabling it and confirm all three stages: DNS returns a mapped address, the core restores the domain, and the rule selects the expected outbound. If any stage is missing, fix that stage before adding more rules.

After disabling FakeDNS, also restore the corresponding DNS server configuration and let applications resolve domains again. Removing only the address pool while retaining the fakedns resolver entry leaves the configuration incomplete. If you need to switch between enabled and disabled states regularly, save two complete configurations instead of manually editing several scattered options each time.

Managing multiple subscriptions, update cadence, and conflicts

Give each source its own lifecycle

The goal of managing multiple subscriptions is not to pile more servers into one list, but to let each source be updated, paused, and reviewed independently. Give every subscription a unique note and group, and do not configure two URLs with the same name. When one source fails to update, changes its node names, or needs to be paused, you can then handle only that group without affecting other verified servers.

Put manual servers in a separate “Local maintenance” group. Subscription updates usually follow the remote content, so edits to subscription-generated servers may be overwritten at the next refresh. If you need to adjust a parameter temporarily, copy the server to the manual group, make the change there, and mark its purpose in the name. Leave the original subscription record untouched for comparison with the remote parameters.

Stagger updates instead of polling constantly

Set the automatic update interval according to how often the subscription changes. An interval that is too short creates unnecessary requests and may produce a stream of failures during network transitions. Multiple subscriptions do not need to update at the same moment; first confirm that each source updates independently, then enable a sensible schedule. After a laptop wakes from sleep, switches networks, or before the proxy core has connected, the first automatic update may fail; wait for the network to settle and retry manually.

When updating a subscription, whether the subscription request uses a direct connection or the proxy depends on client settings and the current network. If a subscription is reachable only through the current proxy, it depends on an already working node. Keep at least one verified server that will not be removed before the update. Do not delete all old records before fetching new content; one temporary update failure would otherwise remove your recovery path.

Handle same-name servers and duplicate content

Different sources may use the same server name and may even provide identical parameters. The same display name does not mean the configurations are the same, so do not bulk-delete by visible text alone. Compare the group, address, port, protocol, and transport parameters. If the client supports group views, limit the operation to one source first. Before deduplicating across groups, confirm that the duplicate record is not serving as a backup source.

When the same subscription is imported twice, the clearest sign is two similar batches of records appearing after every update. Pause automatic updates for the affected groups, decide which subscription configuration to keep, and remove the extra group and its generated servers. Then update the retained group and check that the active server still exists. Deleting records one by one from the combined list does not fix the duplicated subscription itself.

Separate server selection from group management

Groups manage sources; latency tests evaluate the connection stage; actual use also depends on bandwidth, stability, and the target service. Do not assume every server in a recently updated group works. After each update, run a real connection latency test, remove records that cannot complete the proxy handshake, and then test a small number of candidates in practice. See Choosing the right node for a practical selection approach.

If automatic selection relies on scheduled tests, understand the test target, timeout, and switching conditions. An unreachable test address can make every server look unusable; a timeout that is too short can discard high-latency but working routes; overly frequent switching can interrupt existing connections. First verify manually that the test target is reachable through multiple servers, then consider automation. Applications that need persistent sessions usually value stability more than the lowest one-off latency.

Subscription migration and local records

When moving to a new device, handle subscription URLs, manual servers, routing rules, and DNS settings separately. Migrating only subscriptions can regenerate remote servers but will not bring back local custom rules; copying only the runtime configuration may include temporary generated content that is difficult to update later. After migration, update each source individually, confirm that group and server counts make sense, and then import custom rules.

Subscription URLs and server credentials are sensitive configuration. Hide full URLs, user IDs, and tokens in troubleshooting screenshots. Check request parameters and server information before submitting logs. Use an obviously fake value such as https://example.com/sub?token=xxxx in public examples; never put real subscription content in scripts, webpages, or shared notes.

Once a multiple-subscription setup is stable, routine maintenance only needs to check failed updates, unexpected duplicates, and records that have been unusable for a long time. Do not rebuild every group just to keep the list tidy. Clear source boundaries, a recoverable active server, and a few useful notes are easier to maintain over time than complete automation.

Custom outbounds, chained connections, and complete diagnostics

Outbound tags connect routing with connection methods

The core uses outbounds to define how connections leave the device. Common proxy, direct, and block outbounds mean use the current proxy server, connect directly, and block the request. Custom outbounds can add a local SOCKS service, dedicated direct-connection parameters, or other supported protocols, which routing rules then select by tag. Tags must be unique, and outboundTag in a rule must exactly match the outbound's tag.

Before adding an outbound, define its purpose: should a class of requests be sent to another local service, or should a particular target use an independent connection path? A custom outbound without a matching routing rule will not take over traffic automatically. If the tag is misspelled, the core may reject the configuration or report an error when handling a request. Use stable, readable short English words for names; avoid using server names as tags because subscription updates may change them.

{
  "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 sends selected traffic to a SOCKS service on the local 127.0.0.1:1081. Before using it, confirm that a service is actually listening on that port and that it will not send traffic back into the current v2rayN inbound. If two local services point to each other, a loop forms and connections repeatedly start and fail. Custom ports must also not conflict with the local HTTP, SOCKS, or API ports already used by v2rayN.

A chained connection requires every hop to be explicit

Chained connections add failure points and handshake overhead, so configure them only when there is a clear need. Verify every hop independently: the first hop must reach the intermediate outbound from the device, the intermediate outbound must reach the next target, and DNS must resolve where expected. If any hop depends on the previous hop's DNS or routing, document the dependency to avoid mutual waiting during startup.

When testing a chain, start with a simple target and do not enable complex domain rules at the same time. The log should show which inbound received the request, which rule matched, which outbound was selected, and where the failure occurred. A connection timeout has a broad range of possible causes, including an unlistened port, unreachable routing, or an unresponsive next target; an authentication failure points first to the credentials and protocol parameters for that outbound. Do not hide a definite configuration error by extending every timeout.

Read logs layer by layer

Complete diagnostics can be divided into six layers: whether the client process starts, whether the core configuration parses, whether an inbound port or TUN captures the request, whether DNS returns a usable result, whether routing selects the expected outbound, and whether the outbound completes the connection. The earliest error in the log is usually closest to the root cause. When the core configuration fails to parse, a later “proxy unavailable” message has no independent diagnostic value; when DNS has already failed, do not start by tuning server latency settings.

Temporarily increase the log level during troubleshooting and restore the normal level afterward. Detailed logs may contain target domains, server addresses, and local paths, so remove sensitive data before sharing. When capturing logs, keep the time window around the error and include the steps that reproduced it instead of copying only the final line. One clear reproduction is easier to diagnose than a large amount of unrelated output.

Build a reproducible diagnostic workflow

When “V2Ray cannot connect,” first record the time, current server, proxy mode, whether TUN is enabled, whether FakeDNS is enabled, and which programs are affected. Then choose one minimal test target, disable custom rules unrelated to the issue, and start a fresh connection. If the baseline recovers, re-enable settings one at a time in the original order until the error returns. This narrows a complex problem to a single change.

If all servers fail at once, check the local network, whether the subscription was just updated, system time, DNS, and client status before changing server parameters one by one. If only one server fails, compare other records in the same group and that server's protocol parameters. If only one application fails, first confirm that it enters the current proxy path. For more short answers, work through the FAQ page.

Long-term maintenance and upgrade checks

After updating the client or core, start with the existing baseline configuration and then check whether custom fields are still supported. Do not refactor all routing and DNS settings at the same time as a client update. If the configuration will not load, look for logs about deprecated fields or format changes and narrow the issue to a specific snippet. Use the download page on this site for downloads and client selection: v2rayN is preferred on desktop platforms, while Android users can choose v2rayNG or v2flyNG according to their core requirements.

Periodically review subscription groups, filter conditions, routing entries, dedicated DNS rules, and custom outbounds. Remove temporary rules whose purpose is no longer clear, confirm that local-network exclusions still match the current network, and check that automatic updates continue to succeed. The goal of advanced configuration is not to add more options, but to make every layer explainable, verifiable, and reversible.