Advanced V2Ray Configuration
Routing, DNS & TUN

01 / Configuration Sources

Subscription Groups & Server Filters

What Groups Do—and Don't Do

Subscription groups organize configuration sources; they don't route traffic. A group typically stores a subscription URL, update options and the server entries generated from that source. Moving a server into a group won't automatically route particular websites through it. The active connection and routing rules determine which outbound a site uses. Keep these roles separate to avoid mistaking list organization for network policy.

In v2rayN, open subscription group management, create a clearly named group, then enter the subscription URL provided by the source. Name groups by purpose or source—for example, “Everyday” and “Backup”—rather than using hard-to-distinguish initials. Save the group, update it, then check the server list to confirm the imported entries. Menu locations vary between versions, so look for the feature by name and description.

Subscription URLs often contain access credentials, so treat them like account details. Hide the URL and QR code before sharing screenshots, and never paste the full link into public logs. A URL opening in a browser doesn't guarantee that it returns data the client can use. A login page, notice or converted response may be downloaded as plain text, leaving the update marked as complete but no usable entries in the list.

Filter Servers

Filters can narrow the visible list or control which entries are kept after an update, but their scope varies by client. Some affect only what's displayed; others exclude entries during subscription parsing. Start with a simple name keyword and verify how the filter works: note what appears before, save the condition, update the group, then clear the filter and check again. Combine conditions only after you understand their effect.

If the input explicitly supports regular expressions, use the pattern below to match either of two purpose words in a name. The pipe means “or,” and parentheses group alternatives. Pasting a regex into a plain-text search field won't have the same effect. Names come from the subscription source and may change; region abbreviations, rate labels and protocol names aren't consistently formatted, so keep filters broad.

(Daily|Backup)

First check whether the filter is set to include matches or exclude them. The same expression produces opposite results in each mode. If the list is empty, don't reinstall the client. Clear the filter, select all groups, remove any search term, then update a single source. If the entries reappear, the issue is with display or filtering—not the server connection settings.

Updates & Manual Changes

Subscription entries are usually regenerated from remote data. Direct edits to an entry's address, port or transport settings may be overwritten on the next update. For changes you need to keep, copy the entry into a separate manual profile with a distinct name, and note when and why you made the copy. This preserves the original subscription entry while making it clear which profile is no longer managed by the source.

On Android, manage subscriptions from v2rayNG and v2flyNG by source as well. Importing a QR code is useful for a single profile; importing a subscription is for ongoing batch updates. These are different data relationships. When moving from another device, identify whether the export contains a single connection, a subscription URL or the app's complete settings, then use the matching import option. Don't keep trying unrelated formats.

If an update fails, keep your existing working entries and check the system clock, whether the subscription has expired, and whether the update request requires an existing proxy. Some clients can update through the active proxy; others use a direct connection. Start with one group and a network path that you know is reachable, then consider automatic updates after it succeeds. Don't make every source depend on an untested connection.

Once the list is organized, choose one profile as a test baseline and leave automatic switching and complex filters off for now. Confirm the connection works with the standard system proxy before moving on to routing and DNS. Source management answers “Where did this profile come from?”; connection testing answers “Does it work?” Track these checks separately to narrow down later issues.

03 / Name Resolution

DNS Configuration

The DNS Resolution Path

Start DNS tuning by making the query path consistent, then consider response speed. A single connection may involve the system resolver, a browser's encrypted DNS, client-side DNS and resolution by a remote server. To know whether a change helped, identify who sends the query, which outbound it uses and who consumes the result. Changing one server address alone rarely controls the entire resolution path.

A system proxy mainly forwards requests from apps that follow proxy settings; it doesn't necessarily capture system DNS. A browser may send a domain to the proxy or resolve it locally first. Other programs may contact a fixed DNS address directly. So adding a DNS server in the client doesn't mean every query on the device will use it. Check browser settings, system network settings and the scope of the client's DNS capture separately.

Choose remote or direct DNS according to your routing goals. For direct destinations, a resolver reachable on the current network is often appropriate. For proxied destinations, confirm that DNS requests follow the intended path. If an encrypted DNS server is specified by hostname, that hostname must be resolved first. This bootstrap lookup can create a dependency loop if it relies on the resolver it's trying to reach.

Core DNS Example

This is a partial dns object for the main configuration. It directs mainland China domains to a specified server and uses a DoH address for other queries. The example illustrates how to assign resolvers by domain; it isn't suitable for every network. Verify which outbound carries DoH requests with the specific core and configuration in use. Don't assume they use a proxy just because of the address prefix.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

domains specifies which domains should preferentially use a server, but what happens after a failed query also depends on fallback options and the core implementation. It isn't a strict network isolation policy. To ensure a class of queries never reaches another resolver, check the fallback fields and failure behavior supported by your core, then verify the actual network path. Don't rely on this snippet alone.

Here, queryStrategy limits the core's DNS query strategy. It doesn't disable IPv6 in the operating system or stop every app from making its own queries. Choosing IPv4 can help isolate dual-stack issues, but it's not a general speed boost. If your network and server handle IPv6 correctly, test it separately before deciding whether to keep IPv4-only settings. Don't hide a problem indefinitely.

Caching & Layered Testing

After changing DNS settings, old results may remain cached by the system, browser, app or core. Close the target app and restart the client, then flush caches using the method provided by your system. Compare results for the same domain and note the resolved address and actual connection address. Reloading a page once doesn't prove the new settings took effect: resources may be cached locally or use a reused connection.

If an address works but its domain doesn't, start with DNS. If the domain resolves but the connection fails, check routing and the remote connection next. A successful lookup only means an address was returned; it doesn't mean that address suits the current network path. Some services return different endpoints based on the resolver's location. Sending a direct-resolved address through a remote outbound can cause unnecessary detours or connection failures.

If only the browser is affected, temporarily turn off its custom Secure DNS and test again with system settings. If only one app has a problem, check whether it uses its own resolver or a fixed address. Decide on the final policy after testing. Temporarily disabling a setting helps narrow down the issue; it isn't a recommendation to use one DNS setup on every network.

Client form fields such as “Remote DNS” and “Direct DNS” may be converted by the configuration generator into multiple core objects. Prefer configuring DNS through the same set of form fields rather than adding a conflicting setup in custom JSON. If you need manual changes, inspect the generated file for duplicate objects and overrides, then document the working changes separately.

05 / Domain Mapping

FakeDNS

Virtual Addresses & Original Domains

FakeDNS returns a virtual address from a configured pool for a domain and keeps a mapping between the address and domain. When the app connects to that virtual address, the paired traffic entry restores the original domain and passes it to routing and the outbound. FakeDNS isn't a public resolver and doesn't give the destination website a new address. Its purpose is to preserve domain information and reduce the impact of local resolution on later routing decisions.

This mechanism requires DNS queries and connections to follow the same controlled path. If only the DNS query goes through FakeDNS and the subsequent connection bypasses the client, the app will try to reach an address that isn't the real server. Conversely, if the connection reaches the client but the browser resolves the domain using its own encrypted DNS, the client may never create a mapping and can't restore the domain as expected.

Don't treat FakeDNS as an ordinary DNS server address to enter in system settings. First confirm that the client and traffic entry component explicitly support the relevant mode, then configure DNS capture, address-pool routing and mapping restoration using the same implementation. The TUN component managed by v2rayN may use its own virtual address mechanism. Similar feature names don't mean you should enable a second, core-level FakeDNS setup as well.

Xray Partial Configuration

This example shows three related layers in Xray: the top-level address pool, the DNS server list and a sniffing object to merge into the target inbound. The pool uses a reserved benchmarking address range, not public destination addresses. This snippet doesn't create a transparent inbound or add system routes; without those requirements, copying it won't enable FakeDNS across the device.

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

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "routeOnly": false
  }
}

ipPool defines the virtual address range, and poolSize sets the mapping pool capacity. Pool addresses are identifiers, not real remote destinations to send through a direct outbound. Before configuring the pool, check whether your LAN, other tunnels or test networks already use the same range. Overlapping addresses can send some connections to the wrong physical or virtual interface.

In destOverride, fakedns restores the destination from its mapping. This example explicitly sets routeOnly: false because restoring the domain only for routing while keeping the virtual address as the actual connection target wouldn't achieve the intended result. Regular HTTP or TLS sniffing and FakeDNS mapping are different mechanisms; don't treat them as interchangeable just because their field names look similar.

Compatibility & Troubleshooting

After enabling FakeDNS, check whether a regular domain resolves to an address in the configured pool, then verify that its connection is restored to the correct domain. If the result is still a real public address, check whether the query enters the intended DNS path. If you get a virtual address but the connection fails, check that traffic to the pool returns to the paired entry component and that it uses the same mapping state.

Some programs check address types locally, reject reserved addresses or pass resolved addresses to another device. FakeDNS may not suit these cases. LAN device discovery, services that require real addresses and certain network diagnostic tools may need real-DNS exceptions configured as the client supports. An exception must cover both DNS and routing; setting the virtual address range to direct alone isn't enough.

After a restart, the system or an app may still have an old virtual address cached even though the new process has a different mapping table. This can cause partial failures after restarting even if everything worked before. Clear relevant caches and restart the target app before deciding the configuration is wrong. Don't add old virtual addresses to permanent hosts entries or save them as fixed service addresses.

If ordinary DNS and domain sniffing already meet your routing needs, there's no reason to enable FakeDNS just to add more settings. It's for specific cases where domain information needs to be preserved, not a universal network optimization. Test it with one app, keep a configuration backup that's easy to restore, then expand use gradually if it helps.

07 / Outbound Design

Custom Outbounds

Tags & Protocol Objects

An outbound defines how to establish the next connection after receiving traffic. outboundTag in a routing rule is only a reference; it must match the tag of an actual outbound object. Tags are case-sensitive, so use short names that clearly describe their purpose. A rule pointing to a missing tag won't create a connection automatically and may cause errors during startup checks or forwarding.

First distinguish client-generated outbounds from manually added ones. v2rayN usually generates a remote connection object from the selected server, and switching servers may recreate it. Direct edits to a temporary file may be lost on restart. Use the client's documented custom configuration option and confirm whether it merges with, replaces or takes over the main configuration.

This standalone example defines direct and blocked outbounds, plus one that forwards traffic to another SOCKS service on the local machine. It doesn't include remote server credentials. It assumes that service is listening at the specified address and isn't the current entry point. Check the listening port before copying this; forwarding traffic back into the same processing chain can create a loop.

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

freedom means the core makes a direct connection from its current network context; it doesn't bypass every other networking tool on the machine. If the system's default route points to another tunnel, a direct outbound may still use that tunnel. To identify the actual path, check both operating system routes and client logs. A tag named direct doesn't prove that traffic uses the physical network.

blackhole discards matching traffic. A block outbound is useful for destinations that should never connect, but it shouldn't be a default patch for configuration mistakes. If a service fails, check whether it matched a blocking rule before changing anything else. Silent drops can cause long waits, so list and verify block rules separately during troubleshooting.

Connect Rules & Set the Default Outbound

The rule below routes a documentation example domain through the local SOCKS outbound. Add it before any broad fallback rule. The example domain is for syntax only; replace it with the target your use case requires. For a larger service, identify its actual request domains instead of routing every port through the local service and changing the path for unrelated apps.

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

When no rule matches, the core usually uses the default outbound, often related to the first item in the outbound array. The example above puts direct first, so replacing the original configuration with this snippet doesn't mean unmatched traffic will still use the proxy. Keep the existing remote outbound and set the fallback deliberately, or check the array order to ensure it matches your intended behavior.

Chaining Limitations

Forwarding traffic to a local service and chaining outbounds inside the core are different configuration approaches. The first connects to another listening port and lets that service handle the traffic. The second depends on chaining fields supported by a particular core. Field names and behavior vary between cores; don't copy transport settings from one implementation to another. Prefer a method the client explicitly supports and makes easy to inspect.

After adding another hop, test each segment separately. First verify the local SOCKS service, then confirm the core can connect to its port, and finally check that the routing rule matches. If each hop works on its own but the full chain fails, check where DNS is resolved, UDP support and any additional encapsulation requirements. Change one side at a time so you can identify what caused the result.

Once a custom outbound is stable, document its purpose, tag mapping and recovery steps. Keep sensitive connection settings in the protected client configuration, not in ordinary maintenance notes. Change only the rules you need day to day, rather than rewriting every outbound when a subscription changes. Keeping source management separate from outbound design makes updates and rollback easier to control.