Advanced V2Ray Configuration Guide

Build a configuration model you can roll back

Separate client settings, core configuration, and the system network

The first step in advanced configuration is not adding more rules, but identifying which layer owns each setting. v2rayN, v2rayNG, and v2flyNG are graphical clients responsible for subscription management, server selection, starting the core, and writing system network settings. The Xray or V2Fly core handles protocol connections, DNS queries, route matching, and inbound/outbound processing. The operating system handles the default route, system proxy, virtual network adapter, and each application's network permissions. When all three layers are active, a client status of “Connected” only means the client and core process have started; it does not confirm that DNS resolution, route matching, or system traffic capture is working correctly.

During troubleshooting, follow the data flow: an application first generates a domain name or destination address; the operating system decides whether traffic goes to the local proxy or virtual network adapter; the core then applies DNS and routing rules; finally, it selects a direct, proxy, or blocked outbound. If a browser works but a command-line tool does not, focus on how the system proxy is inherited. If a domain fails while direct access to its address works, focus on DNS. If only certain websites or paths behave oddly, check rule order, protocol support, and the destination's address family. Layer-by-layer diagnosis avoids low-information actions such as repeatedly reinstalling the client.

Establish a baseline and record every change

Before making adjustments, keep a confirmed working baseline. It should contain one usable subscription, one current server, default DNS, default routing, and the system proxy mode, with TUN, FakeDNS, and complex custom outbounds disabled. Record the client type, active configuration file, selected server, system proxy status, and test applications. On desktop, v2rayN works well with separate profiles for different purposes. On Android, record the selected profile, per-app proxy status, and battery policy so that background restrictions are not mistaken for core failures.

Change one topic at a time. For example, finish and test subscription filtering before adding routing rules; adjust DNS only after routing is stable; evaluate TUN and FakeDNS last. If DNS, routing, and the virtual adapter are changed together, a failure cannot be attributed to a single step. A change log needs no special tool: a table with “Before, Change, Expected result, Actual result, and Rollback” is enough. The more rules you have, the more important rollback becomes, because subscription updates, network changes, and system upgrades can expose edge cases that previously never appeared.

Define repeatable validation steps

Validation steps must be consistent; otherwise test results cannot be compared. At minimum, check that the client log is not stuck retrying, a test domain resolves, both a browser and a non-browser application can establish a connection, and the system proxy or virtual adapter returns to the correct state after the client stops. For routing, choose three targets that clearly represent direct, proxy, and blocked rules rather than testing only one familiar website. For DNS, observe both the query result and the final connection path so a browser cache is not mistaken for a successful configuration.

On Windows, use Get-NetIPInterface to inspect interface metrics; on macOS, use scutil --dns to inspect system resolvers; on Linux, use ip route to check the routing table. Command output confirms system state only; it does not prove that the client's internal rules matched. On Android, combine client logs, network changes, and per-app tests. If you do not yet have a suitable client, visit the client page and choose by platform; v2rayN is the recommended desktop option, while Android users can choose v2rayNG or v2flyNG according to core requirements.

Subscription groups and server filtering

Groups solve management; routing solves traffic flow

Subscription groups are often mistaken for traffic routing. Groups organize servers, narrow the selection, and define update boundaries; they do not decide which outbound a website uses. Traffic paths are controlled by routing rules and outbound tags. A maintainable structure stores subscriptions by source, builds views by purpose or capability, and lets routing rules reference stable outbounds. Do not mix subscription names, server names, and outbound tags into one layer: when an update changes names, both name-based filters and dependent rules may fail.

Keep “source groups” and “work groups” as separate dimensions. A source group maps to a subscription URL, making it easy to update, pause, or remove independently. A work group filters by protocol, transport, region label, or manual purpose. v2rayN's server list works well with remarks, subscription ownership, and filter expressions; the mobile interfaces of v2rayNG and v2flyNG are better kept to a small number of groups rather than complex filters on a small screen. Group names should be stable and readable; do not encode temporary status in them.

Design filters that are easy to maintain

Server filtering usually operates on remark text, so accuracy depends on naming quality. Prefer an “include first, exclude second” strategy: narrow the list by a clear protocol or purpose, then exclude test entries, expired entries, and unwanted transports. Keep expressions short and spot-check the results after each subscription update. If an upstream provider changes its naming format, update the filter instead of renaming entries one by one, since the next update may overwrite local changes. Important servers can have local remarks, but confirm that the client preserves this field during updates.

Regular expressions work well with stable naming schemes, not with vague text. The example below matches names containing “VLESS” or “REALITY” while excluding “Test” and “Expired.” Filter fields support regular expressions differently across clients, so verify the result against a small number of entries before applying it to the full list. If the interface supports only plain-text search, split the logic into several simple views instead of forcing everything into one keyword.

^(?=.*(?:VLESS|REALITY))(?!.*(?:Test|Expired)).*$

If the filter returns nothing, remove the exclusion first, then add the expression back piece by piece. If it returns too many entries, check capitalization, full-width punctuation, and consistency in the upstream naming. Filtering does not test server reachability and cannot replace real connection tests. Latency reflects network round-trip conditions at one moment; it does not fully represent throughput, stability, or protocol compatibility. Choose servers using handshake logs, sustained access, and recovery after network changes rather than a single sort result.

Handling updates, deletions, and duplicates

Update subscriptions one source at a time. Update one subscription first, verify the server count, names, and current selection, then move to the next source. Updating all subscriptions at once can spread duplicate entries or malformed names before their source is known. Before deleting a subscription, confirm that the active server and custom routes do not depend on it. Some clients retain historical servers generated by subscriptions, while others overwrite them during updates. Check the client's update policy first and export the client configuration when necessary.

Do not identify duplicate servers by display name alone. Two entries may share a name but differ in address, port, protocol parameters, or may have identical parameters while coming from different subscriptions. Compare the protocol, server address, port, transport, and security parameters before deciding what to keep. If several sources have long provided the same entry, keep the most stable and consistently named copy and move the others to a disabled group instead of deleting them immediately. This preserves a rollback path when updates fail.

Automatic selection also needs clear boundaries. It can reduce manual switching within a candidate set, but that set must be filtered first and tested under conditions close to actual use. Putting servers with different protocol capabilities and network paths into one automatic group can cause frequent connection changes, interfering with DNS caching, long-lived connections, and troubleshooting. For stability, pin a server for a period and observe logs and application behavior; enable automatic selection only after the candidates are confirmed compatible.

Routing rule order and practical structure

Understand first-match evaluation from top to bottom

The key to V2Ray routing is not the number of rules but their order. Most configurations evaluate rules from top to bottom; once a connection matches the first applicable rule, later rules are not checked. Specific rules should come before general ones, blocking rules should cover clear and stable targets, and a fallback path should come last. If a broad domain, address, or port rule is placed at the top, later specific rules will not take effect even when their syntax is correct.

A maintainable order is usually: private-network addresses and local services first, explicit blocks next, domain or address sets requiring a specific path after that, common direct-access sets next, and the default outbound last. Distinguish the relationship between conditions within one rule and the order between multiple rules. Multiple fields in one rule generally require all corresponding conditions to match; multiple values in one field usually mean any value may match. State the intent in plain language before translating it into a rule.

Boundaries between domain, address, and process conditions

Domain rules work only when the core has access to the destination domain. If an application resolves the domain itself and connects directly by address, the core may see only the destination address; address rules, DNS sniffing, or TUN may then be needed. Address rules are stable, but large services change their ranges and are costly to maintain manually. GeoSite is suited to domain-category matching, while GeoIP is suited to address-geolocation matching. Keep both data sets updated; see the GeoIP and GeoSite Database Update Guide for update guidance.

Process conditions depend on the operating system and client implementation, so they should not be the sole basis for routing. Process names can change with installation methods, helper processes, or app updates, and an app may initiate requests through a system service. On desktop, process rules can supplement precise routing, but keep domain or address rules as the foundation. Android per-app proxying selects which apps enter the virtual network at the system layer; it is a separate decision from core routing: the former decides whether traffic enters, and the latter decides which outbound it uses afterward.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:telemetry.example.invalid"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

In the example, IPIfNonMatch means the core checks domain rules first, then resolves the address for address rules if no domain rule matches. This can improve address-rule coverage, but it also makes core DNS part of the decision, so it must be designed together with the DNS servers and query strategy in the DNS section. Always resolving by address creates more DNS queries; never resolving means connections with only domain information cannot match address sets. There is no universal value: choose according to whether rules depend on GeoIP, whether the app supplies a domain, and how DNS is routed.

Use logs to validate rules instead of inferring from page results

Rule validation should confirm the target, the matching condition, and the final outbound. Clear the browser's DNS and connection cache, close test pages that reuse connections, and send a fresh request. If the log shows the target has already become an address, inspect application resolution or sniffing. If the domain is correct but the wrong outbound is selected, check rule order and domain syntax. If the outbound is correct but the connection fails, move on to protocol parameters, server status, and network path instead of changing routing again.

Domain syntax has important differences. A full domain matches one hostname; a domain suffix covers its subdomains; keyword matching is the broadest and most prone to false positives. Prefer full domains or well-maintained domain sets, and use keywords only when the naming is stable and cannot be enumerated. Port rules should specify the protocol because TCP and UDP behavior may share a port. When blocking UDP, also consider whether the application automatically falls back to TCP: apparent access does not prove that the block rule failed.

After changing routing, test a local-network service, a clearly direct target, a clearly proxied target, a blocked target, and an unmatched target in that order. Local-network failures usually indicate misplaced private-address rules. If every target follows the same path, a fallback rule may be too high. If only domains fail, DNS and routing may be looping. If a connection succeeds but pages do not open, continue through the local settings, node, routing, and resolution layers using the 12-Point Troubleshooting Checklist.

DNS configuration and resolution paths

Map where each query originates

DNS problems are difficult to locate because the system resolver, browser secure DNS, client core DNS, and remote resolution may all coexist. An application may use the system resolver or send encrypted queries itself. Under system-proxy mode, some applications still use system DNS directly. TUN can capture more queries, but hard-coded resolvers and special protocols may still bypass it. Before configuring anything, determine which path the test application uses and whether the core should take over; simply seeing a DNS address in the client does not mean every query passes through it.

A resolution path has at least three decisions: which server receives the query, which outbound carries it, and whether the result is used for routing or only for connection setup. If the DNS server itself must go through the proxy while the proxy connection depends on that same DNS, startup enters a loop. Keep a resolver reachable through the basic network, or use an already resolvable fixed domain and an independent path for the server address. Every optimization should first ensure that the startup chain is complete before tuning caching, concurrency, or address-family preferences.

Choose resolvers by domain scope

Different domains can use different DNS servers, but the routing basis must be clear. Internal domains and LAN devices usually belong with the system or LAN resolver because they may depend on search domains, private zones, and local addresses. Public domains can use the resolver configured in the core. Domains that must follow a specific outbound should send queries along the same path so the resolution result matches the connection egress. Do not simply query multiple servers in parallel and accept the first response; unstable result sources make troubleshooting harder.

The hosts setting is suitable for a small number of stable mappings, such as local test services or internal resources requiring a fixed alias. It is not a large-scale domain-rule database and should not replace normal resolution. Static entries can quickly become stale when mappings change often. If a domain has both IPv4 and IPv6 records, confirm that the system network has a usable path for the relevant address family. Disabling one type of response may hide the symptom while leaving system routing or upstream network problems unresolved.

{
  "dns": {
    "hosts": {
      "router.home.arpa": "192.168.1.1"
    },
    "servers": [
      {
        "address": "localhost",
        "domains": [
          "domain:router.home.arpa",
          "domain:service.example.invalid"
        ]
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

This example illustrates the relationship between fields: send local domains to the local resolver first and use subsequent servers for the remaining queries. In production, choose resolvers that are reachable on the current network and have a clear purpose. queryStrategy controls the returned address families, while UseIP enables address lookups; querying only IPv4 or IPv6 should reflect actual network capability. Clients may generate equivalent configurations with different field forms. If the graphical interface already provides a DNS mode, avoid importing duplicate settings, because later-generated fields may override earlier ones.

Caching, browsers, and diagnosing poisoned results

Immediately revisiting the same page after changing DNS often still uses an old cache. Caches may exist in the browser, system service, core, and target application. For validation, create a new connection, use a test domain that has not been queried before, or flush the resolver cache using the platform's normal method. If the browser has independent secure DNS enabled, temporarily disable it or configure it explicitly so the test path matches the client design. Otherwise, a working browser and failing applications only show that they use different resolution paths.

When evaluating an abnormal result, compare the system query result, core query result, and final connection address instead of relying on one command. If system resolution works but the core fails, inspect the core DNS outbound and routing. If the core resolves correctly but the application still fails, check whether it bypasses the proxy or reuses an old connection. If the address is correct but the connection times out, the problem has moved beyond DNS to routing, protocol, or server checks. Occasional increases in resolution time do not necessarily justify changing servers; first check for a network change, an initial handshake, or a cache miss.

DNS and routing must be validated together. With strategies such as IPIfNonMatch, routing may actively trigger resolution, while DNS queries themselves enter the routing system. If the DNS server's domain is matched by a rule that depends on the resolution result, recursion can occur. Assign the resolver an explicit outbound, ensure the basic server address has a directly reachable path, and place related rules before general rules to reduce loop risk. Once the configuration is stable, add finer-grained per-domain resolver rules.

TUN mode: activation order and boundaries

TUN and system proxy handle different traffic

A system proxy provides a proxy address to applications that follow the operating system's proxy settings. It is simple to configure and easy to roll back, but it cannot cover programs that ignore the system proxy or some UDP traffic. TUN creates a virtual network interface that sends a broader range of IP traffic into the client, where the core applies DNS, routing, and outbound selection. It is not a “stronger switch”; it changes the system data path and therefore requires additional handling for the routing table, DNS capture, interface priority, and local-network access.

Whether to enable TUN should depend on application requirements. If browsers, common desktop software, and development tools use the system proxy correctly, switching merely adds complexity. Evaluate TUN when you need to handle apps that ignore proxy settings, UDP requests, or unified routing. Android clients generally capture traffic through the system's virtual network capability and may add per-app selection. Desktop clients may require system privileges to create an interface and write routes. Permissions differ by platform, but validation is the same: confirm interface creation, default-path changes, DNS entering the expected channel, and network recovery after the client stops.

Enable it with the smallest possible configuration

Before enabling TUN, close other network tools that create virtual adapters, modify the default route, or capture DNS so two routing systems do not compete. Keep one verified server, use a minimal rule set, disable FakeDNS, and avoid changing the system firewall at the same time. After starting TUN, first check the client log for successful interface creation, then test the local gateway, an ordinary domain, and a target that clearly uses the proxy. If the local gateway fails immediately, check private-address direct routing and exclusions before changing remote protocol parameters.

On Windows, inspect interface and route metrics in PowerShell; on macOS, check the current default route and DNS resolvers; on Linux, inspect the routing table, policy routing, and DNS service status together. The commands below only read state and do not modify system configuration. The output should show a virtual interface created by the client, but its name depends on the client and operating system; do not write automated checks around a fixed name.

# Windows PowerShell
Get-NetIPInterface | Sort-Object InterfaceMetric

# macOS
route -n get default
scutil --dns

# Linux
ip address
ip route
ip rule

Handle LAN traffic, loopback, and routing loops

The most common TUN failure is sending traffic that should not be captured back into the virtual interface. The proxy server's own connection must be excluded from TUN routing; otherwise the core's outbound connection is sent back to its inbound path, creating a loop. LAN subnets, loopback addresses, local services, and required system network probes should also use direct access as needed. Private-address rules are a foundation, but enterprise networks may use more complex internal ranges and domains. Supplement them from the actual routing table instead of relying only on a generic list.

If the client reports a normal connection after enabling TUN but every app times out, first check whether the server address was recaptured by TUN. If the internet works but LAN devices are unreachable, check private-address direct routing and local-interface routes. If only UDP apps fail, verify outbound UDP support, routing permission for UDP, and whether the system firewall blocks the virtual interface. If connectivity remains broken after stopping TUN, confirm that the client exited cleanly and restored system DNS, the default route, and the system proxy.

Switching between mobile and Wi-Fi networks changes the underlying interface, address, and DNS. A TUN client must bind to the current network again, so a brief interruption is part of path reconstruction; persistent failure calls for reconnecting and checking whether an old interface is still referenced. Laptops can show the same behavior after waking from sleep. Record whether the issue occurs at initial startup, after a network switch, after resume, or during long-running use. This is more useful than simply reporting “cannot connect.”

Assessing performance and MTU

TUN adds a user-space processing layer, but performance issues cannot be attributed to the virtual adapter alone. First compare system-proxy and TUN performance with the same server, network, and routing rules, then observe CPU usage, log retries, and behavior on specific sites. If small requests work while large pages or file transfers stall, MTU or path fragmentation may be involved. If every request slows evenly, inspect DNS, the server path, and protocol handshakes first. Do not change MTU, concurrency, and buffer sizes simultaneously without controlled comparisons.

Start with the client's default MTU. Lower it gradually only when a stable, reproducible pattern of large-packet failure with small-packet success remains after changing servers and networks. Re-establish connections after each change so old connections are not reused. For a fuller explanation of virtual-adapter principles, platform procedures, and conflict cases, see V2Ray TUN Mode Explained. This section focuses on placing TUN within the complete configuration chain rather than treating it as an isolated switch.

How FakeDNS works and when to use it

FakeDNS preserves domain information that would otherwise be lost

Some applications resolve domains locally and then connect using the destination address. When the core receives the traffic, it sees only the address, so domain-based routing cannot match directly. FakeDNS returns a temporary address from a dedicated pool for the domain and records the mapping. When the connection reaches the core, it restores the original domain from that mapping and applies domain-based routing. Its purpose is to preserve domain information needed for routing, not to provide a faster public DNS service.

FakeDNS normally works with TUN or an inbound that can capture DNS. If an app's DNS query does not enter the core, it will not receive a dedicated address and no mapping will be created. If the query enters the core but the subsequent connection bypasses TUN, the system will try to access the dedicated address directly and fail. Both the DNS-query path and connection path must therefore be captured. Verify that ordinary TUN and real DNS work first; enabling FakeDNS on top only adds variables.

Address pools, mappings, and fallback

The dedicated address pool must not overlap with ranges used by real LANs, enterprise networks, or other virtual networks. An overlap can send a real internal service to FakeDNS or route a temporary address through the wrong interface. Pool capacity determines how many mappings can be retained at once, but enlarging it blindly is unnecessary. Insufficient capacity usually appears as old mappings being evicted, which can confuse long-lived connections and cached applications. Keep a sensible cache lifetime and create fresh test connections after client restarts and network changes.

Not all traffic is suitable for FakeDNS. LAN discovery, internal domains, services that depend on system search domains, and applications that require real addresses should retain real resolution or be bypassed. For apps that cannot handle dedicated addresses correctly, use per-app exclusions or send the relevant domains through ordinary DNS. Do not label compatibility problems as server failures: if the same server works immediately after FakeDNS is disabled while ordinary TUN remains reliable, inspect domain mappings, sniffing, and address-pool conflicts.

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

This snippet shows common field relationships; a specific client may generate the corresponding configuration through its interface. 198.18.0.0/15 is commonly used for benchmarking and can serve as a dedicated mapping pool, but confirm that the local environment does not already use it. Do not access addresses in the pool directly over an external network; they are meaningful only in the local core mapping. If logs show a request reaching the address without restoring its domain, the DNS query and connection may not share the same mapping context, or the mapping may have expired.

Working with sniffing, routing, and real DNS

Sniffing can recover domains from some TCP, TLS, or HTTP traffic, while FakeDNS recovers them from a controlled DNS mapping. They address similar problems but obtain the information differently. Sniffing requires recognizable data in the traffic and does not suit every protocol; FakeDNS requires both the query and connection to pass through the core. They can work together under a client's default policy, but define which target routing ultimately uses. If the domain in the log differs from the application's request, inspect target-overwrite behavior so an incorrect sniffing result does not replace the original target.

A temporary address returned by FakeDNS does not mean real DNS is no longer needed. The core may still need the real server address for the final connection, and GeoIP routing may also require real resolution. Configurations therefore commonly contain both FakeDNS and an ordinary resolver, with each handling a different stage. If the ordinary resolver's outbound is wrong, the domain may be restored successfully while the final connection still fails. Review mapping hits and real-address resolution separately in the logs.

Validate an enabled setup in four steps: confirm that the application receives a dedicated address; confirm that the connection enters TUN; confirm in the core log that the original domain is restored; then confirm that domain routing selects the expected outbound and completes the real connection. The first step alone does not prove success. If the browser works but one app fails, check whether it caches addresses, uses independent DNS, or bypasses the virtual network. Fully close the app and clear its connection state before testing again.

When rolling back, disable the FakeDNS server, address pool, and target-overwrite settings that depend on it, then restore ordinary DNS. Disabling only one component can leave dedicated addresses cached, causing the system to contact invalid targets for a while. Restart the client and test application after rollback and confirm that resolution returns real addresses. FakeDNS is suited to configurations with a clear need for domain-based routing that ordinary sniffing cannot cover; it should not be the default for every setup.

Multi-subscription management and update strategy

Treat subscriptions as external configuration sources

Managing multiple subscriptions is not about putting more servers in one list; it is about controlling external configuration changes. Each subscription can change names, protocol parameters, entry counts, and availability, so give it an independent name, update schedule, and disabled state. Keep subscription URLs only in the client's subscription manager; do not copy them into routing remarks, script output, or shared screenshots. If several devices need the same source, import it separately and create local groups by device purpose instead of assuming desktop and mobile need identical server sets.

For each source, record its purpose, client scope, last successful update time, and failure-handling procedure. This management timestamp belongs in your records, not in server names. Pause automatic updates for subscriptions that are no longer used, then delete them only after confirming that nothing depends on them. Deleting one directly may remove the active server or disrupt groups. v2rayN is well suited to managing multiple desktop subscriptions and reviewing differences in a larger list; v2rayNG and v2flyNG should retain only the sources the mobile device actually needs to reduce background updates and manual selection.

Stagger updates and review changes

Do not update multiple subscriptions in a batch at the same time. Start with a low-risk source, review additions, deletions, renames, and protocol changes, then continue to the next. If the active server is replaced, test a confirmed entry from the same source first. If many entries disappear, do not immediately update again or clear the list; preserve the current state and inspect the client log. Repeated actions can overwrite information that would have supported rollback. Automatic update intervals should not be excessively short, because frequent updates can repeatedly reshuffle the list during network changes or temporary source failures.

At minimum, review four items: whether the entry count changed unexpectedly; whether display names are still recognized by filters; whether the selected server remains; and whether protocol or transport parameters changed. A name change affects organization, while a parameter change can affect connectivity. If a source begins using different protocol capabilities, adjust the work group rather than merely editing display names. For subscription-format recognition and conversion boundaries, see V2Ray Subscription Formats Explained so share links, encoded lists, and native configurations are not treated as the same structure.

Deduplication, priority, and fault isolation

Deduplicate by connection identity, not display name alone. Compare the protocol, address, port, user ID, transport, and security parameters. Identical entries from different subscriptions may still have source value: if one source fails to update, another may continue to maintain the same server. Move duplicates to a lower-priority group to keep the daily list manageable while preserving rollback options. If the client lacks complex views, at least distinguish sources clearly in subscription names.

Priorities should serve stability. Assign fixed-purpose applications to continuously validated servers instead of mixing them with temporary test entries. Put test sources in a separate group and prevent them from becoming the default automatically. Automatic selection across multiple subscriptions should use only compatible candidates. Entries with major differences in protocol, transport, or network path do not belong in the same fast-switching group, or connection changes may be mistaken for DNS, routing, or application problems.

For fault isolation, first disable automatic updates and automatic selection, pin a known server, and inspect sources one by one. If every source fails, the problem is more likely in the local network, system capture, or shared configuration. If only one source fails, focus on its resolution, parameter changes, and entry status. If the same source works in v2rayN but fails in an Android client, compare core family, transport support, system network permissions, and mobile-network restrictions instead of copying every desktop setting.

Backup scope and recovery order

Backups should include subscription definitions, manual servers, custom routing, DNS, outbounds, and client preferences, but restore them incrementally. Restore subscriptions and one server first, then confirm the basic connection. Restore routing and DNS next, and TUN, FakeDNS, and custom outbounds last. When moving between clients, prioritize common connection parameters and rule intent; do not assume that every private field exported by one interface can be understood by another client.

Backup files contain sensitive configuration and should be stored only in controlled locations, never shared publicly. When showing a problem, remove subscription URLs, server addresses, user IDs, and authentication fields, keeping only structure-related fragments. Logs may also contain destination domains and connection details, so review them before sharing troubleshooting material. After recovery, start a new change log to avoid mixing an old backup with the current subscription state.

Effective multi-subscription management should achieve three outcomes: a problem with one source does not disrupt the entire configuration; updates make changes easy to identify; and removing or disabling a source does not break routing or outbounds. These outcomes come from stable naming, layered grouping, staggered updates, and explicit rollback paths—not from adding more automation switches. The more sources you have, the fewer implicit behaviors you should allow.

Custom outbounds, chained paths, and unified troubleshooting

Connect routing to outbounds with stable tags

A custom outbound is the execution target for a routing rule. Common base outbounds are proxy, direct, and block; complex configurations may add a specified server, a DNS-only path, or a chained upstream path. Give each outbound a stable, meaningful tag such as proxy, direct, block, or dns-out. Routing rules reference tags, not temporary display names in the interface. Before changing a tag, check every routing, DNS, and chaining relationship to avoid a configuration that parses correctly but references a missing object.

Keep the number of outbounds to a minimum. If two outbounds differ only by name while their protocol and path are identical, merge them and distinguish targets through routing rules. Create separate outbounds only when connection parameters, upstream paths, address families, or network policies truly differ. Numerous near-duplicate outbounds make logs harder to read and can point to stale servers after subscription updates. A graphical client may generate its primary proxy outbound from the current server; custom rules should reference a stable entry point rather than an internal tag that may be replaced.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

The example shows the basic structure of direct and block outbounds. Actual clients usually generate the proxy outbound automatically, so a manual snippet should not overwrite the server configuration maintained by the client. The freedom outbound's domain strategy controls how direct connections resolve destinations and should align with global DNS and the system's address-family support. Use blackhole to explicitly reject matching traffic; the application may show a timeout or connection failure, which is expected. Check the outbound tag to confirm that a rule took effect instead of relying on the application's wording.

Prerequisites for chained paths

A chained outbound sends a connection through one upstream outbound before establishing the next. It suits scenarios with a defined path requirement, but adds handshake layers, failure points, and log complexity. Before configuring one, verify that the upstream and final servers each work independently and decide which stage handles DNS resolution. If the upstream connection depends on the final path, a loop results. If both stages resolve domains differently, the final destination address may not be what you expect.

A chained path is not a universal stability fix. Each added stage introduces another connection setup, timeout, and parameter match. Validate the application, routing, and DNS with a single outbound first, then add the upstream path. During testing, record whether the first stage completes its handshake, whether the second stage starts, and whether the final target connects. If the log says only “connection failed,” start with the first stage instead of blaming the final server.

Avoid using dynamic automatic selection as a chained upstream unless every candidate has been verified for the same protocol capabilities and network behavior. Frequent upstream changes interrupt long-lived connections and alter the relationship between DNS and egress. A safer approach is to pin the upstream outbound, observe it for a while, and evaluate automation afterward. When chaining causes problems, the first rollback is to remove the chain and restore a single outbound, not to add more routing exceptions.

DNS-only outbounds and traffic isolation

A dedicated DNS outbound makes the query path clearer, but it must not create a bootstrap loop. The server address required by that outbound must be resolvable or directly reachable through the basic network, and routing must ensure that DNS traffic does not return to a proxy that itself needs that DNS to connect. After configuration, distinguish DNS queries from ordinary connections in the logs: confirm that resolution uses dns-out while business traffic continues to follow its original routing choices.

Traffic isolation can also send a particular protocol or port to a dedicated outbound, but the condition must be reliably identifiable. A port is not an application, and a process name does not represent every connection. Prefer destination domains, address sets, and explicit network types. When combining conditions, start with one condition in a test rule, confirm a match, then add restrictions. Writing a complex condition all at once makes a miss difficult to diagnose.

Unified troubleshooting order

When a complex configuration fails, use a standard rollback: disable automatic server selection and pin a known server; remove chained outbounds; disable FakeDNS; retain ordinary DNS; switch from TUN back to the system proxy; and restore routing to private-address direct access plus a default proxy. If it still fails, the likely cause is server parameters, the local network, or client startup. If the baseline works again, re-add each feature in the original order. The first step that fails is the primary suspect.

Read logs as a timeline. First look for configuration loading and syntax errors; then check whether the inbound received the connection; next see whether DNS returned a result, which tag the router selected, and whether the corresponding outbound began its handshake. Check only the failed stage and its direct dependencies. If the outbound handshake succeeds but page content is abnormal, inspect the application protocol, address family, or destination service rather than changing subscription groups. Temporarily increase the log level if needed, then restore the normal level after confirming the issue to avoid unnecessary records.

Troubleshooting material should include the client name, operating system, whether the system proxy or TUN is used, the single change made before the issue, key log stages, and the rollback result. Do not submit a complete subscription or full configuration. Controlled comparisons are more useful than many screenshots: does the same server work with the baseline, does the same configuration work on another network, and does disabling the new module restore service? These three results usually narrow the scope to the local system, core configuration, or server path.

After configuration is complete, save a structural description listing subscription sources, work groups, routing order, DNS paths, TUN exclusions, the FakeDNS address pool, and custom-outbound dependencies. Review each item after updating the client, core data, or subscriptions. If you need to reconsider client selection, read v2rayN vs. v2rayNG vs. v2flyNG. Use the Quick Start for basic operations; this page is for long-term maintenance and systematic troubleshooting.