V2Ray Advanced Config: Subscriptions, Routing, DNS, and TUN

02 / Subscription cleanup

Subscription groups and server filters

Subscriptions provide servers in bulk, but as the server count grows, selection becomes harder and mistakes become more likely. Effective organization does not mean putting every server into one long list. Group them by source first, then filter by purpose. v2rayN is well suited to keeping default groups, external subscriptions, and self-hosted servers separate. In v2rayNG and v2flyNG, subscription settings and note fields can distinguish sources. Keep group boundaries stable: server notes may change, but source, purpose, and maintenance ownership should not be mixed.

Give each subscription a recognizable name, such as “Daily,” “Testing,” or “Self-hosted.” Names should describe the source, not the current server status, because status changes over time. Keep manually added servers in a separate group instead of moving them into an automatically updated subscription group, where updates can make it difficult to tell whether they were overwritten. For subscriptions you no longer use, disable automatic updates and observe for a while before deleting the group; clearing it immediately also removes existing notes and selection history.

What should a filter solve?

Server filters narrow a long list of candidates. Common dimensions include note keywords, protocol type, transport, and subscription source. Filters should be explainable: after entering a keyword, users should be able to see from the server note why an entry matched. Complex regular expressions are flexible, but even small naming changes can cause entries to be missed. A more reliable approach is to keep notes in a consistent format within each subscription, then use region, purpose, or route category as keywords.

Filtering and routing are different tasks. Filtering determines which servers appear in the UI or are included in a batch test; routing determines which outbound handles a request after connection. Do not use server filtering as a substitute for traffic routing, and do not assume that a hidden server has been completely removed from the configuration. Some clients change only the displayed list; the active server may continue to work. Before deleting entries in bulk, confirm the selected items and group scope.

When to use keywords versus regular expressions

Simple keywords work well for everyday selection, such as filtering notes by “Work,” “Self-hosted,” or a protocol name. When you need multiple alternatives, use the regex alternation operator; when excluding test servers, use a negative condition, but validate it on a small set first. Filter entry points and regex support differ between clients, so before copying an expression, confirm whether it applies to the server note, address, or full display name. The expressions below illustrate general ideas and do not depend on any particular server count or speed data.

Work|Self-hosted
^(?!.*Testing).*
(VLESS|VMess|Trojan)

The first line matches entries whose notes contain “Work” or “Self-hosted”; the second excludes names containing “Testing”; the third filters by protocol terms in the display name. If a subscription uses a different naming scheme, inspect the actual notes before adjusting the expression. When no results appear, remove anchors and exclusions first to confirm that the basic keyword matches, then add constraints one at a time. Avoid writing a long expression immediately, or it will be difficult to identify which part caused the mismatch.

Handling updates, duplicates, and invalid entries

Update one subscription group at a time whenever possible. After updating, confirm that entries parsed correctly before switching the active server. The same server may appear more than once because its note differs, or because identical address and port values hide different parameters. When deduplicating, compare more than the domain and port: also check the user ID, protocol, transport, TLS settings, path, and other key parameters. Automatic deduplication is suitable for identical entries; when parameters differ, keeping both and renaming them is safer.

Invalid entries generally fall into three categories: temporarily unreachable, incorrectly configured, and withdrawn by the subscription source. One failed connection is not enough to declare an entry permanently invalid; try another local network or wait for the route to recover. Persistent protocol parsing errors call for checking whether the subscription uses fields unsupported by the current client. Entries that disappear after an update were usually withdrawn by the source, so copying them back into an automatically updated group is not recommended. Speed tests compare response under current network conditions; they are not a permanent ranking system.

How the three clients differ in group management

v2rayN offers more desktop list space, making it suitable for managing multiple subscriptions, batch updates, and detailed filtering; it is also the preferred desktop client. v2rayNG uses a touch-friendly list, so keep the number of enabled subscriptions small, use short names, and retain clear prefixes. v2flyNG follows similar Android management habits, but it belongs to a different core family; after importing the same subscription, confirm that protocols and transport parameters were recognized completely. When reinstalling or changing platforms, choose the appropriate client on the download page.

After organizing subscriptions, perform a recovery check. Note the active subscription and server, update one group manually, confirm that the update does not change self-hosted servers, then restart the client to verify that the selection remains. If the active item changes after an update, check whether automatic selection is enabled or whether the current entry was replaced by the subscription. A subscription URL is an ongoing access credential and should not appear in public screenshots, logs, or shared rule files; for troubleshooting, report only the parsing result and error type.

04 / Name resolution

DNS optimization and split resolution

DNS configuration determines how domains obtain addresses and also affects the handoff between domain and IP rules. System DNS, the client’s built-in DNS, encrypted DNS in the browser, and application-level resolvers may all coexist. When a query does not follow the expected path, you may see “the routing rule is correct, but traffic still uses the wrong outbound.” Before optimizing, identify the query source. A system proxy usually does not intercept every DNS request automatically; TUN is better suited to sending system queries through the client, but browser- or application-initiated encrypted queries still need to be handled.

The basic goal of split DNS is to send different domains to suitable resolvers and route the queries themselves through the correct outbound. Domain classification, resolver selection, and routing outbound are three separate decisions. Assigning a domain to a particular DNS server does not mean its application connection will use the same outbound; routing rules must enforce that separately. Conversely, writing only a business route without handling the resolution path may give the application an unsuitable address, which then triggers the wrong IP rule.

Server order and matching scope

The core DNS module can use multiple servers and attach domain match lists to them. Specific matches should come before general servers. Internal domains can use the LAN resolver, selected external domains can use encrypted queries, and all other domains can go to the default server. If the client supports a control such as skipFallback, it can prevent matched domains from being sent to fallback servers. Before enabling it, ensure that the dedicated resolver is stable; otherwise matched domains will have no fallback answer when that resolver fails.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "full:intranet.example",
          "domain:office.example"
        ],
        "skipFallback": true
      },
      {
        "address": "https://dns.example/dns-query",
        "domains": [
          "domain:service.example"
        ]
      },
      "localhost"
    ]
  }
}

The example sends internal domains to the LAN resolver, selected services to a sample encrypted resolver, and all other requests to the local resolver. In a real configuration, the encrypted resolver’s own hostname must also resolve and connect. Bootstrap resolution cannot depend on the same encrypted channel before that channel is available. Let the system or a basic DNS resolver resolve the resolver hostname first, or use the client’s supported bootstrap mechanism. If logs repeatedly show that the resolver hostname cannot be resolved, fix this dependency first.

Query strategy and address families

queryStrategy controls which address types are returned. UseIP permits any available address family, UseIPv4 requests IPv4 only, and UseIPv6 requests IPv6 only. Choose based on whether the local network and outbound path fully support the address family. If the system receives an IPv6 address but the proxy path cannot establish an IPv6 connection, the application may wait for failure before falling back, making the first visit noticeably slower. You can temporarily use an IPv4 strategy to verify the cause, but the long-term fix is to check IPv6 handling across the local network, server outbound, and routing rules.

Do not hide every resolution problem behind a fixed address family. Some services provide different access through different families, and internal LAN services may work only over one. After changing the setting, test internal domains, common public domains, and direct IP connections separately. If only one application is affected, check whether it has its own DNS or connection-optimization feature, because its queries may never enter the client.

How DNS and routing work together

A DNS query is also a network request, so routing determines whether it goes direct or through a proxy. When encrypted DNS uses an ordinary TCP or HTTPS connection, route it by resolver hostname or IP as needed. If the query goes through a proxy, make sure that outbound already has a reachable server address before resolution begins. This is especially important when a subscription server uses a hostname. The most reliable startup path lets a basic DNS resolver resolve the server hostname, then uses the established proxy for later dedicated queries.

With IPIfNonMatch, a domain-rule miss triggers DNS resolution before IP rules are evaluated. The addresses returned by DNS therefore directly affect routing. If a domain has multiple address sets, changing cached results can send traffic to different rules. Prefer stable domain rules where possible, and reserve IP rules for regional sets, private addresses, and targets that genuinely require address-based matching instead of manually maintaining addresses for every domain.

Caches, leak paths, and verification

When verifying DNS, disable the browser’s independent resolver or explicitly include it in the test. Reconnect the client, clear relevant system and browser caches, and perform a completely new query. Logs should show the domain, selected DNS server, returned address, and the routing result for the subsequent application connection. A web-based detection tool cannot reveal every system query path because it observes the current browser, not terminals, background services, or other applications.

If DNS is still handled by the local network under a normal system proxy, that reflects a difference in interception scope and is not necessarily a configuration error. Enable TUN only when you need broader interception, then define explicit DNS inbounds and routes. If enabling TUN causes a resolution loop, check whether DNS requests re-enter TUN, whether the resolver lacks a direct or proxy exception, and whether FakeDNS overlaps with real resolution rules. For a complete split-resolution example, see the detailed V2Ray DNS split-resolution configuration guide.

06 / Domain mapping

How FakeDNS works and where it fits

FakeDNS returns temporary addresses from a reserved pool for domains and stores the mapping between each domain and address inside the core. When an application connects to the temporary address, the core restores the original domain from the mapping and then performs routing and the real connection. This mainly solves cases where an application performs its own DNS lookup and then gives only an IP connection to TUN, causing the core to lose the original domain and domain rules to miss. FakeDNS preserves domain information until the connection stage, making split-routing decisions more reliable.

FakeDNS is not a replacement for a regular DNS server and does not improve every resolution path automatically. After the core restores a domain, the actual connection still needs to be resolved according to the configuration or passed to the appropriate outbound. If routing, real DNS, or the outbound is wrong, FakeDNS only makes the problem harder to observe. Enable it after the TUN baseline and ordinary DNS are stable, and define which queries enter FakeDNS and which internal domains must return real addresses.

Address pool and mapping capacity

FakeDNS configuration includes an address pool and mapping capacity. The pool must use a dedicated reserved range and must not overlap with the LAN, enterprise network, container network, or an existing virtual interface. With an overlap, the system may send a temporary address onto the real network or mistakenly send a real internal address to FakeDNS. Capacity determines how many domain mappings can be retained at once. When it is too low, old mappings are evicted and applications holding those addresses may no longer recover the domain. Keep the client default for normal use; adjust it only after confirming high concurrent domain volume and mapping eviction in the logs.

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

198.18.0.0/15 is a commonly used reserved range for benchmarking, and many implementations use it for virtual mappings. Still, check whether the local network or other tools already use it. This snippet represents only the core’s FakeDNS object. For queries to actually enter it, you also need matching DNS settings, inbound sniffing, and TUN interception. Adding the object alone does not change the system query path.

Sniffing and destination overrides

Inbound sniffing identifies domain or protocol information from connections. With FakeDNS, common destination overrides include HTTP, TLS, and FakeDNS mappings. Whether to enable destination overrides depends on the client template: they let routing use the restored domain, but may also change how special connections are handled. Start with the client’s standard FakeDNS mode, inspect the generated configuration, and customize only afterward. Do not enable every protocol-identification option at once.

{
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "tun",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "fakedns"
        ],
        "routeOnly": true
      }
    }
  ]
}

routeOnly means that the identified result is used primarily for routing and does not directly replace the final connection destination. This suits environments that want to minimize the impact of destination rewriting. Whether the field is supported depends on the current core and the client’s configuration method; use the client’s generated result as the authority. If the configuration reports an unknown field, remove the custom snippet, use the FakeDNS option in the UI, and then check that the core family matches the configuration format.

Targets that should not use FakeDNS

LAN domains, enterprise internal domains, printing, and discovery services usually need real addresses and should bypass FakeDNS in favor of the internal resolver. Applications that depend on local address checks, certificate binding, or special resolution results may also be unsuitable for virtual mappings. Keep exclusions specific: start with clearly identified internal domains and reserved suffixes, then observe for additional symptoms. Excluding every broad domain range defeats the purpose of retaining domains with FakeDNS.

Some applications validate the addresses returned by DNS, bypass system resolution, or use their own encrypted queries. The first two cases may prevent FakeDNS from working; the third may send the query into TUN as an ordinary HTTPS connection, leaving the core to infer the domain from connection characteristics. If FakeDNS queries do not appear in the logs, do not repeatedly change the address pool. First confirm whether the application’s query enters the client.

A practical order for diagnosing common failures

If resolution stops completely after enabling FakeDNS, first check whether DNS sends queries to FakeDNS. If a temporary address is returned but the connection fails, check whether TUN intercepts that address range and whether the inbound can restore the domain. If only internal services fail, check internal-domain exclusions and the LAN resolver. If failures appear intermittently after some use, check mapping capacity, application caches, and resume-from-sleep behavior. Each symptom belongs to a different layer; changing the DNS server cannot solve them all.

During verification, check whether queries return reserved addresses, then confirm in core logs that the same address maps back to the original domain and inspect the final outbound. Do not use a system tool to connect directly to a temporary address as a server-reachability test; it does not represent the real server. After disabling FakeDNS, clear relevant application and system DNS caches so applications do not continue using expired temporary addresses.

Using FakeDNS alongside real DNS split routing

A mature configuration often uses FakeDNS and real DNS together: public domains can receive temporary addresses to preserve their names, internal domains can query the LAN resolver for real addresses, server hostnames can use basic DNS during startup, and selected services can use dedicated encrypted queries. Give each domain group a clear priority so the same target is not matched by the internal resolver and FakeDNS at the same time. After changes, test public webpages, internal services, server reconnection, and system sleep and resume separately to confirm that mappings can be rebuilt throughout their lifecycle.

08 / Outbound orchestration

Custom outbounds, chained forwarding, and systematic troubleshooting

An outbound is the final target of a routing decision. Common outbounds include proxy servers, direct connections, blocks, and forwarding to a local or upstream SOCKS service. Custom outbounds are useful for sending a specific workload through a dedicated exit, reusing an existing local service, or creating a clear test path. The essentials are unique tags, complete protocol parameters, and no circular dependencies. Routing references outbounds only by tag, so renaming one requires updating every rule that uses it.

GUI clients generally generate the primary proxy outbound from the active server and add direct and block outbounds. When extending the configuration manually, do not overwrite these base objects unless you have confirmed how the client merges them. A safer approach is to use the client’s custom configuration, preconfiguration, or template entry point, create a unique tag, and test it with one specific route. Direct edits to runtime files disappear after a server switch or restart and may also make the UI state disagree with the actual configuration.

Add a local SOCKS upstream

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

The example creates an outbound named local-socks and sends connections to the SOCKS service listening on port 1081 on the local machine. Before using it, confirm that the port is listening and prevent its traffic from being captured by the same TUN and sent back to itself. If the upstream requires authentication, add the actual credentials in a configuration structure supported by the client and keep them local. During testing, point one clearly identified domain to this outbound instead of switching all traffic at once.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:service.example"
        ],
        "outboundTag": "local-socks"
      }
    ]
  }
}

Tags in rules must exactly match outbound tags. If the configuration fails to load, first check the JSON structure, duplicate commas, and field placement. If it loads but does not use the upstream, check rule order and domain matching. If it matches but the connection fails, check the local port, upstream authentication, and routing loops. Layered checks are faster than repeatedly changing servers.

Risk control for chained forwarding

Chained forwarding makes one outbound establish its connection through another outbound. It suits environments with a clearly defined network topology, but adds resolution dependencies, connection layers, and failure points. Before starting, draw the path: which inbound receives the application, which business outbound the route selects, which front outbound that outbound uses, and who resolves the server hostname. Any segment that returns to an earlier entry point can create a loop.

Do not implement a chain through vague global rules. Give the front and business outbounds explicit tags, route upstream server addresses directly or through a designated outbound as needed, and keep a basic connection outside the chain for fallback. When a timeout occurs, test each hop separately before combining them. If every hop works alone but the combination fails, focus on DNS bootstrap dependencies, UDP support, and TUN recapturing the upstream connection.

Direct and block outbounds

Direct outbounds are for LAN targets, internal services, and destinations that do not need a proxy. Block outbounds explicitly reject connections. Block rules should be specific and placed before broad proxy rules. Broad classifications can affect login, payment, updates, or embedded resources, so verify both the page’s main domain and its resource domains after adding one. If the goal is only to keep one application off the proxy, prefer process rules or inbound isolation. If the client and core cannot identify processes reliably, use explainable domain and IP conditions instead.

Direct does not necessarily mean bypassing every client layer. Traffic may enter TUN first and then be sent by the core to a direct outbound, or it may bypass TUN at the system-routing layer. These approaches differ in their effects on logs, DNS, and compatibility with local services. If you need unified routing and logging, let traffic enter the core and then connect directly. Traffic sensitive to LAN discovery or device access is usually better bypassing TUN at the system-routing layer while retaining direct rules for private addresses.

Build a troubleshooting matrix from the logs

Advanced configuration troubleshooting should answer four questions: did traffic enter the client, who resolved the domain, which route matched, and did the final outbound establish a connection? Increase log verbosity only during troubleshooting and restore the normal level afterward to keep logs manageable. If no target request appears, check the system proxy, application proxy, or TUN. If there is a request but no domain, check DNS interception and sniffing. If the routing tag is wrong, adjust rule order. If the outbound connection fails, check the relevant server and upstream.

Build a configuration that remains maintainable

A maintainable configuration should minimize dependencies on server names, temporary addresses, and UI ordering. Routing should reference stable outbound tags, DNS should use explicit domain groups, subscriptions should preserve source boundaries, and TUN and FakeDNS should be enabled only when needed. Document the purpose of every custom object and keep a working baseline. When a failure occurs, disable the most recently added object, confirm that the baseline returns, and narrow the issue to one rule or outbound.

After completing the configuration, perform four acceptance rounds: restart the client to confirm that the configuration loads; switch servers to verify that routing does not depend on the old server; update subscriptions to confirm that custom groups and tags were not overwritten; and restart the system to verify that TUN, DNS, and the system proxy are established and restored correctly. One successful webpage visit is not enough. For internal networks, also test LAN services, internal domains, and recovery from system sleep.

If the issue is still unclear, return to the quick-start path and verify the minimum connection, then check the Help Center for installation, configuration, and troubleshooting entries. For system proxy, DNS, or speed differences, continue with the layered case studies in the site’s technical notes.