V2Ray DNS Routing: Split DNS for Mainland China and Secure DNS for International Domains

At a glance

This guide is for users with a working proxy outbound who want to adjust their DNS strategy. First, distinguish resolver selection from the route DNS queries take. Then combine rules for mainland China, remote DoH, and direct outbound traffic, and use a separate test endpoint to verify the resolution path. Examples use V2Ray-style JSON snippets; they do not replace server settings in a subscription or assume that every client uses the same core.

1. DNS routing has two parts: resolver selection and query routing

DNS routing is more than adding two server addresses to a list. The first layer selects the resolver for a domain; the second determines whether the connection to that resolver goes direct or through a proxy. Both layers must be explicit to verify that queries for international domains follow the intended path. Encrypted DNS protects queries in transit, but cannot guarantee that the resolver always returns correct results.

Domain enters the core Select resolver Match query route Receive DNS response Connect to destination

The core's DNS is not the same as the operating system's DNS. When an app sends a domain through SOCKS, the proxy protocol may pass it to the server for resolution. If the app first asks the system resolver for an IP address, the core may see only the IP. Changing the dns object in the config does not automatically take over queries from every program on your computer or phone.

Core-side resolution: The built-in resolver is involved when routing needs an IP, a direct outbound needs to resolve a domain, or a DNS inbound passes requests to the DNS outbound.
Remote resolution: When a destination domain is sent to the server with a proxy request, the resolver used depends on the server environment.
App-level resolution: A browser's Secure DNS feature may send its own DoH requests instead of using the server list configured here.

2. Check the core, rule files, and outbound tags before configuring DNS

v2rayN is a desktop client for managing configurations; its behavior depends on the core currently in use. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Many fields are similar, but that does not mean all DNS options, FakeDNS behavior, and defaults are identical. Note the core name and version, then check the relevant configuration documentation to confirm which fields are supported.

In v2rayN, open Settings → Parameter Settings and check the options for the selected core. The DNS editor may be located elsewhere in different client versions, so follow the interface in your version.
Back up the current configuration, inspect outbounds in the generated config, and note the actual tag values for the proxy and direct outbounds.
Confirm that geosite.dat in the runtime directory is readable and includes the cn category. You only need the corresponding geoip.dat rules if you use IP categories.
Verify that the proxy connection works before changing DNS. If the proxy outbound is unreachable, a failed remote query does not necessarily point to the resolver.

Example UDP port for direct DNS

443

Example HTTPS port for remote DoH

1053

Port for the loopback test endpoint later in this guide

These numbers are configuration examples, not performance measurements. Below, the existing proxy outbound is called proxy and the direct outbound direct. If your actual tags differ, update every reference accordingly; copying only the names in the rules will not work.

3. Use direct DNS for mainland China domains and remote DoH for other queries

Merge the following snippet into the top-level dns field of your existing configuration. Queries matching the mainland China category use 223.5.5.5 first; queries that do not match use https://1.1.1.1/dns-query. These are example addresses, not a guarantee that either service is reachable on every network, nor a requirement to use this particular pair of public resolvers.

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

domains specifies the resolver's preferred matching criteria. geosite:cn relies on categories in the rule files; it is not a simple domain-suffix check and may not cover every site in mainland China.
skipFallback: true keeps this server out of the general fallback for unmatched domains, preventing queries for international domains from being sent to this direct resolver during fallback.
This configuration still allows queries that fail on the preferred mainland China resolver to fall back to the remote server. It is not a strict policy that guarantees queries for mainland China domains never leave the country. For strict isolation, check the core's fallback controls separately.
UseIPv4 helps narrow down IPv6-related issues during initial troubleshooting. It does not disable IPv6 system-wide. If you need dual-stack support, reassess the query strategy against your actual IPv6 routing.

Using an IP literal for the remote endpoint can reduce bootstrap dependencies—there is no need to resolve the DoH hostname just to connect to DoH—but TLS certificate validation is still required. Do not disable certificate validation to work around connection errors. If you switch to a hostname-based resolver, also plan bootstrap resolution for that hostname to avoid depending on the same DNS path that is not yet established.

4. Set the outbound for DNS queries to prevent default routes from changing the path

The rules below use AsIs, handling the two resolver endpoints first, mainland China domains next, and then sending all other TCP and UDP connections through the proxy. Standard https:// DoH and https+local://, which implies local direct access, are not interchangeable. This example routes query connections through the core, so it uses the former.

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

This basic strategy makes the query path easier to observe, but does not cover LAN, corporate intranet, or ad-filtering rules. When merging it into your configuration, keep any required existing rules and check their order: rules are generally matched in sequence, so a catch-all at the end must not override the resolver endpoint rules. The IP and port rules above also match other connections to the same endpoints; they do not identify only traffic generated by the DNS module.

For direct outbound connections, also check the Freedom domain strategy. The existing direct outbound should have the structure shown below; modify the relevant entry rather than adding a second tag with the same name. UseIP makes this outbound use the built-in DNS resolver to obtain the destination IP. Otherwise, it may continue to rely on system DNS by default.

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

In short: verify where names are resolved and where connections go

First confirm that the direct outbound for mainland China domains actually calls the built-in DNS resolver, then confirm that remote DoH connections match the proxy. A page loading successfully does not prove that DNS routing is working; when a proxy request carries the domain, resolution may still happen on the server.

5. Test with a dedicated DNS endpoint instead of relying on browser cache

To test the built-in resolver directly, append the following objects to the existing inbounds and outbounds arrays. Bind the inbound only to 127.0.0.1; do not change it to a public listening address. This endpoint is for local troubleshooting. It does not change system DNS or automatically take over browser queries.

{
  "tag": "dns-in",
  "listen": "127.0.0.1",
  "port": 1053,
  "protocol": "dokodemo-door",
  "settings": {
    "address": "1.1.1.1",
    "port": 53,
    "network": "tcp,udp"
  }
}

{
  "tag": "dns-out",
  "protocol": "dns",
  "settings": {}
}

Then place the following rule at the top of routing.rules from the previous section. This sends test requests to the DNS outbound instead of letting the final proxy catch-all rule handle them. For A and AAAA queries, the DNS outbound calls the built-in resolver. Verify handling and forwarding of other record types separately; do not substitute a TXT query for the address-record test in this example.

{
  "type": "field",
  "inboundTag": ["dns-in"],
  "outboundTag": "dns-out"
}

Restart the core and check the configuration load logs first, ruling out port conflicts, unknown fields, and failures to read rule files.
Run the following commands in an environment with dig installed to test the mainland China category and remote resolution path separately.
Check DNS debug logs alongside outbound connection logs to confirm which tags the two resolver endpoints actually use. You can temporarily increase the log level while troubleshooting, then restore it afterward.
Change one setting at a time. Repeated queries may hit the cache; if needed, restart the core and clear the app or system cache before comparing results.

dig @127.0.0.1 -p 1053 www.baidu.com A
dig @127.0.0.1 -p 1053 www.example.com A

Whether a test domain matches a category depends on the current rule files. Different DNS answers do not necessarily indicate poisoning: CDN routing, resolver location, and cache state can all affect the result. Check whether queries reach the expected resolver, whether they time out, and whether the final destination connection succeeds—instead of comparing only the IP addresses returned by two queries.

6. FakeDNS, caching, and the limits of routing resolution strategies

FakeDNS returns synthetic addresses that the core uses for mapping; they are not the real addresses of destination sites. It mainly helps preserve or recover domain names after traffic enters the proxy. It cannot replace a real resolver or fix an unreachable proxy server. Before enabling it, confirm that your core, traffic interception method, and domain-recovery path all support the relevant configuration.

Setting or mechanism	What it does	Common misconception
DNS queryStrategy	Controls which address family the built-in resolver queries or uses.	Assuming that setting IPv4 means all apps stop sending IPv6 traffic.
routing.domainStrategy	Controls whether routing obtains an IP address when matching rules.	Assuming AsIs means the core will never resolve domains.
Freedom domainStrategy	Controls how the direct outbound handles domains when establishing connections.	Changing only the DNS server list while the direct outbound still relies on system DNS.
FakeDNS	Maintains a mapping between domains and synthetic addresses; subsequent traffic must return to a core that can recover the mapping.	Enabling synthetic responses without ensuring the corresponding connections are also intercepted.
DNS cache	Reuses previous DNS results to reduce repeat queries.	Seeing an old result after a configuration change and assuming the new configuration did not load.

IPIfNonMatch attempts resolution when domain rules do not match, then continues matching IP rules. IPOnDemand triggers resolution when a rule requires an IP. Both can increase local DNS queries. If the configuration already has a catch-all rule that always matches, do not assume every domain will proceed to IP resolution.

Verify the basic path with standard DNS and explicit domain rules first, then add FakeDNS. This avoids introducing address mapping and DNS fallback as variables at the same time.
After changing rule files, restart or reload the core according to the client’s behavior. Updating the files alone does not mean the running core has switched to the new rules.
Troubleshoot browser Secure DNS, the system DNS cache, and the core DNS cache separately. Clearing one does not automatically clear the others.

7. Common split DNS problems and troubleshooting steps

Why is my browser still querying the local resolver after I configured remote DNS?

First confirm that the query reaches the core. Use the 1053 test endpoint above to verify it separately, then check browser Secure DNS and system proxy behavior. A standard system proxy usually handles app connections; it does not automatically take over the operating system's UDP 53 queries.

Mainland China sites load, but DNS queries for international domains keep timing out. What should I check?

Check that 1.1.1.1:443 matches proxy, and confirm that the tag exists and the proxy connection works. Then check for TLS errors and verify the system clock. If the proxy server address is a hostname, also rule out a bootstrap resolution loop caused by relying on remote DoH to resolve it.

Why did my DNS configuration disappear after I updated my subscription?

Check whether you made the changes in a runtime configuration temporarily generated by the client. Generated files may be overwritten when switching nodes or restarting. Save your settings through the DNS or custom configuration options provided by your client version, then inspect the generated config again to confirm that the fields and tags were preserved.

Some apps stopped connecting after I enabled FakeDNS. What should I change first?

First restore standard DNS resolution, restart the core, and clear the affected apps' caches. Once connectivity is back, check that connections to synthetic addresses return to the same core and that inbound domain recovery is configured as required by your core. Do not let an app that received a synthetic address bypass interception and connect directly.

Keep three records for final verification: the current core and configuration source, the outbound tags used by the two resolver endpoints, and query logs from the dedicated test endpoint. These help pinpoint whether an issue lies in resolver selection, query transport, or the destination connection, rather than prompting repeated changes to public DNS providers.