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

Separate DNS Resolution from Traffic Routing

In a V2Ray configuration, DNS and routing are two connected but distinct stages. DNS resolves domain names to addresses, while routing decides which outbound handles the connection. A correct DNS result does not guarantee that traffic uses the proxy; traffic matching a proxy rule does not mean the original DNS lookup went through a remote server. When troubleshooting split-routing issues, inspect these two steps separately.

When an application submits a domain target to V2Ray, the routing module can use domain rules to choose an outbound directly. If the rules also need to inspect the destination address, or an address is required before an outbound connection can be established, the built-in DNS module participates in resolution. The routing.domainStrategy setting affects this process. Common values include AsIs, IPIfNonMatch, and IPOnDemand; supported values and exact behavior vary by core version, so consult the documentation for the version in use.

• AsIs: Keep the domain whenever possible; do not resolve it proactively just to match IP-based routing rules.
• IPIfNonMatch: If no domain rule matches, resolve the address and continue checking IP rules.
• IPOnDemand: Resolve earlier when routing needs an address; misconfiguration can increase the number of queries.

For most configurations that send mainland Chinese traffic direct and proxy everything else, IPIfNonMatch is the easiest starting point to understand. Let geosite domain rules run first; resolve unmatched targets through DNS, then apply geoip rules to the resulting address. This preserves domain-based routing while handling connections that can only be classified by address.

Key Fields in the dns Configuration

dns.servers is the entry point for the entire configuration. Items in the array can be server addresses or objects with matching conditions. Object syntax can define address, port, domains, and expectIPs. Supported fields vary between V2Ray, Xray, and the core versions bundled with clients, so do not rely only on the client UI version when migrating a configuration.

hosts entries are processed before external DNS queries. They are useful for a small number of fixed bootstrap dependencies, such as a remote resolver whose service address is a domain that must itself be resolved first. In that case, use a verified fixed address for the initial mapping to avoid the loop in which the remote DNS connection must be established before its own hostname can be resolved.

Set queryStrategy according to network conditions. If the network has stable IPv4 connectivity only, start with UseIPv4 to avoid waiting on unreachable IPv6 addresses. With full dual-stack connectivity, query both families if needed. This setting controls address-family selection, not proxy routing; even with IPv4-only queries, domains can still be assigned to different DNS servers by mainland-China and overseas rules.

Resolve Mainland Chinese Domains Locally and Other Domains Remotely

Here is a DNS example that can be merged into the main configuration. Mainland Chinese domains select a local resolver through geosite:cn, while geoip:cn checks the address range in the response. Domains that do not match this dedicated rule are sent to the remote HTTPS DNS server below. The addresses illustrate the structure; before deployment, verify that the current network, core version, and remote outbound can all reach the relevant services.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

The final item without domains is the default resolver. It handles domains not explicitly covered by earlier rules. Keeping a default entry matters because classification data cannot cover every domain; newly registered domains, private services, and domains awaiting classification updates all need a defined destination.

The example lists the same remote resolver once as a dedicated server for non-mainland domains and again as the default server to make the matching logic explicit. In practice, you can simplify it according to the DNS selection behavior of the core in use. If the version handles duplicate entries for the same address unexpectedly, keep only the default remote server: mainland Chinese domains match the first item, and everything else naturally falls through to the default.

geosite:cn is a domain classification; it does not guarantee that the resolved address is in mainland China. Some mainland Chinese sites use global CDNs, so results may vary by network location. Conversely, domains outside the mainland classification may still return addresses in mainland China. Domain classification and address geolocation should be used together, but neither should be treated as absolute.

How expectIPs Detects Unexpected Responses

expectIPs describes the expected address range returned by a DNS server. When a mainland Chinese domain uses a local resolver, you can set it to geoip:cn. If the response falls outside the expected range, the core can treat it as a failed match and try other candidates according to its DNS server selection logic. This check reduces the impact of incorrect resolution; it is not a standalone protection switch.

It works best when the rule boundary is clear. For example, a local server dedicated to mainland Chinese domains will usually return addresses in mainland China. If it returns a clearly inconsistent address, retrying through a remote server is often more sensible. However, CDNs, cross-border services, and Anycast make address geolocation complex; overly strict conditions can misclassify valid results as abnormal.

Do not apply geoip:!cn uniformly to all remote domains. Many international services return nearby nodes based on the user's location, which can include addresses in mainland China; some domains also return addresses from multiple regions. Requiring every result to be outside mainland China can cause repeated queries, resolution failures, or connection delays.

When configuring expectIPs, follow three steps:

1. Start by configuring only the domains groups and confirm that each domain category reaches the intended server.
2. Then add expectIPs to servers with stable boundaries and watch for false positives on commonly used sites.
3. Finally, check fallback behavior to ensure abnormal results move to a suitable candidate server instead of terminating resolution.

If intermittent failures appear after adding expectIPs, first inspect the addresses actually returned for the failing domains. Then decide whether to broaden the expected range, remove the domain category, or drop the address restriction for that server. Do not hide a classification error by repeatedly changing server order.

Send Remote DNS Queries Through a Proxy Outbound

Adding a remote DNS server to dns.servers only specifies which resolver to use; it does not guarantee the network path. Requests to the remote DNS server still pass through routing and an outbound. A direct connection may expose queries to the local network path; to access the resolver through a proxy, define an explicit rule for its destination address.

The routing snippet below sends the remote resolver addresses to the outbound tagged proxy, while mainland Chinese domains and addresses use direct. The final rule catches all remaining TCP and UDP traffic. Rules are matched in order, so remote DNS addresses must appear before broad direct-connection rules.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "1.1.1.1"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "geoip:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

This is only a routing fragment; the main configuration must also contain outbounds whose tags exactly match proxy and direct. Tags are case-sensitive. Referencing a nonexistent tag can make the configuration fail to load or prevent connections from being established as expected.

If the remote DNS service uses a domain name as its endpoint, account for bootstrap resolution. The core must know the endpoint's address before it can establish an HTTPS connection. Options include using an address-based endpoint, providing a verified bootstrap mapping through hosts, or letting the system DNS handle only this initial stage. Do not make the remote DNS hostname dependent on resolution by that same remote DNS service.

The proxy server address has the same bootstrap dependency. If a subscribed node uses a domain name, V2Ray must obtain the node address before the proxy channel exists. Such hostnames need a reliable bootstrap resolution path and must not be forced through a proxy outbound that is not yet available.

Key Settings for DNS Pollution Prevention

Preventing DNS pollution is not as simple as replacing the local DNS address. A complete path includes query selection, transport routing, response validation, caching, and the application connection. If any part still follows the wrong path, you may see symptoms such as a site working on the first visit but failing on refresh, correct resolution followed by a direct connection, or an old address persisting after switching nodes.

Group Query Servers by Domain Category

Use a local resolver for mainland Chinese domains whenever possible to obtain CDN addresses closer to the current network; use a remote resolver for other domains to reduce interference from the local recursive path. Classification rules need a default destination so uncategorized domains are never left without a server.

Send Remote Queries Through a Controlled Outbound

Even when the destination server differs, ordinary UDP queries can still be affected by intermediate network paths. HTTPS DNS encrypts the transport, but you must still verify that it uses the intended outbound. Changing only the server address is not enough to establish the final route.

Adjust Caching for Diagnostics, Not as a Permanent Workaround

V2Ray's built-in DNS, the operating system, and applications may all cache resolution results. After changing the configuration, old results may continue to be used. Reload the core, clear the system DNS cache, and restart relevant applications. Temporarily disabling caching can help confirm a problem, but leaving it off increases query volume and first-connection latency.

Independent Resolution in Browsers and Applications

Some applications use their own encrypted DNS settings rather than handing queries to the system or V2Ray. In that case, V2Ray may see only the subsequent connection address, and domain-based routing may be limited. During testing, first determine how the application resolves names, then verify whether the built-in DNS is actually involved.

Application and Verification Order in v2rayN

v2rayN subscriptions provide server configurations, while DNS and routing usually belong to client-side runtime settings. Updating a subscription does not automatically preserve custom DNS rules; the result depends on the configuration mode, routing settings, and client version. Save the currently working configuration before editing, then reload the core afterward instead of merely toggling the system proxy.

Do not test a large number of websites at once. Start with one domain clearly belonging to the mainland-China category and another that should use remote DNS, then inspect the DNS and routing logs separately. Check the matched DNS server, returned address, outbound tag, and whether the final connection succeeds.

1. Confirm that the configuration loads successfully and that the logs show no unknown fields, missing tags, or JSON syntax errors.
2. Query a mainland Chinese domain and confirm that it matches the local server object containing geosite:cn.
3. Query another domain and confirm that it reaches the remote default server, then verify that the remote DNS connection uses the proxy outbound.
4. Check the routing result for the application connection to ensure that traffic is not changed to direct access by a later rule even though DNS uses the proxy.
5. Switch to another test domain or clear the cache to rule out the influence of old results.

If you use v2rayNG or v2flyNG, the troubleshooting method is the same, but available fields depend on the Xray or v2fly core bundled with the app. Do not copy a desktop configuration directly to Android without checking versions. If a field is unrecognized, first identify the core type and version, then adjust the configuration format accordingly.

Common Problems and How to Locate Them

Mainland Chinese Sites Load Slowly

First check whether mainland Chinese domains are falling through to the remote default server. If geosite data failed to load, the classification file version is incompatible, or the domain is not listed, it will reach the default entry. Also check whether expectIPs is too strict, rejecting a valid CDN address from the local server and triggering a remote query.

Remote DNS Is Configured but Resolution Is Still Wrong

Focus on the outbound used by the remote request. The destination address may match a geoip rule that sends it direct, or an ordering mistake may prevent it from reaching proxy. An HTTPS DNS connection can also fail because the system clock is wrong, the network cannot reach the destination, or the proxy node has not been established.

A Resolution Loop Appears During Startup

This usually happens when the proxy node hostname or remote DNS hostname can be resolved only through the proxy, while the proxy itself depends on that result. The solution is to establish an independent bootstrap resolution path. The dependencies among the node hostname, local resolver, and remote DNS endpoint should be able to build progressively from the direct-connection stage.

The Address Is Correct but the Site Uses the Wrong Outbound

Check DNS and application routing separately. The domain may resolve correctly, but a later geoip:cn rule can send the returned address direct; alternatively, an earlier domain rule may already specify another outbound. Review routing rules from top to bottom and identify the first match rather than looking only at the final fallback rule.

Results Keep Changing Shortly After an Edit

This is usually related to multiple cache layers, CDN responses with multiple addresses, or application-provided resolution. Close and restart the relevant application, reload the V2Ray core, and repeat the test with a single domain. If the logs show new queries but a different address each time, the resolver may simply be performing normal load balancing; changing addresses alone does not prove DNS pollution.

Final Configuration Checklist

After completing DNS splitting, confirm that mainland Chinese domains, local network addresses, and remote domains each have a clear handling path. Then verify the outbound for remote DNS, bootstrap resolution for proxy nodes, the default server, and the final fallback route. Finally, use logs for verification instead of judging only by whether a webpage opens.

A maintainable configuration is usually simple: a small number of DNS servers, clear domain groups, limited expectIPs conditions, and routing rules with an unambiguous order. Finer classification increases maintenance costs, while stricter conditions create more false positives with CDNs and dynamic addresses. Establish two working resolver groups first, then add exceptions based on actual logs; this is more stable than loading in a large rule set all at once.

When you need to verify the complete JSON structure, use this site's JSON manual to review the hierarchy of dns, routing, and outbounds. Once the client loads the configuration successfully, test subscribed nodes, the system proxy, and split routing one by one instead of attributing every connection problem to DNS.