V2Ray DNS Routing: Split DNS for China and Overseas Domains

Start with the distinction: DNS routing is not traffic routing

When you visit a domain, DNS resolution finds its address; routing decides which outbound connection to use. These are separate decisions. Sending mainland China domain queries to local DNS and other queries to remote DNS only determines which resolver handles each query. If a routing rule still sends a connection through a direct outbound, using remote DNS won't automatically send that connection through the proxy.

First, check whether queries reach the core. With only the system proxy enabled, your browser may resolve domains through the operating system or send its own encrypted DNS queries. Terminal apps behave differently depending on their proxy settings. The built-in DNS settings in V2Ray or Xray can directly control only queries handled by the core. If an app resolves a domain locally and passes the resulting IP to the proxy, the core may never see the original domain.

Troubleshoot in this order: check whether the app sends a domain or an IP, see which DNS server was selected, then identify the routing rule matched by the connection. A connected node doesn't prove that DNS is being routed as expected; node status confirms only that a connection was established, not how your browser resolved the domain.

Choose resolvers for mainland China and other domains

A common setup for built-in DNS is to use local resolution for queries matching mainland China domain rules and remote resolution for the rest. These rules come from data available to the core, and coverage may vary between core versions and rule-data releases. Unmatched domains use the default resolver, so check which resolver is set as the default before adding lots of narrow rules.

“Mainland China” and “other” here are domain-rule categories, not a live check of where a server is located. A domain may use infrastructure in multiple regions, and its classification can change when rule data is updated. For work sites or internal domains, add explicit rules rather than relying on the domain suffix to determine the network path.

Check settings and config format in v2rayN

In v2rayN, go to Settings → Parameter Settings to confirm the active core and proxy mode, then open the DNS settings available in your client version. Settings layouts can change, so follow the options shown in your current interface. Keep a copy of the existing config before editing. If a subscription, preset, or custom template regenerates the core config, check after restarting that your changes are still in effect.

This Xray DNS snippet illustrates how the fields relate; it is not a complete, runnable config. It sends domains matching geosite:cn to the system's local resolver, represented by localhost, and sends other queries to the DoH entry below. Before using it, confirm that your core supports these fields, the rule data is available, and the example DoH address has been replaced with a working endpoint.

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:cn"]
      },
      "https://dns.example.net/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategy sets the address-family query policy; it doesn't choose between a direct connection and a proxy. If a site has only IPv6 records and your network doesn't support IPv6, check the address-family settings first to avoid misdiagnosing the issue as a remote DNS failure. dns.example.net is an example domain; its endpoint doesn't provide real DNS resolution.

DoH and fakeDNS: what each one does

DoH sends DNS queries over HTTPS. It can reduce the chance of queries being altered along an ordinary plaintext DNS path between the app and the chosen resolver, but it doesn't replace routing rules or guarantee that every returned IP is suitable for the selected outbound. Remote DoH requests also need a connection to the endpoint. If the endpoint is a domain, resolving it may be necessary to establish that first connection; check the logs to see which outbound is used.

fakeDNS is a different mechanism: the core returns a virtual address to the app, then maps connections to that address back to the original domain. It's useful in specific transparent proxy setups that need to preserve domain information. It isn't a public DNS server or a switch that encrypts every real DNS query. Whether to enable it depends on your TUN, inbound interception, and sniffing settings.

These port numbers can help identify request types, but they don't prove that every query passes through the core. For example, a browser using its own DoH may send requests that look like ordinary HTTPS connections. Seeing—or not seeing—traffic on port 53 doesn't tell you which resolver the browser ultimately used.

Make DNS results work with your routing rules

Domain and IP routing rules serve different purposes: domain rules can choose an outbound directly from the domain, while IP rules need a destination IP. In Xray, for example, domainStrategy set to IPIfNonMatch attempts DNS resolution when no domain rule matches, so IP rules can be checked next. IPOnDemand resolves a domain when routing needs its IP. Don't confuse routing's domainStrategy with DNS's queryStrategy.

• Domain rules: Add explicit rules for internal services or business domains first, then use broader category rules. Check rule order and which outbound is actually matched.
• IP rules: If routing depends on the resolved address, check whether routing will trigger a lookup. Don't assume every domain request is resolved to an IP in advance.
• App sends an IP: If the app resolves the domain before sending traffic through the proxy, domain rules may not match. Check the proxy mode and whether the original domain is visible to the core.

For a practical test, choose two domains whose access you can control: add one explicitly to the local DNS rules and leave the other on the default remote resolver. Record the DNS query, matched routing rule, and final outbound for each instead of comparing page-load times. If DNS selection is correct but the connection takes the wrong path, adjust routing rules. If routing is right but the resolved address is wrong, check the DNS rule match and upstream resolver.

Troubleshoot by symptom: from client to core logs

Before testing, note the local proxy port configured in v2rayN and confirm that the system proxy points to the same port. Port numbers vary by device and config; don't put an example port in a permanent config. When testing in a browser, check its independent DNS settings and extensions. For terminal tests, confirm that the command explicitly uses the proxy so you don't mistake a direct connection for a test of the core's DNS.

1. First, confirm the request reaches the core. Test in a browser and a terminal, then look for connection records at the corresponding times in the v2rayN logs. If there are none, check the system proxy, app proxy settings, or TUN interception status.
2. Next, check whether the domain is preserved. If the logs show only a destination IP, check whether the app resolved it beforehand. If they show a domain, check whether DNS and routing rules are matching as expected.
3. Finally, compare the results. For repeated tests of the same domain, record the time, resolver, returned address family, and outbound. Retest after changing networks so you don't rely on cached results from the previous network.

If a site opens in your browser but not in the terminal, don't switch DoH right away. The terminal app may not use the system proxy, or it may rely on its own proxy environment variables. If a mainland China site is routed remotely, check its domain classification and matched routing rule first. If only certain domains fail, check DNS responses, IPv4/IPv6 connectivity, and whether those domains need specific rules.