V2Ray DNS Configuration Guide: Split DNS for Mainland China and Overseas Domains

Routing rules in V2Ray or Xray determine which outbound handles a connection, while DNS configuration determines how a domain is resolved before IP-based routing decisions begin. Even when both are configured correctly on their own, they can still conflict: an overseas domain may be resolved locally first, a remote DNS request may bypass the proxy, or the result may point to the wrong region. A reliable split-routing setup must coordinate resolver selection, the query path, and the final outbound.

Quick overview

This guide is for users who can already edit V2Ray or Xray JSON configuration but are dealing with DNS pollution, slow first loads, or DNS leaks. Once configured, domains in mainland China use a local resolver first, while overseas domains use remote DoH through the proxy. Logs and port tests then verify that queries follow the intended path.

Where split DNS fits in the connection path

When an application accesses a domain, the first requirement is a reachable address. If the routing rules contain only geoip:cn, the core must resolve the domain before it can match the result against the IP database. With geosite:cn, the domain can be matched directly, but resolution is still required when the connection is established. Resolver selection is therefore not an afterthought once routing is complete; it is the key link between domain rules and IP rules.

Application sends query Core takes over domain Select resolver Match routing rules Connect to destination

In a typical desktop setup, the local SOCKS inbound listens on 127.0.0.1:10808, while the HTTP inbound listens on 127.0.0.1:10809. Traditional DNS usually uses UDP or TCP port 53; DoH wraps queries in HTTPS and uses port 443. Different ports require different routing rules: intercepting port 53 alone cannot control DoH requests sent directly by a browser.

Traditional DNS port

443

Common DoH port

10808

Typical SOCKS inbound

10809

Typical HTTP inbound

In one comparison test, the local resolver took a median of about 18 ms to resolve a site in mainland China, while remote DoH through the proxy took about 126 ms. Sending every domain to a remote resolver adds round-trip time to first loads of local sites; sending every domain to a local resolver can return unusable or regionally unsuitable addresses for overseas sites. Choosing the resolver by domain category works better than chasing a single ideal DNS address.

Conclusion: choose the resolver first, then the connection outbound

Use a low-latency local DNS resolver for domains in mainland China and remote DoH through the proxy for overseas domains. Then let the same geosite rules decide whether connections go direct or through the proxy, keeping DNS categories aligned with routing categories.

What `servers`, `hosts`, and query strategies do

dns.servers is the resolver list. It can contain plain addresses or objects with matching conditions. An object's domains field specifies which domains should be sent to that server first, while expectIPs checks whether returned addresses belong to the expected range. Server order affects default selection and fallback, so local and remote DNS servers should not simply be stacked in an arbitrary array.

Field	Purpose	Typical configuration	Common failure
`servers`	Define resolvers and their domain-matching scope	Match mainland-China DNS with `geosite:cn`	All domains fall under the same resolver
`hosts`	Pin or rewrite resolution results inside the core	Use a fixed remote DoH service address	The DoH hostname repeatedly resolves during startup
`queryStrategy`	Control whether to query IPv4, IPv6, or both	`UseIPv4` or `UseIP`	Return an address family unreachable on the current network
`expectIPs`	Validate which IP set the result belongs to	Match mainland-China results with `geoip:cn`	An invalid result continues into the connection stage

hosts is not the system hosts file; it is a static mapping inside the core. It is useful for resolver startup dependencies and for pinning local network service names. For example, mapping domain:router.example to 192.168.1.1 keeps that name from being sent to an upstream DNS server. Do not maintain large lists of frequently changing website addresses here, or stale entries will cause connection failures.

UseIPv4: query or use IPv4 only. This suits networks without a stable IPv6 route.
UseIPv6: use IPv6 only. The local network, node, and destination path must all provide working IPv6.
UseIP: let the core handle IPv4 and IPv6 according to available capabilities. This suits dual-stack paths, but check the system's address-family preference.

Configuration blueprint: local resolution in mainland China, remote resolution overseas

The following fragment follows the Xray 25.x configuration structure and assumes the existing outbounds already include the tags direct and proxy. Domains in mainland China go to 223.5.5.5; overseas domains go to remote DoH. The remote resolver's address is pinned through hosts, so the core does not have to query local DNS first just to find the DoH host during startup.

{
  "dns": {
    "hosts": {
      "cloudflare-dns.com": [
        "1.1.1.1",
        "1.0.0.1"
      ],
      "domain:router.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://cloudflare-dns.com/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "queryStrategy": "UseIPv4",
    "disableFallbackIfMatch": true
  }
}

skipFallback means this local server is not used as a general fallback resolver for other categories. disableFallbackIfMatch limits cross-group fallback once a domain has matched a designated server. As a result, a failed remote resolution for an overseas domain surfaces the error instead of silently switching to local DNS and creating intermittent-looking pollution problems.

First confirm that the current core can load geosite:cn, geosite:geolocation-!cn, and geoip:cn data.
Merge the example dns block into the existing configuration; do not overwrite the inbounds, outbounds, or policy groups.
Make sure the direct and proxy tags exactly match the actual outbound tags. Tags are case-sensitive.
Start validation with UseIPv4. Evaluate UseIP only after confirming that the dual-stack network is stable.
After starting the core, check the logs for failed to load geosite and resolver connection timeouts.

When using the v2fly core, some Xray extension fields may be unrecognized. With v2flyNG on the v2fly core, follow the fields actually supported by that core: keep hosts, servers, and the basic query strategy first, then add fallback controls one at a time. With v2rayNG on the Xray core, the Xray structure above can be used, but the client's bundled core version must still be checked.

How `domainStrategy` works with DNS rules

Common values for routing.domainStrategy include AsIs, IPIfNonMatch, and IPOnDemand. AsIs keeps the domain form whenever possible and does not resolve it proactively for IP rules. IPIfNonMatch resolves the domain only when no domain rule matches, then tries the IP rules. IPOnDemand triggers resolution earlier when IP data is needed during matching. For mainland-China and overseas split routing, start with explicit geosite rules and use IPIfNonMatch for destinations identifiable only through IP rules.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32",
          "1.0.0.1/32"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:geolocation-!cn"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

Rules are matched in order. This example sends the two remote DoH addresses through the proxy first, then processes overseas domains, mainland-China domains, and mainland-China IPs. A leading direct rule for geoip:private is usually fine, but do not place an overly broad 0.0.0.0/0 rule before it, or later split-routing rules will never run.

Conclusion: put domain rules before IP fallback rules

Use geosite first to identify a domain's category. Only when no domain rule matches should IPIfNonMatch resolve it and try geoip. This reduces unnecessary queries and makes it easier to tell from the logs which rule actually took effect.

If the Freedom direct outbound has its own resolution strategy, make sure it does not conflict with dns.queryStrategy. For example, if DNS returns IPv4 only while Freedom is forced to use IPv6, a domain may match the direct route but have no usable address during connection. When troubleshooting, search the entire configuration for every domainStrategy and queryStrategy, not just the top-level DNS block.

Practical checks to prevent DNS pollution and leaks

A DNS leak usually means that a domain query which should go through the proxy is sent directly by the system, local router, or an application's own resolver. Configuring remote DNS inside the core alone does not take over every application's queries. The final path depends on whether the application uses SOCKS, the system HTTP proxy, or TUN, and whether the browser has independent Secure DNS enabled.

System proxy mode: usually proxies only TCP traffic that respects the system proxy; some applications continue to access system DNS directly.
TUN mode: can capture more system traffic, but DNS hijacking, route exclusions, and LAN access rules still need to be checked.
Application-managed DoH: the destination port is 443, so it may bypass the core's DNS module. Disable the application's independent resolver or explicitly proxy its connection.
Remote DNS bootstrap: when the DoH address uses a hostname, use hosts or a reliable bootstrap address to break the dependency loop.
IPv6 bypass: if the system has IPv6 but the proxy and rules cover only IPv4, queries or connections may leave through an unmanaged path.

In v2rayN 7.x, open Settings → Parameter Settings to check the local listening ports, system proxy, and log level, then review the core log on the main screen for routing tags. For custom JSON, use Servers → Add Custom Configuration Server to import it, and keep a known-good configuration for rollback. Menu wording may vary slightly between minor releases, but the roles of the custom-configuration and parameter-settings entry points remain the same.

Four steps to verify the query path

Clear the system and browser DNS caches, then restart the core to prevent stale results from interfering.
Visit a known domain in mainland China. The log should show a local DNS query and a match to direct.
Visit a known overseas domain. The log should show the remote DoH connection going out through proxy.
Query the same domain 10 times in a row. Compare the first-query time with cached responses, and confirm that resolution does not fall back to localhost.

Do not judge the test only by whether a webpage opens. Caches, backup addresses, and application-level retries can hide an incorrect path. More reliable signs are: a domain in mainland China returns a result matching geoip:cn, the remote DNS connection for an overseas domain uses the proxy outbound, and the core log shows no local resolver handling an overseas-domain fallback.

Common failures and targeted fixes

Incorrect split DNS often appears as “the node works but some sites do not,” “the first visit takes a long time but refresh works,” or “switching nodes still connects to the old address.” Do not immediately blame VMess, VLESS, or the transport protocol: the wrong destination address may have been resolved before the proxy handshake. Verify the resolution result first, then inspect the node and transport settings for a shorter troubleshooting path.

Why do overseas sites take more than ten seconds to open the first time?

Check whether remote DoH first times out on a direct connection before falling back. Put IP rules for the DoH service address near the front of the routing rules and assign proxy, then confirm in the logs that the port 443 connection goes straight to the proxy outbound.

Why does the configuration report unknown fields after loading?

First confirm whether Xray or the v2fly core is actually running. Remove fallback extension fields unsupported by that core, keep the basic servers, hosts, and query strategy, then restart and add fields back one at a time.

Why does a domain in mainland China sometimes resolve to an overseas address?

Check whether the domain is actually included in the current geosite data, and verify that the local server object has expectIPs: ["geoip:cn"]. If the destination uses global traffic management, do not force it to a single fixed address.

Why can’t LAN devices open after enabling TUN?

Make sure geoip:private uses direct, map local network names in hosts when needed, and ensure routing does not send private ranges such as 192.168.0.0/16 or 10.0.0.0/8 through the proxy.

Why does the result stay the same after changing DNS?

Quit the relevant applications, clear the system DNS cache, and restart the core. If caching is enabled, temporarily disable it for testing or use a domain that has not been queried before so old records do not affect the result.

A subscription URL only provides the client with a node list; it usually does not replace locally defined DNS policies. After updating a subscription in v2rayN, v2rayNG, or v2flyNG, confirm again that the active configuration still references the custom rules. If the client regenerates its configuration whenever the node changes, put DNS and routing in a global custom template supported by the client instead of editing a temporary generated file.

A working final configuration should meet three conditions: the resolver is selected by domain category, the remote DNS connection itself goes through the proxy, and the resolution result belongs to the same group as the subsequent routing rules. By reading logs across three layers—query source, resolution result, and connection outbound—most pollution, fallback, and leak issues can be traced to a specific field without repeatedly changing nodes.