V2Ray DNS Split Routing Configuration Guide: Separate Resolution for Mainland China and International Domains

DNS split routing solves more than a speed problem

When a client accesses a website, it usually resolves the domain to an IP address before choosing direct, proxy, or blocked egress according to routing rules. If the answer is wrong, the connection may reach the wrong address even when VMess, VLESS, and the underlying transport settings are correct. If the answer comes from an unsuitable region, the site may return a distant service node, causing a slow first byte despite a successful handshake.

Mainland domains are typically sent to a local recursive resolver for shorter round trips and addresses suited to the local network. International domains can use encrypted DNS through the proxy to reduce the risk of query rewriting or incorrect caching. The goal is not to force every query through one server, but to keep domain rules, DNS servers, and final egress aligned.

Also distinguish between the client’s built-in DNS and the DNS currently used by the operating system. With only a system proxy enabled, browser HTTP traffic can enter v2rayN, while some applications may still call the system resolver directly. TUN mode can capture a broader range of traffic, but whether port 53 queries are intercepted still depends on the client’s generated inbound, DNS hijacking, and routing configuration. A connected proxy does not mean every DNS query has entered the core.

Separate the four configuration layers that are easy to confuse

A maintainable DNS setup has at least four layers: resolvers answer queries; domain rules choose a server group; query strategy controls A, AAAA, or both; routing strategy determines how the returned domain or IP is matched to an egress. The parameters may sound similar, but they operate at different points.

expectIPs checks whether a DNS answer falls within the expected address range. For example, after sending a mainland domain to a local server, you can require the result to fall under geoip:cn. If it does not, the core can continue with subsequent servers. skipFallback controls whether domains matched by the current server participate in fallback, which is useful when group boundaries are already explicit.

How to write a readable server-group configuration

The snippet below shows a common DNS group structure in the Xray core. Use it to understand field relationships rather than replacing the complete configuration generated by the client. v2rayN, v2rayNG, and v2flyNG may bundle different cores and versions, so confirm that the active core supports each field before importing it.

{
  "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"
        ]
      },
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

The first server group handles mainland domains and constrains answers by address range. The second handles non-mainland domains. The final localhost entry is a fallback; whether to keep it depends on the environment. If the system resolver often returns incorrect answers, replace it with another explicitly reachable server, but do not add layers of fallback without evidence in the logs.

An encrypted DNS address may itself contain a domain name. Before opening the HTTPS connection, the core needs the IP address of that server domain; this is called bootstrap resolution. An IP endpoint can reduce circular dependencies. With a domain endpoint, make sure a local server can resolve it reliably and that the query will not recurse into the same encrypted connection before it is established.

• Keep domain sets bounded: geosite:cn and geosite:geolocation-!cn have clearly separated roles, preventing the same domain from matching multiple server groups.
• Check the DNS egress separately: Encrypted queries may use remote port 443, but routing rules can still send them mistakenly through the direct egress.
• Keep a final fallback: When no domain list matches, an available server must answer the query; otherwise new domains will fail immediately.
• Test with IPv4 first: If IPv6 is unreliable, an AAAA answer can cause connection delays before falling back to an A record.

Setup order for v2rayN and Android clients

In v2rayN 7.x, open “Settings” → “Parameters” to confirm the active core, system proxy, and DNS options, then review the rule set under routing settings. Menu labels may vary slightly between minor releases, but keep the same order: confirm the traffic entry point, then DNS, and finally routing egress. Stop the active connection and restart it after saving so the new configuration is regenerated.

1. Record the entry mode: Confirm whether the client uses a system proxy or TUN. The common local HTTP port is 10809 and the SOCKS port is often 10808; use the values shown in the client interface.
2. Check DNS server groups: Enter locally reachable servers for the mainland group and encrypted endpoints for the international group, with a clear domain scope assigned to each.
3. Check routing rule order: Put exact domain rules before broad rules, and do not let block, direct, and proxy rules overlap unpredictably.
4. Restart the connection: Save the settings, reconnect, and then clear existing DNS caches in the operating system and browser.
5. Read the core logs: Look for the target domain, DNS server address, egress tag, and failure reason—not just latency-test results.

v2rayNG uses the Xray core, and its DNS, routing, and VPN-service options are usually configured under “Settings.” v2flyNG uses the v2fly core, so supported fields depend on the actual core version. Do not copy a complete configuration from one core to the other. A safer approach is to select the server and query strategy in the interface first, then inspect the generated configuration.

These ports help identify traffic; they do not mean every client uses the same defaults. For example, after changing the local listening port, if the terminal environment still points to 10808, the browser may work while command-line tools fail. When checking DNS, also confirm which local entry point the application is actually using.

How to verify that mainland and international domains resolve separately

Do not verify this only by checking whether a page opens. A browser may reuse an existing connection or retain its own DNS cache. Choose one known-direct mainland domain and one known-proxy international domain, then check the answer, query time, core logs, and final egress for each.

In a Windows terminal, use nslookup with a specified server for a baseline test. The first command below checks whether the local resolver is reachable; the second shows the system’s current resolution path. System command results do not necessarily pass through V2Ray’s built-in DNS, so use them for comparison rather than as sole proof that core-level split routing is active.

nslookup example.cn 223.5.5.5
nslookup example.com
ipconfig /flushdns

Before testing in a browser, close and reopen the target page to avoid reusing an old connection. Then inspect v2rayN’s live logs: identify which DNS rule matches the domain first, and confirm that the connection matches the direct, proxy, or block egress tag. If the logs show only an IP address, check whether the traffic entry point preserves the domain name and whether sniffing applies to the current protocol.

Common failures and fixes

The most common issue is that encrypted DNS is configured but routed through the direct egress. Ordinary nodes connect normally, while international domains repeatedly time out during resolution. First check which rule matches the encrypted DNS endpoint’s domain or IP, then create an explicit proxy-egress rule for it. Do not keep adding fallback servers whenever a timeout occurs; that makes the actual query path unpredictable.

Another common issue is that the browser has its own Secure DNS enabled while the client also uses encrypted DNS. Queries may bypass the client’s group logic, leaving no target domain in the logs. During troubleshooting, standardize the query entry point: either send browser queries through the proxy for the client to handle, or document the browser’s own resolver endpoint and proxy path. Avoid running both strategies at once.

• Query timeout: check resolver reachability, the path to ports 443 or 853, and the corresponding egress tag.
• Unexpected address: check the domain group, the expectIPs range, and the local cache.
• Intermittent page failures: check A and AAAA records, IPv6 reachability, and the Happy Eyeballs fallback delay.
• Rule not matched: check domain-rule priority, routing domainStrategy, and the rule-set version.
• Failure after a subscription update: check whether the client switched configuration groups and whether custom DNS is still attached to the active configuration.

Finishing principles for a stable configuration

After verification, keep one mainland resolver group, one international encrypted resolver group, and one clearly defined fallback. More servers do not automatically mean more reliability; a long list without domain boundaries or fallback conditions only increases random matches and troubleshooting cost.

Routing rules should follow the same principle: start with exact domains required by the service, then geosite categories, and finally IP categories and the default egress. DNS and routing groups should express the same intent—direct for mainland traffic and proxy for international traffic—so the resolution and connection stages do not contradict each other.

1. Save a verified working baseline configuration.
2. Record the client version, core type, entry mode, and local listening ports.
3. Choose one fixed test domain each for mainland and international traffic.
4. Run the initial-query test again after updating a rule set or subscription.
5. When something fails, read the logs in this order: entry point, resolver, returned address, and routing egress.

The final acceptance criteria are clear: mainland domains receive suitable addresses quickly from a local resolver and use the direct egress; international domains are resolved by an encrypted resolver, with both the DNS request and target connection using the proxy egress; uncategorized domains have a stable fallback; and the returned IPv4 and IPv6 types match the network’s capabilities. Only after all four are met should you tune cache lifetimes, refine rules, or add individual domain overrides.