V2Ray DNS Split Tunneling: Configure DNS for Mainland China and International Domains

1. DNS Split Routing Prerequisite: Queries Must Reach the Core

Setting a DNS server in V2Ray does not make every app on your computer use it. The built-in DNS handles lookups needed by the core, such as resolving IPs for routing decisions, resolving domains for some outbounds, and queries forwarded through a configured DNS inbound. DNS queries generated directly by apps only use these rules if they pass through an appropriate interception or forwarding path.

This flow describes one scenario: an app passes a domain to the proxy, and routing needs to resolve it. If a domain rule already selects a proxy outbound, the core may pass the domain to the remote server without looking up its IP locally. If the app resolves the domain first and sends the proxy an IP, the core may never receive the domain at all.

v2rayN is a desktop client. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Don't copy every setting across them just because their interfaces all have a DNS section. The examples in this guide use the traditional JSON structure common to V2Ray/V2Fly. Whether they load depends on your core version and the configuration generated by your client.

2. How the Built-In DNS Selects a Server

dns.servers can contain server address strings or server objects with domains. When a domain matches an object's rules, that server becomes a preferred resolver. If multiple objects match, their order in the list also matters. Don't treat the array as a simple setup where the first entry is always primary and the second is always a fallback.

1. Check static mappings and the cache. dns.hosts entries and existing cache data can affect results, so changing servers may not trigger a new network query immediately.
2. Select a server based on domain matching. For example, geosite:cn refers to domains in a rule set; it does not dynamically determine a domain's location from its suffix.
3. Handle failures and fallback. If the preferred server returns no usable result, the core may try servers eligible for fallback, if the configuration allows it. A server marked skipFallback: true is not a regular fallback candidate.
4. Return the lookup result. Results may also depend on the requested address family, expectIPs filtering, and version-specific behavior. Check the documentation and logs for your version to determine whether a retry will occur.

expectIPs filters the address ranges returned by a lookup, but it does not verify that results are authentic. Shared CDNs, cross-border deployments, and differences between rule sets can all cause valid results to be filtered out. Leave it unset when getting started, then test it separately once the query path is stable.

3. Separate DNS for Mainland China and International Domains

Here's a configuration snippet to merge into an existing setup: domains classified as mainland China use 223.5.5.5 first, while other domains use https://1.1.1.1/dns-query. The latter uses a standard DoH URL routed through the core, with destination IP rules selecting the proxy outbound. This is not a complete, ready-to-run configuration and does not include node details.

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "223.5.5.5"
        ],
        "port": "53",
        "network": "udp",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "1.1.1.1"
        ],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:geolocation-!cn"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

• Check outbound tags first. The direct and proxy tags must match the tag values of existing outbounds. A direct outbound typically uses freedom; the proxy outbound should use a node you've already verified works.
• Check the default outbound. In a traditional configuration, connections that don't match a rule typically use the first outbound. This snippet does not define one, so set the default outbound in your existing configuration. Don't assume uncategorized destinations will use the proxy.
• Keep existing rules. When merging this into a client configuration, preserve LAN, blocking, and necessary system rules, and check their order. The first matching routing rule takes effect.
• Prepare the rule files. geosite:cn, geosite:geolocation-!cn, and geoip:cn depend on the corresponding rule data. If categories are missing or files can't be read, fix the loading errors first.

The example's IP rule also matches other connections to the same address and port; it doesn't identify DNS traffic exclusively. For complex configurations, use a DNS query tag if your core supports it. Don't swap a standard https:// URL for https+local://, which has different local handling and routing behavior.

4. domainStrategy: When to Resolve and When to Keep the Domain

routing.domainStrategy controls how routing uses IPs when evaluating rules; it is not a switch that sends all DNS queries through the proxy. In particular, distinguish the routing module's field of the same name from domainStrategy in a freedom outbound. The former controls rule matching, while the latter concerns how a direct outbound handles destination domains. Their supported values are not interchangeable.

The example above uses IPIfNonMatch: domains clearly classified as mainland China or non-mainland China are routed by domain rules first. Only uncategorized destinations may be resolved and checked against geoip:cn. This is why not seeing a local DNS lookup when opening an international website doesn't necessarily mean the configuration is broken.

• To reduce local lookups, add reliable domain rules first. Don't start by switching to a more aggressive resolution strategy.
• If traffic is routed to the wrong outbound, check the first rule that matched and then verify the lookup result. Don't just change the DNS server.
• If the destination is already an IP, these three options can't recreate the original domain on their own. Recovery depends on conditions such as sniffed data or a FakeDNS mapping.

5. FakeDNS: Virtual IPs Require the Entire Traffic Path to Be Captured

FakeDNS returns a virtual IP mapped locally, not the website's real server address. When an app connects to that address, the core uses the mapping to recover the domain for routing or proxying. This addresses the loss of domain information when an app resolves a name before passing an IP to the proxy; it does not automatically encrypt DNS queries.

1. Make sure DNS queries are intercepted. If an app's lookup never reaches FakeDNS, no mapping will be created. Adding an address pool to the configuration alone does nothing.
2. Make sure traffic to virtual IPs returns to the core. Desktop TUN or Android VPN routing must cover the address pool, rather than send its traffic over the physical network.
3. Make sure the domain can be recovered. The inbound must use a FakeDNS sniffing setting supported by the core. A commonly used field is fakedns in sniffing.destOverride.
4. Make sure direct connections can resolve real addresses. After the domain is restored, a direct connection still needs an appropriate lookup. Don't connect to the virtual IP as if it were the real server address.

For a standard system proxy setup where apps can pass domain names, prefer normal DNS resolution. If you really need FakeDNS, first check the feature documentation for your client and core, and enable only one interception mechanism at a time. Don't change TUN, DNS hijacking, sniffing, and routing strategies all at once, or you won't know which layer caused the connection failure.

6. Verify the Configuration: Check Loading, Then DNS and Routing

When troubleshooting DNS, first distinguish a configuration load failure from a query timeout and a successful lookup followed by a connection failure. If a VMess or VLESS node is unavailable, DoH sent through that node will also time out. Conversely, a DNS response doesn't prove that the node handshake, TLS, or destination port is working.

1. Record a baseline. Save the working configuration and note the client version, active core and version, system proxy or VPN mode, and any per-app exclusions. Before and after updating a subscription, make sure the active node hasn't changed.
2. Restart the core after changes. After saving changes in the client's DNS settings or custom configuration, check the startup logs. If you see an unknown field, a rule data loading error, or a missing outbound tag, fix it before testing websites.
3. Temporarily increase log detail. Select debug level in the client's log settings and check the destination domain, DNS connection address, and outbound tag. Restore your usual log level after testing, and remove node addresses and browsing records before sharing logs.
4. Test each category separately. Choose a domain confirmed to be in the mainland China rules, one confirmed to be outside that category, and one uncategorized domain. Visit each three times and note the difference between the first lookup and cache hits.
5. Rule out caching last. Test again after restarting the app or core, and clear the system DNS cache if needed. Don't change the resolver, node, and rule files all at once.

ipconfig /flushdns
nslookup www.baidu.com 223.5.5.5

These are supplementary Windows checks: the first command clears the system DNS cache; the second queries a specified server directly. The second command bypasses the built-in DNS server selection described here, so it only checks basic reachability to that server and cannot confirm that split routing works. If the query fails, your local network may be blocking direct UDP port 53.

The goal isn't to send every domain to the same DNS server. Domain classification, the route used for DNS queries, and the route used for application traffic should work together. Anti-pollution settings can reduce exposure to untrusted query paths, but they can't guarantee that classifications are always accurate or replace connection logs, certificate validation, and regular maintenance.