V2Ray DNS Split Tunneling: Configure DNS for China and Overseas Domains

Separate resolver selection, DNS routing, and website routing

“DNS split tunneling” involves at least two separate decisions: which resolver handles a domain, and which outbound connection carries the query to that resolver. Website connections require a third decision. Entering an overseas DNS address does not mean the query goes through the proxy; routing website traffic through the proxy does not automatically send the browser's earlier local DNS lookup through the core either.

V2Ray/Xray's dns object configures the built-in resolver; routing determines which outbound connection a request uses. geosite:cn is a set of domain rules, while geoip:cn is a set of IP address rules. They are not interchangeable. If the app does not pass the domain to the core, a connection containing only an IP address cannot be matched directly against domain rules. Traffic sniffing can sometimes recover domain information, but it should not be treated as a fix that works for every protocol.

Mainland China DNS and remote DoH: define their roles first

This example uses 223.5.5.5 for domains in mainland China and https://1.1.1.1/dns-query for other queries. These are examples of public resolvers that can be replaced, not universally optimal settings. The first typically uses UDP port 53; the second uses HTTPS port 443. Encryption protects queries in transit between the client and resolver, but the resolver can still see the domains it processes.

UseIPv4 limits initial troubleshooting to IPv4, avoiding IPv6 routing issues at the same time; it is not a general recommendation to disable IPv6 permanently. If both the network and server support IPv6, switch to UseIP after the baseline works, then check A and AAAA records separately. The DNS query strategy does not replace system-level IPv6 routing settings.

Example dns.servers configuration: domain matching and fallback behavior

These are core configuration snippets, not complete server configurations that can be imported on their own. The examples target the Xray core used by v2rayNG; v2rayN users should also confirm which core is selected. Back up your configuration before making changes. If the client generates the configuration, edit the relevant DNS settings or custom configuration entry rather than a temporary runtime file that will be overwritten on the next launch.

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

• domains specifies which resolver to prefer for matching domains; it is not an access-control rule that limits what the resolver can look up.
• skipFallback: true means this server is excluded from general fallback. It does not mean that other servers are forbidden if this one fails.
• A DoH server without a domains restriction acts as the default resolver. With the configuration above, failed lookups for domains in mainland China may still fall back to it. This is split DNS with fallback, not strict isolation.
• tag provides a routing identifier for queries sent by the built-in DNS; it is not a DNS service listening on local port 53.

To restrict matching domains to their specified server, consider Xray's disableFallbackIfMatch. Before enabling it, confirm that the current core supports the field and that you accept resolution failing whenever the designated resolver is unavailable. Avoid changing fallback, caching, and IPv6 settings all at once, or a failure will have several possible causes.

Example routing configuration: send remote DNS through the proxy

The snippet below assumes the existing configuration has a working proxy outbound tagged proxy and a direct outbound tagged direct. The tags must exactly match the actual outbounds[].tag values. This example has no catch-all rule at the end, so unmatched connections use the first outbound; that means the first outbound must be proxy. If your configuration uses a different default policy, adapt the snippet to its existing structure rather than replacing it as-is.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "dns-internal"
        ],
        "ip": [
          "223.5.5.5"
        ],
        "port": "53",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": [
          "dns-internal"
        ],
        "ip": [
          "1.1.1.1"
        ],
        "port": "443",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

The first two rules match only built-in DNS queries, so other connections to the same IP addresses are not treated as DNS requests. The last two rules handle website connections. IPIfNonMatch means that if a domain connection does not match an existing rule, the core then tries to resolve its IP and match against IP rules. It does not choose a DNS server or automatically route DNS queries through the proxy.

DoH vs. FakeDNS: encrypted queries and virtual IPs are different things

DoH sends DNS messages over HTTPS, primarily protecting queries in transit. FakeDNS returns a virtual IP address to the app and maintains a mapping between that address and the domain, allowing subsequent connections to be handled by domain. FakeDNS does not host the real website at the virtual address, nor does it mean that the domain has already been resolved to its real address remotely.

For example, if you use 198.18.0.0/15 as the FakeDNS IPv4 address pool, the system must route connections to that range back through the core so it can recover the corresponding domain. If a connection bypasses the VPN or TUN path, the virtual IP won't work like a real public address. If only some apps fail after enabling FakeDNS, check per-app proxy settings, the capture scope, and mapping handling before switching servers.

• If standard DNS split routing hasn't been verified yet, leave FakeDNS off and use real addresses as your troubleshooting baseline.
• If an app passes only the destination IP and domain rules aren't matching, then evaluate FakeDNS alongside the current inbound and sniffing settings.
• If virtual addresses persist after disabling FakeDNS, clear the relevant app and system caches, then reconnect to avoid using stale mappings.

Verify each setting in v2rayN and v2rayNG

The client interface and core configuration are separate layers. The same “remote DNS” field can generate different configuration structures in different client versions, so check the configuration actually loaded by the core. In v2rayN, check log-related settings under Settings → Parameter Settings, then review startup results in the log area of the main window. DNS editor labels can change between versions; don't mistake a basic single-line address field for a full JSON editor.

1. Record your baseline. Note the server, current routing mode, DNS addresses, and system proxy or VPN status. In v2rayNG, check the DNS-related settings under Settings. After making changes, stop and restart the service, then confirm the logs show no configuration errors.
2. Check startup errors. Resolve issues such as unknown fields, missing outbound tags, or failed geosite data reads first. If the core hasn't started correctly, browser tests can be misleading.
3. Check whether the app submits the domain. For desktop testing, use a SOCKS request that supports remote DNS resolution. The command below assumes the local SOCKS port is 10808; change it to the actual port if your configuration differs.
4. Check which routing rules match. Temporarily enable more detailed logs, then visit domains in mainland China and overseas to confirm the outbound used for DNS queries and website connections. Restore your usual log level after testing to avoid recording unnecessary browsing details.
5. Rule out cache issues. Restart the core and close existing connections before testing again. On Windows, run ipconfig /flushdns to clear the system cache, but you may also need to clear the browser or app's own cache.

curl --proxy socks5h://127.0.0.1:10808 --head --max-time 15 https://www.example.com/

socks5h tells curl to pass the domain to the SOCKS proxy; with socks5, the local machine typically resolves it first, so the two tests use different paths. This command only confirms that the domain enters the proxy path; it cannot by itself prove that all DNS queries are split as intended. Another common pitfall is running only nslookup www.example.com 223.5.5.5: it queries the specified resolver directly and can verify that resolver is reachable, but it cannot prove the built-in DNS rules are working.

Troubleshooting: DNS timeouts, unexpected addresses, and settings that don't apply

Keep a configuration you can explain: which domains use DNS in mainland China, which resolver handles default queries, which outbound carries DNS traffic, and what happens to websites that don't match a rule. Change one variable at a time and verify with startup logs and connection results; this makes issues easier to pinpoint than stacking multiple public DNS servers at once.