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

Identify the DNS query path first

When an application accesses a domain, the first step is usually converting that domain into an IP address, not connecting through a proxy. If the application calls the system DNS directly, the query may finish before it reaches V2Ray. In that case, changing only the dns section may not change the result returned to the application. Built-in rules participate only when queries are handled by built-in DNS, a DNS inbound, a transparent-proxy capture path, or a corresponding client feature.

Another common source of confusion is that choosing a DNS server and splitting business traffic are separate steps. dns.servers determines which resolver receives a domain query, while routing.rules determines which outbound handles the query and the subsequent connection. Even if a domain is assigned to overseas DoH, the request may time out or be reset if that DoH request still uses an unsuitable direct path.

Check the complete path in order: whether the application hands the query to the client, whether the domain matches the expected server, which outbound carries the resolver request, whether the returned address passes validation, and which route ultimately handles the business connection. Observing only whether a webpage opens cannot identify the layer where a problem occurs.

What servers, domains, and expectIPs each do

servers is the list of DNS resolvers. An entry can be a plain address or an object with matching conditions. The object form allows domains, expectIPs, a port, and fallback controls to be assigned to a server. An unconditional server in the list usually handles default or fallback resolution, so it is usually unhelpful to give every server the same matching scope.

domains determines which queries should preferably be sent to the current server. Common rules include geosite:cn, geosite:geolocation-!cn, domain:example.com, and full:host.example.com. domain: matches the current domain and its subdomains, while full: matches only the complete hostname. Geographic classification depends on the data files used by the client, so outdated data may leave new domains uncategorized.

expectIPs does not select a DNS server. It checks whether returned IPs match the expected range. For example, after configuring geoip:cn for a mainland China domain resolver, the core can try a subsequent resolution path if the returned address is outside that set. This field helps detect clearly unreasonable responses, but it cannot replace domain classification or guarantee that a cross-region service always returns an address from a fixed region.

queryStrategy controls the address family used for queries. UseIPv4 requests only IPv4 and suits environments with incomplete local IPv6 support or proxy nodes without IPv6 outbound capability; UseIPv6 requests only IPv6; UseIP allows both result types. The address-family choice must match the node, system network, and routing rules. Otherwise, DNS may return results while connections continue to time out.

An adjustable split-resolution configuration

The example below shows the core structure without node credentials or complete outbounds. Mainland China domains go to a UDP 53 resolver, overseas domains go to an HTTPS-based resolver, and the local resolver is the final fallback. The example uses an IP-form DoH address to reduce the dependency loop that can occur when resolving the DoH hostname through DNS again.

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

The example assumes that the existing configuration already has outbounds named direct and proxy. If the actual tags are freedom, main, or another name, update the example to match the existing configuration rather than copying it directly. Routing rules also need the right order: more specific DNS server address rules should appear before broad direct rules for mainland China IPs, or they may be matched by an earlier rule.

skipFallback keeps the current server out of the ordinary fallback process, but support for DNS fallback details and extended fields varies between core versions. When using V2Ray 5.x, Xray 25.x, or another core bundled with a client, follow the actual core startup logs. If the logs report an unknown field, remove that field and complete basic validation first, then add fallback controls according to the documentation for the current core.

Verify that splitting works in the logs

Do not change DNS, routing, nodes, and the system proxy all at once. Back up the currently working configuration, replace only the DNS section, and restart the core. After confirming that there are no syntax errors, add outbound rules for the resolvers. Staged changes separate “the configuration will not start” from “the resolution result is unexpected.”

In v2rayN, check the log level under Settings → Parameter Settings, then open the log window from the main interface. For diagnosis, temporarily use an informational log level and restore the original setting after testing. On Android, v2rayNG or v2flyNG should be disconnected before saving the configuration and reconnecting, so an old core process does not continue using cached configuration.

1. Prepare one domain clearly classified for mainland China, one overseas domain, and one custom full-domain rule instead of relying on a single website.
2. Clear DNS caches within the controllable scope of the system and browser, then restart the current client core and record the test start time.
3. Access each domain group three times in succession, confirming the query target, matched server, and final outbound tag in the logs.
4. Test with the proxy enabled and disabled to determine whether failures occur only when DoH requests must use the proxy.
5. Temporarily remove expectIPs and test once more. If the problem disappears, the returned address conflicts with the expected set; adjust classification instead of blindly changing nodes.

Latency should also be recorded by layer. A complete access includes DNS time, TCP or UDP connection time, the TLS handshake, and server response time. If the logs show that DNS completes within 40 milliseconds but the page takes over 3 seconds, the problem is more likely in the business connection or routing than in resolution. Conversely, repeated DNS timeouts near 5 seconds call for checking server reachability and outbound selection.

Common failures and how to address them

The most common DNS-splitting problems are not JSON formatting errors but overlapping rules. domains inside a server object selects a resolver, while domain and ip in routing split connections. Both can reference geosite or geoip, but they run at different stages. During troubleshooting, identify whether the log shows a DNS query or a business connection.

Caching can make a change appear ineffective. The operating system, browser, client core, and upstream resolver may all cache records. During testing, first switch to a previously unused subdomain, or wait for the record's TTL to expire in a controlled environment. Repeatedly restarting the client clears only some caches and cannot force every upstream resolver to return a new result immediately.

Another risk is enabling multiple DNS interception mechanisms at the same time. For example, a browser may use secure DNS independently while client software intercepts system traffic, causing the two query paths to return different results. During diagnosis, temporarily use one clearly defined entry point so queries pass through the current core; after validation, decide whether the application's own resolver is still needed.

• Mainland China domains occasionally return overseas addresses: check content delivery network routing first instead of immediately treating the result as abnormal.
• DoH remains unresponsive: confirm that the connection to port 443 uses the proxy outbound and that the node can reach the target resolver.
• Connections fail only for IPv6 addresses: temporarily change the query strategy to UseIPv4, then check IPv6 capability on the node and local network.
• Subscription updates work but webpage resolution fails: subscription requests and business DNS use different paths, so inspect their logs separately.

Apply the configuration in v2rayN, v2rayNG, and v2flyNG

The v2rayN desktop client is suitable for complete configuration checks because its log window and custom configuration editor make comparison easier. Export the existing configuration first, confirm the core type under Settings → Parameter Settings, and then merge the DNS object into the top-level JSON. Do not keep two dns objects with the same name in one file; the later object may overwrite the earlier settings.

For Android clients, it is better to complete verification on the desktop and then transfer the approach rather than copy the entire configuration directly. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; their field support, default query strategies, and methods of generating client configuration may differ. If a client generates its runtime configuration automatically from a subscription, temporary manual changes may also be rebuilt after a subscription update.

A stable setup should retain a clear fallback path, but fallback must not hide a primary server that is failing continuously. First make the mainland China UDP 53 resolver and overseas DoH resolver match accurately, then add the local resolver as the final safety net. If the default server handles most queries, the domains classification or data file still has a problem; “the page opens” alone does not prove that splitting is correct.