Xray DNS Configuration: Split DNS for China and Overseas Domains

At a glance

This guide is for v2rayN and v2rayNG users who can already connect to a node and want to configure Xray DNS. It explains how to use a specified DNS resolver in mainland China for matching domains and send all other domains to DoH over the proxy, including when built-in DNS is used, fallback limits, and how to verify the setup. The examples are snippets to merge into an existing configuration; they do not include connection-ready node settings.

1. What built-in DNS handles: DNS queries vs. application traffic

Xray's dns object provides name resolution for the core; it does not mean that all DNS traffic from the operating system is being intercepted. An app may use the system resolver to get an IP address before passing it to the proxy, or it may pass the domain to the proxy protocol for resolution by the local core or a remote server. These paths produce different logs and test results.

Domain reaches the coreBuilt-in DNS is triggeredResolver is selectedQuery is sentAddress is returned

dns.servers is used only when built-in DNS is triggered. For example, the core needs DNS resolution when a routing rule must match an IP address, or when a direct outbound is configured to connect by IP. Conversely, if a proxy outbound passes the destination domain to a remote server, it can be normal for that domain not to appear in local DNS logs.

DNS routing: Determines which resolver receives a query for a given domain.
Traffic routing: Determines whether a connection to a destination uses the direct or proxy outbound.
DNS transport routing: Determines how UDP or HTTPS requests to the resolver are routed.
System-wide interception: Determines whether DNS requests from browsers, other apps, and system services enter the same processing chain.

2. Key fields: servers, domains, and fallback behavior

servers can include both standard DNS addresses and DoH addresses. Server entries in object form can specify domain matching and fallback behavior. Here, “local DNS” means connecting directly from your current network to a specified resolver in mainland China—not localhost, and not DNS automatically obtained from your router.

Resolver for domains in mainland China

address: 223.5.5.5
port: 53
domains: geosite:cn
skipFallback: true

Handles only matching domains; it is not included in the general fallback for other domains.

Resolver for all other domains

address: https://1.1.1.1/dns-query
Transport port: 443
queryStrategy: UseIPv4, inherited globally
Query outbound: proxy, set by routing rules

Uses a standard HTTPS DoH address, routed through the proxy outbound by the rules below.

Field	Value used here	What it does
`domains`	`["geosite:cn"]`	Sets the domain scope matched by this resolver; it is not a traffic routing rule.
`queryStrategy`	`UseIPv4`	The built-in DNS queries IPv4 addresses only, removing IPv6 connectivity as a variable during initial troubleshooting.
`skipFallback`	`true` for the mainland China entry	This entry is excluded from the general fallback resolver pool used for unmatched domains.
`disableFallbackIfMatch`	`true`	Once a domain matches a server rule, its query does not move on to a general fallback server.
`tag`	`dns-internal`	Adds a routing tag to queries generated by built-in DNS, which can be matched by `inboundTag`.

UseIP allows queries for both IPv4 and IPv6, while UseIPv6 queries IPv6 only. UseIPv4 is used here as a troubleshooting baseline, not as a recommendation to disable IPv6 on every network. Change the strategy only after confirming that the node's egress, system routes, and direct connection all support IPv6, then test again.

geosite:cn uses the domain data file available to your setup; it does not determine a domain's region in real time. Updates and coverage affect which domains match. geoip:cn is a set of IP addresses and cannot replace domain classification in DNS entries.

3. DNS configuration: match mainland China domains, send the rest to DoH

The JSON below contains a top-level dns object. If your configuration already has one, merge its contents rather than adding a second dns key. The example uses an IP-based DoH address so its hostname does not need to be resolved before reaching the resolver; standard HTTPS certificate validation is still required.

{
  "dns": {
    "tag": "dns-internal",
    "queryStrategy": "UseIPv4",
    "disableFallbackIfMatch": true,
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  }
}

Domains matching the mainland China set: Use 223.5.5.5:53. If the query fails, this setup will not fall back to the general DoH entry, keeping the resolution boundary intact.
Domains outside the set: The mainland China entry is excluded by skipFallback: true, so the DoH entry handles the query.
Mainland China resolver unreachable: First check whether your network blocks UDP port 53. If you need redundancy, add another resolver for mainland China with the same domains and configure its transport routing as well.
Internal domains: Corporate domains usually need corporate DNS. Add a dedicated match for the actual internal domain suffixes; do not send them directly to a public resolver.

4. Routing setup: ensure DoH traffic uses the proxy

DoH means that queries are sent over HTTPS; it does not guarantee that the connection uses a proxy. The routing example below works with the preceding DNS object and assumes your existing configuration has outbounds named proxy and direct. When the client generates node settings, the actual tags may differ. Check the runtime configuration and update all references consistently.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-internal"],
        "ip": ["223.5.5.5"],
        "port": "53",
        "network": "udp",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["dns-internal"],
        "ip": ["1.1.1.1"],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

The first two rules match only query connections tagged dns-internal, so they must come before general rules. The third handles application traffic to domains in mainland China, the fourth handles destinations that are already private IPs, and the last is the catch-all. AsIs does not resolve domains just to match IP-based routing rules, so this example keeps IP-based routing separate from DNS routing.

To make direct connections to domains in mainland China use the built-in DNS described above, configure the relevant part of your existing direct outbound as shown. Do not add another outbound with the same name; edit the existing object and keep its other required settings.

{
  "tag": "direct",
  "protocol": "freedom",
  "settings": {
    "domainStrategy": "UseIP"
  }
}

Check the DNS connection's outbound before evaluating the resolution result

Seeing the DoH address in the logs only confirms that the resolver was selected. Also verify that queries to 1.1.1.1:443 match proxy. If they go through direct, fix the rule order and tags before investigating DNS poisoning further.

Standard HTTPS vs. local mode: This guide uses an https:// address. Do not casually switch to https+local://; its local handling path does not fit the routing assumptions used here.
Node startup dependency: If the proxy server address is a domain, it still needs to be resolved before the proxy can connect. Do not make the initial lookup for the node's domain depend on that same proxy before it is up.
Merging rules: If you already have ad-blocking, LAN, or custom domain rules, merge these rules individually. Do not replace your entire existing routing configuration.

5. Apply and verify: check the runtime configuration before testing queries

v2rayN can generate configurations for different cores; the fields in this guide apply to Xray only. v2rayNG uses Xray, but some UI options may generate or override DNS settings. v2flyNG uses V2Fly, so similar field names alone do not mean this snippet can be used as-is. Settings locations vary by client version; verify against the active configuration and logs after startup.

UDP port for the example mainland China DNS resolver

443

HTTPS port for the example DoH resolver

Outbound tags to verify

Back up: Keep a working copy of your current connection and routing settings. Note the active node, selected core, and system proxy or VPN status.
Merge: Add the snippet through the DNS editor or custom configuration option provided by your client. If the editor accepts only the DNS object contents, do not paste the outer {"dns": ...} wrapper.
Check: Verify that the runtime configuration retains dns-internal, both DNS transport rules, and the correct outbound tags. Restart the core and check for errors such as unknown fields, missing data files, or nonexistent outbounds.
Test both groups: Choose one domain confirmed to be in the current geosite:cn set and another that does not match. Clear relevant caches or use a new test domain, then inspect the actual query connection.
Check the apps: Review secure DNS in the browser, Android Private DNS, and app exclusions separately. Do not mistake a browser's own DoH request for a built-in DNS query.

On Windows, run the command below to clear the system DNS cache if needed. It does not clear browser-specific, remote server, or core caches, so seeing no new query logs afterward does not by itself mean the configuration is broken.

ipconfig /flushdns

nslookup example.com 223.5.5.5 tests the system's connection to the specified resolver; it does not automatically use Xray's built-in DNS. Likewise, opening a website in a browser only shows that the application traffic path works—not that DNS routing is correct. To verify the setup, check whether the domain reaches the core, which resolver gets the query, and which outbound is used.

6. Prevent DNS poisoning and leaks: identify the failing layer

DNS poisoning may appear as an incorrect or unusual address, or a failed lookup, but a different result on a single query does not prove poisoning. CDNs return different addresses depending on the recursive resolver's location, carrier, and network conditions. Consider connection errors, certificate warnings, and results from repeated queries; different answers from two DNS resolvers alone are not enough to draw a conclusion.

Symptom	Check first	What to try
Mainland China domain lookup times out	Whether the mainland China entry matched and UDP port 53 is reachable	Check network restrictions and add a backup resolver for the same domain scope.
DoH connection times out	The `proxy` tag, rule order, and node connectivity	Restore the proxy connection first and keep standard TLS verification enabled.
Website loads, but there are no local query logs	Whether the proxy resolves the domain remotely and whether a cached result is being used	Trace how the domain is passed along; not every connection needs to trigger a local query.
Tests show an unexpected resolver	Browser secure DNS, system Private DNS, or apps bypassing the proxy	Test each path consistently, then confirm which resolver actually handled the query.
Some sites stall after enabling dual-stack	Direct IPv6 connectivity, node egress, and routing overrides	Temporarily switch back to `UseIPv4` for comparison, then enable IPv6 after verifying the IPv6 path.

Whether a DNS query counts as a leak depends on your intended policy. This guide explicitly allows domains in mainland China to use a direct resolver, so seeing those queries does not mean the policy has failed. Check whether queries meant to use the proxy are going out directly, and whether apps outside the interception scope are bypassing the settings.

7. FAQs: why didn't the results change after updating the settings?

Can changing only queryStrategy stop apps from using IPv6?

No. UseIPv4 limits queries made by this built-in DNS setup; it does not disable IPv6 on the system or stop apps from making their own AAAA queries. First check which resolution path the app's requests use, then review the VPN or other traffic interception scope.

Why do logs still show direct after I set a remote DNS server?

A remote address does not automatically mean proxy routing. Check that dns.tag matches the rule's inboundTag, that the rule for 1.1.1.1:443 comes before the catch-all, and that your actual proxy outbound is named proxy.

Why doesn't DoH take over when the mainland China DNS server fails?

This guide enables disableFallbackIfMatch, so queries that match a domain rule do not use the general fallback. For redundancy, first add another entry with the same domain match conditions. If you allow fallback across groups, verify again which domains are sent to each resolver.

What if a subscription update resets my DNS settings?

First check whether you changed settings saved by the client or a temporary configuration regenerated at every startup. Add your changes through a persistent DNS or custom configuration option supported by the client, then regenerate and verify the runtime configuration. Keep a backup so updates do not discard your rules.