V2Ray DNS Routing: Split DNS for China and Overseas Domains

At a glance

For readers who can connect to a node with v2rayN but are seeing DNS errors or inconsistent routing. First identify what is resolving each domain, then assign separate roles to DNS servers in China, overseas DoH, and routing rules. Finally, trace the request path and check the cache, logs, and actual outbound route.

First, find out what is sending DNS requests

DNS routing is more than adding two server addresses to a list. Your browser may resolve domains on its own, or the operating system may resolve a domain before the request reaches the proxy. The dns rules in your configuration can only take effect when the domain enters the V2Ray or Xray core's DNS resolution flow. Enabling “System Proxy” in v2rayN mainly affects apps that respect the system proxy; it does not take over every DNS request on the device.

Connect using a working node, then compare how the same website behaves in your browser and another app. If only one browser has a problem, check its Secure DNS settings first. If only an app using a direct connection fails, confirm whether its traffic passes through the client. Avoid changing system DNS, TUN, and routing rules all at once, or it will be hard to tell what fixed the issue.

App requests a domainProxy receives the requestDNS rule matchesQuery goes to the selected upstreamRouting selects an outbound

Choose DNS in China or overseas DoH by domain

This dns snippet illustrates the structure; it is not a complete configuration you can import directly into v2rayN. The example matches common domains in China with geosite:cn and sends them to a standard DNS server. It matches the corresponding overseas domains with geosite:geolocation-!cn and sends them to DoH. Domains that match neither group go to the final fallback upstream. Whether this works as expected also depends on the core, rule data, and how the configuration is generated.

{
  "dns": {
    "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"]
      },
      "localhost"
    ]
  }
}

address specifies the upstream. The standard DNS example uses port 53; the DoH address uses HTTPS, usually over port 443. domains determines which entry a domain matches first; it is not an access control list. expectIPs filters returned addresses: this example requires results from the DNS server in China to fall within geoip:cn. This does not prove that a domain should resolve to an IP address in China. Websites deployed across regions may return results that differ from expectations.

Standard DNS port in this example

443

Common port for HTTPS queries

2 groups

Upstreams selected by domain

localhost is the fallback resolver for domains that don't match the rules above, and uses the local machine's DNS environment. If you're troubleshooting DNS poisoning on your machine, don't assume a fallback result came through DoH. The DoH endpoint itself must also be reachable. For timeouts, check both whether your current network can reach the upstream and which outbound the core uses for its DNS connection. Editing the servers list alone does not guarantee that queries will go through the proxy.

Save settings in v2rayN and check routing

The v2rayN interface may change between versions. In Settings, find DNS Settings and check the current configuration mode and editable options. If the interface supports custom DNS configuration, back up the existing content before editing and follow the field's requirements. Don't paste the snippet above into a field that only accepts server addresses. After saving, restart the core and check the client logs for JSON parsing errors or failed connections to DNS upstreams.

DNS: identify what is being queried first

Entry point: “Settings” → “DNS Settings”
Match domains in China: geosite:cn
Match overseas domains: geosite:geolocation-!cn
Fallback: Check the actual result from localhost

Back up the original configuration before editing, and confirm that the selected mode allows changes to the core's DNS rules.

Routing: identify the connection's outbound next

Entry point: “Settings” → “Routing Settings”
Rules for China: Route matching domains directly
Overseas rules: Proxy matching domains
Default outbound: Check where unmatched traffic goes

Check rule priority and the currently active routing profile—not just whether a rule exists.

DNS and routing rules should reflect the same intent. For example, a broad proxy rule earlier in the list may take precedence over a rule for a domain in China that uses a local DNS upstream. The result can be “DNS resolves correctly, but traffic uses the wrong outbound.” In Settings → Routing Settings, confirm which rule set is active and check the order of its individual rules. Subscription updates usually refresh server lists; don't assume they also fix local DNS or routing settings.

If a domain is still present when the request reaches the core, routing can match it against domain rules first. domainStrategy affects when an IP address is resolved for routing decisions. AsIs does not resolve domains for routing. IPIfNonMatch attempts resolution when no domain rule matches. IPOnDemand can trigger resolution when a rule needs an IP address to make a decision. These options control when routing checks an IP; they won't redirect system DNS requests that never enter the core to a specified upstream.

Tell DNS poisoning apart from caching and routing mismatches

Test one domain, one app, and one node at a time, changing only one setting per test. First check whether the domain opens, then check the core logs for DNS queries, lookup failures, or routing matches. If only a few domains fail, compare the addresses returned by different upstreams. If every domain fails, check the node connection, DoH reachability, and configuration syntax before concluding that DNS is being poisoned.

Check the request path. Test in a browser, then compare with another app that respects the system proxy. If only apps using a direct connection fail, check the system proxy or TUN status instead of adding DNS rules first.
Check the DNS query. Search the v2rayN logs for the domain and any DNS errors. If there's no trace of the request, check the app's Secure DNS settings, the system cache, and whether the traffic reaches the core.
Check the outbound. Compare the active rules in Routing Settings with the outbound shown in the logs. If the returned IP is valid but the connection fails, check routing, the node, and the destination service instead of repeatedly switching upstreams.
Clear old results and test again. On Windows, run ipconfig /flushdns in Command Prompt to clear the system DNS cache. Then restart the app you're testing so its cached results aren't mistaken for the effect of your new settings.

If an app resolves a domain to an IP before sending the request through the proxy, the core may only be able to match IP rules. Traffic sniffing may recover domain information for some HTTP or TLS connections, but it doesn't work for every protocol and can't replace a correctly routed DNS request. Trace the request path first, then decide whether to adjust sniffing or IP routing rules.

FAQ: Why aren't my DNS changes taking effect?

Added a DoH address, but pages keep loading?

First check whether the HTTPS connection required by https://1.1.1.1/dns-query is reachable, then look for timeouts in the core logs. Check the outbound for the DoH connection separately; a website using the proxy doesn't prove that the DoH request does too.

A website in China is being treated as overseas. What should I do?

Check the geosite rule data and active routing profile, then see whether the domain matches the intended domains entry. Services spanning multiple regions may not follow expectations based on IP location. Add a more specific rule for that domain if needed.

Getting a DNS error in just one browser?

Check the browser's own Secure DNS settings, turn the feature off, and test again. Restart the browser to clear old connections. If other apps still work, don't change the global DNS configuration yet.

Can't open any websites after saving the configuration?

Restore your backup first, then look in the logs for configuration parsing errors. Confirm that the field accepts a complete dns object rather than just an upstream address. Add one rule at a time, save, and restart the core to test.

Changed routing, but DNS still returns the old result?

Routing rules don't refresh cached DNS results. Clear the system cache, restart the app you're testing, and check whether the core sent a new query. A change in the connection's outbound does not mean the DNS response changed.

The final check is straightforward: choose one domain in China and one overseas, then confirm each one's DNS upstream, routing match, and actual reachability. Once all three check out, expand testing to the apps you use every day. If the issue only occurs in v2rayNG or v2flyNG, check the core and client settings on Android separately. Settings in desktop v2rayN aren't copied to other devices automatically.