V2Ray DNS Configuration: Split DNS for China and Overseas Domains

1. DNS routing and proxy routing are separate settings

DNS routing determines which resolver translates a domain into an IP address; traffic routing determines which outbound connection a request uses. Assigning overseas domains to a remote resolver does not mean requests to that resolver are automatically proxied. Conversely, a website may load through the proxy even if the browser previously looked up its domain using the system DNS. Check both paths.

This flow describes a case where an application passes a domain to the core and the routing policy requires DNS resolution. If a domain rule directly selects a proxy outbound, routing may not query DNS at all; the proxy server may resolve the destination domain instead. If an application submits only an IP address, the core generally cannot reliably recover the domain originally queried.

• DNS tampering: A lookup returns an incorrect or manipulated result. A change in IP address alone is not proof of tampering; CDNs may return different addresses based on location.
• DNS leak: A query takes an unintended resolution path. Resolving domains in mainland China through a local DNS server as planned should not automatically be classified as a leak.
• Inefficient DNS routing: A remote resolver returns a distant CDN address for a service in mainland China. This may cause slow image loading or video buffering rather than a complete connection failure.

2. Understand domainStrategy in three different settings

When looking up V2Ray DNS configuration, you’ll often see fields with the same name. Their behavior depends on where they appear. Don’t confuse the routing domainStrategy, the same-named setting on a freedom outbound, and DNS queryStrategy.

For an initial setup, start with IPIfNonMatch. This lets explicit domain rules determine the outbound first, using IP geolocation rules only when no domain rule matches. It does not mean “resolve every domain first,” nor does it take over DNS for every application on the system.

3. Choose local DNS and remote DoH by domain

Server objects in dns.servers can use domains to specify which domains they should handle preferentially. This matching selects a DNS resolver; it does not also create a routing rule for website traffic. This guide uses two paths—a local UDP DNS server and remote DoH—and explains when each is selected and how its traffic is routed.

geosite:cn and geosite:geolocation-!cn are category tags in the rule data, not strictly complementary sets that cover every domain. Some newer domains may be absent, so the remote resolver above also serves as a fallback for unmatched domains. If the categories overlap or data is missing, check the current data files and logs; don’t infer matches from the domain suffix alone.

• skipFallback: true does not mean “never query this server.” Domains that explicitly match it can still use it; the setting mainly affects its selection as a fallback.
• Requests using https:// follow a different path from those using https+local://. The latter uses local mode, so the core-routing assumptions in this guide do not apply directly.
• When using a domain name for a DoH endpoint, you also need a bootstrap lookup for the resolver’s own hostname. This guide uses an IP literal to reduce that dependency.
• DoH encrypts queries in transit to the DNS service. It does not guarantee that the resolver will always return suitable results, and it does not replace routing checks.

4. Combine DNS and routing settings, and pin down the resolver’s outbound

Here’s an example of how to merge the core JSON settings. It assumes your existing configuration has a proxy outbound named proxy and a direct outbound named direct. If your tags differ, replace them everywhere they appear. Keep your existing inbounds, node authentication, transport, and TLS settings. Don’t start the core with this snippet as if it were a complete configuration.

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      }
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["1.1.1.1"],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["223.5.5.5"],
        "port": "53",
        "network": "udp",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:geolocation-!cn"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

Routing rules are evaluated from top to bottom, and the first match takes effect. Putting resolver-specific rules before general geolocation rules makes the DNS transport path easier to predict. These rules match destination IP addresses and ports, so other connections to the same address and port will follow them too.

1. Check the default outbound: Traffic that matches no rules typically uses the first outbound in outbounds. If unmatched traffic should default to the proxy, make sure the first outbound is the intended proxy; changing rules alone is not enough.
2. Check the rule data: If startup logs report a missing geosite category or data file, fix the rule-data source and path. Don’t treat deleting the failing rule and continuing as proof that the configuration works.
3. Check DNS for direct connections: To use built-in DNS for direct connections too, set "domainStrategy": "UseIP" in the settings of your existing freedom outbound, and confirm that your core version supports it.
4. Check node bootstrap resolution: If the proxy server address is a domain name, its only resolution path must not depend on the proxy connection that has yet to be established. Provide a working bootstrap lookup for that domain to avoid a startup loop.

5. Apply the settings in your client without letting the UI overwrite your JSON

v2rayN generates its runtime configuration from the nodes, DNS, and routing settings in its UI. Direct edits to a temporarily generated file may be overwritten when you switch nodes or restart the client. Prefer the DNS, routing, or custom-configuration options available in your current version. Menu names vary between releases, so don’t assume a path from one version applies to every version.

1. Save a rollback point: Note the current node, system proxy mode, and routing mode; export the configuration or back up the relevant settings. Change only DNS and the necessary routing rules at a time—don’t also switch protocols or transport settings.
2. Inspect the effective configuration: Save your settings and restart the core, then open the runtime configuration or preview provided by the client. Confirm that dns.servers, rule order, and outbound tags are present.
3. Check how the app connects: Desktop apps must use the system proxy or connect explicitly to a local HTTP/SOCKS endpoint. For SOCKS tests, use the actual port shown by the client; tutorial examples are not guaranteed to match your local port.
4. Check Android app coverage: In v2rayNG and v2flyNG, also review VPN mode, per-app settings, and DNS options. Excluded apps may continue using their original network path.
5. Isolate other DNS settings: During testing, note the original status of the browser’s “Secure DNS” and Android’s “Private DNS.” Temporarily disable them for comparison if needed, then restore your preferred settings when testing is complete.

A browser’s built-in encrypted DNS may bypass the core’s domain-classification logic, while its connection may still go through the proxy. Check “which resolver was used” separately from “which outbound carried the connection.” Seeing DoH does not prove that split DNS is working as intended.

6. Verify split DNS with ports, logs, and comparison tests

The numbers below are protocol ports and suggested test runs, not measured performance results. Test at least one domain that you’ve confirmed matches the local rules and one that matches the remote rules. Verify their classification against the data set actually in use; an unlisted domain is not a reliable way to determine whether a rule is broken.

On Windows, run ipconfig /flushdns to clear the system DNS cache, but browsers and the core may keep separate caches. Running nslookup normally tests the system DNS or a specified DNS server; enabling the system proxy does not automatically make it test the core’s DNS. You can use it to verify a specific path only if a local DNS listener is explicitly configured and the query is actually sent to that listener.

7. Common split DNS issues and how to troubleshoot them

The final configuration should make three things clear: which domains use the local resolver, which queries reach the remote resolver through the proxy, and what happens when no category matches. For tighter control over DNS paths, plan separately for system DNS, browser resolution, and network interception. A single dns.servers block cannot control DNS across an entire device.