V2Ray DNS Setup: Split DNS and Prevent DNS Spoofing

1. Where built-in DNS fits into a connection

“I configured DNS, so why is my browser still querying the system resolver?” The server address usually isn’t the problem—the request may never reach the core’s DNS module. Built-in DNS in V2Ray and Xray is a resolver the core can call. Adding a dns field does not automatically intercept every UDP port 53 request on your device.

When an app passes a domain to a SOCKS proxy, the core may send the domain to the remote server for resolution. If the app first resolves the domain through the system DNS and then passes the IP to the proxy, the core never sees the original domain. Neither path means that the client’s built-in DNS is necessarily in use.

• Routing needs an IP: When routing.domainStrategy is set to IPIfNonMatch, the router can query built-in DNS after no domain rule matches, then try the IP rules.
• A direct outbound needs an IP: Xray’s freedom outbound uses built-in DNS to resolve the connection address when configured with strategies such as UseIPv4.
• The device sends a regular DNS packet: You need a separate receiving, forwarding, or interception path. Configuring an upstream alone does not handle it.
• The browser uses Secure DNS: It may send its own HTTPS queries. Even over a proxy, those requests may not use the resolver configured in the core.

2. Choose upstreams, ports, and the core’s role

This setup sends mainland China domains to 223.5.5.5 and all other domains to https://1.1.1.1/dns-query, routing the latter through your existing proxy outbound. Using an IP address for the DoH endpoint avoids needing to resolve the resolver’s hostname just to connect to it. Keep normal TLS certificate verification enabled.

v2rayN is a desktop client, not a guarantee that a particular core is in use. v2rayNG uses Xray, while v2flyNG uses V2Fly. Check the supported fields and default behavior for the core you actually run. In particular, don’t apply Xray settings for DNS fallback, special address prefixes, or outbound resolution strategies unchanged to every core.

1. Back up a configuration that currently connects, and note the client version and core version shown in the startup log.
2. Make sure the running config has a proxy outbound, and note its actual tag. This example uses proxy; it does not ask you to change the protocol name.
3. Make sure geosite.dat is readable and includes the cn category. A missing data file causes rule loading to fail; it is not an upstream timeout.
4. Change one layer at a time: DNS first, routing next, then check whether the system and browser still resolve independently.

3. Route domains to upstreams and restrict fallback

This is a snippet for the top-level dns field. The mainland China server has a domain match list and handles only those domains. The DoH server has no domain list and serves as the general upstream for everything else. IPv4 is used here to remove IPv6 reachability as a variable during initial troubleshooting—not to suggest disabling IPv6 permanently.

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

• domains defines which queries match a DNS server; it is not a complete traffic routing rule. Sending a domain to a resolver does not automatically send its web traffic through the same outbound.
• skipFallback: true excludes this server from fallback for unmatched queries, preventing the mainland China upstream from also receiving queries for other domains.
• disableFallback: true disables fallback when a matching upstream fails. Queries that don’t match a dedicated domain list still use the default upstream; this does not mean that the default server is disabled for all queries.
• queryStrategy: "UseIPv4" limits the resolution strategy for these queries; it does not replace IPv6 routing management at the system level.

This config deliberately does not add localhost or the system DNS as a fallback. Otherwise, if proxy-based DoH is unreachable, queries may fall back to the very resolver path you wanted to avoid. If the startup log reports an unknown field, check the core’s documentation and version first. Don’t simply remove the fallback restrictions and assume the issue is fixed.

4. Route DoH through the proxy and make direct connections use built-in DNS

A DoH URL alone doesn’t tell you whether queries go through the node. Standard https:// DoH requests can be handled by the core router; the rules below send them to proxy by destination IP and port. Don’t casually switch to https+local://: it has different local lookup semantics, so the routing guidance here no longer applies.

Merge these rules into your existing routing config. Put DNS upstream rules before broad direct, IP-category, and final fallback rules. Replace proxy with your actual proxy outbound tag, and make sure direct matches an existing direct outbound. This example does not split traffic by destination IP, so it uses AsIs and avoids resolving every unfamiliar domain just for routing.

{
  "routing": {
    "domainStrategy": "AsIs",
    "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",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

This is a minimal routing example, not a replacement for necessary rules such as LAN bypasses or direct connections to node addresses. In particular, if a node uses a domain name, its bootstrap lookup must not depend on the proxy that is not connected yet, or startup can get stuck in a loop. You can keep the client’s existing node resolution method and check which upstream it uses separately.

Check the direct outbound too. The snippet below shows the freedom outbound object to merge or replace; it does not mean you should create a second outbound with the same name. Once configured, domains routed directly through this outbound use built-in DNS to obtain an IPv4 address.

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

5. Apply the config in v2rayN and v2rayNG

A DNS page in the graphical interface may not accept a complete Xray JSON config. Some fields accept only a server address; other pages separate basic and advanced settings. Check whether the field expects an address, a DNS object, or a complete config before pasting. Direct edits to a client’s temporary generated config are usually overwritten when you switch nodes or restart.

1. Desktop: find the right settings first: In v2rayN, open “Settings” → “DNS Settings” and check the DNS options for your current core. Then go to “Settings” → “Routing Settings” and review rule order. If your version uses different tabs, follow the descriptions shown for the actual fields.
2. Use a custom config for complex rules: To control dns, routing, and outbounds together, import the complete merged config via “Servers” → “Add custom config server” in v2rayN. Keep the existing node’s authentication, transport, and TLS settings.
3. Android: verify how the config runs: In v2rayNG, check VPN mode and DNS-related options under “Settings.” If you import a complete custom config, make sure it is the one actually running, not just saved in the list.
4. Don’t mix config formats: v2rayNG raw custom configs must follow the Xray structure; v2flyNG must use fields supported by V2Fly. A subscription link, a single-node share link, and a complete JSON config are three different input types.
5. Restart the connection after saving: Check the startup log for JSON parsing errors, unknown tags, or data file read errors. If startup fails, restore your backup first instead of toggling several options in a row and obscuring the cause.

6. Verify split DNS and DNS spoofing protection

A proper check answers three questions: who received the query, which outbound it used, and which address the app ultimately connected to. Seeing a working IP with nslookup does not prove that the core’s DNS is working; by default, it tests the system resolver path and can serve as a comparison.

Clear relevant caches before testing. On Windows, run the command below to clear the system DNS cache, then restart the core to clear its in-process cache. Browsers may keep their own caches too. Don’t repeatedly refresh the same cached domain and conclude the config is broken because no new query appears.

ipconfig /flushdns
nslookup www.example.com

For troubleshooting, briefly set the top-level log.loglevel to debug and inspect the connection logs. DNS details vary across core versions, so don’t rely on finding one specific log line. After testing, restore warning or the previous level, and avoid sharing full logs that expose visited domains, server addresses, or credentials.

• DoH keeps timing out: First check that the proxy node is available, the proxy tag is correct, and the rules are in the right order. Then check whether the service address is reachable.
• Certificate error: Check the device clock and TLS verification environment. Disabling certificate verification is not a DNS fix.
• A mainland China site resolves, but loads slowly: Check whether DNS returned an unsuitable CDN address and whether the web traffic is also going direct.
• A test page shows an overseas resolver: Interpret this in context. Proxy-based DoH may use an overseas recursive resolver; its location alone does not prove a leak.

7. Common questions