V2Ray DNS Configuration: Split DNS by Domain and Prevent DNS Spoofing

1. DNS Routing Is Not the Same as Connection Routing

First, adding a remote DNS server to your client does not mean every app will use it. Browsers can enable encrypted DNS independently, operating systems maintain their own caches, and proxy protocols may pass domain names to the server for resolution. The servers rules below only apply when a request actually reaches the built-in DNS module.

This sequence describes what happens when the built-in DNS module is called. It does not mean every proxy connection is resolved locally. After receiving a domain, the client can usually pass it to the server if routing selects a proxy outbound. A local lookup may be triggered if routing needs an IP address to make a decision, or if a direct connection needs the destination IP. The exact behavior depends on the routing policy and outbound configuration.

• DNS routing: Determines which DNS server handles a domain. Configure it under dns.servers.
• Connection routing: Determines whether application traffic goes direct or through a proxy. Configure it under routing.rules.
• DNS query routing: Determines whether connections to DNS servers go direct or through a proxy. Check the routing rules for this as well.

A system proxy generally handles requests from apps that honor the proxy settings; it does not automatically route all device DNS traffic. TUN can capture more traffic, but DNS hijacking, routing, and exclusions still need to be configured. The toggle state alone does not tell you whether queries reach the core.

2. What servers, domains, and queryStrategy Control

servers is a list of candidate resolvers. The domains property on a server object specifies which domains should prefer that resolver. queryStrategy controls whether to query for IPv4, IPv6, or both. These fields work at different levels; none can replace another.

Do not treat domains as a strict access whitelist. Whether another server is tried after a lookup fails also depends on fallback settings. The example below uses skipFallback to keep the local resolver from serving as the usual fallback for unmatched domains. It does not mean that a failed lookup for a matched domain will never be retried with another resolver.

geosite:cn relies on domain rule data in the runtime directory; the core does not identify locations on its own. If the startup log reports a missing rule file, fix the resource files first. For corporate intranet domains, use an appropriate domain: match and send queries to the company’s internal resolver. Public DNS servers cannot be expected to return internal IP addresses.

3. DNS Configuration for Split Routing by Domain

This example uses a local resolver and a default DoH resolver. The goal is to query domains in mainland China locally and use the remote resolver for other domains. Back up your configuration, then merge the top-level dns object into the existing JSON. If an object with the same name already exists, edit it instead of adding a second dns key.

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

The DoH endpoint uses an IP address to avoid a bootstrap dependency on resolving the DNS server’s hostname. If you use a DoH URL with a hostname instead, check which resolver handles that hostname and whether the lookup depends on the DoH service that is not yet reachable.

1. Check the core: v2rayN is a client interface, not a V2Ray core. Check the core startup log to see whether V2Ray or Xray is running, then verify which fields it supports.
2. Check the rule files: Startup must not report a failure to load geosite:cn; otherwise, the matching rules cannot work as intended.
3. Check the generated configuration: Restarting the client may overwrite manual edits if it generates the configuration through its interface. Save changes through the client’s supported custom configuration option, then inspect the configuration actually passed to the core.
4. Check the address family: Keep UseIP as the normal dual-stack setting. Temporarily switch to UseIPv4 only to investigate an IPv6 issue, and record the results for comparison.

This snippet has no inbound, proxy server, or outbound definitions, so it cannot run on its own. On Android, v2rayNG uses the Xray core and v2flyNG uses the v2fly core. Even if both interfaces have a DNS section, check their configuration overrides and operating modes separately.

4. Route DNS Queries Through the Right Outbound

A resolver address alone does not define the query route, so a “remote DNS” request may still go direct. Standard https:// DoH requests can go through core routing. Some cores support https+local://, which uses local access semantics; it is not an interchangeable version of the same URL.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "223.5.5.5/32"
        ],
        "port": "53",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32"
        ],
        "port": "443",
        "outboundTag": "proxy"
      }
    ]
  }
}

This is a separate merge example. It assumes the existing outbound tags are actually named direct and proxy. Tags are references in the configuration, not objects created automatically by the core. Replace the example names with your actual tags, and place both query rules before any broad rules that could match them first. Do not use these rules to override existing application routing.

AsIs means the routing stage will not resolve domain names just to evaluate IP-based rules. It does not mean application connections never need DNS resolution. With IPIfNonMatch, a request that does not match a domain rule may be resolved before IP rules are checked. With IPOnDemand, a rule that requires an IP may trigger a lookup. Before changing these values, confirm that you actually need IP-based routing.

Also check how the proxy server’s own hostname is resolved. If connecting to the proxy requires a DoH lookup through that same proxy, you have a circular dependency. Use a clearly defined bootstrap resolution path or an address confirmed by the provider; do not change server details from your subscription arbitrarily.

5. Prevent DNS Spoofing: Check Encryption, Routing, and Caches

DoH protects queries in transit between the client and resolver, but it cannot guarantee the results will meet your expectations. Resolver location policies, website CDN routing, device caches, and IPv6 connectivity can all lead to different addresses or successful lookups followed by failed connections. Different IPs from two resolvers are not, by themselves, proof of DNS spoofing.

• Check where queries start: A browser’s built-in secure DNS can bypass the operating system resolver. Temporarily disable it while troubleshooting, then decide whether to turn it back on after comparing results.
• Check where queries go: Review DNS errors and outbound connections in the core log. If needed, capture traffic on the device to check for unexpected outgoing UDP port 53 requests.
• Account for system caches: On Windows, run ipconfig /flushdns to clear the system DNS cache. This does not clear every cache maintained by browsers or the core.
• Change one variable at a time: Keep the target, node, and operating mode the same, and change only the resolver or address family. This helps avoid mistaking a change in proxy route for a DNS improvement.

The local resolver in this example uses regular UDP queries, so that part is not encrypted. If plaintext queries are unsuitable for your network, choose a reachable encrypted local resolver and design the corresponding routing rules. Do not just replace the address with a DoH URL without checking connectivity, certificate validation, and outbound policy.

6. DNS Troubleshooting Steps and FAQs

Save a working configuration first, then check in this order: core startup, outgoing queries, returned results, and application connections. Temporarily increase log verbosity and reproduce the issue with a single target so concurrent requests do not obscure the relevant entries. Restore your normal log level afterward, and remove subscription URLs and connection credentials before sharing logs.

nslookup -type=A example.com 223.5.5.5
nslookup -type=AAAA example.com 223.5.5.5
ipconfig /flushdns

example.com is a reserved example domain used for illustration. The first two commands query the specified regular DNS server directly to check whether that route works. They do not automatically use V2Ray’s built-in DNS or prove that DoH is going through the proxy. To verify core DNS routing, make a request from a real application and check the core logs and active configuration.

The final check is not how many DNS servers you have entered. All three of these must be true: local domains use the intended resolver, remote queries use the intended outbound, and application connections follow the planned routing. For more on client settings and configuration structure, see the client configuration guide and technical reference.