V2Ray DNS Setup: Split DNS, DoH Servers & DNS Leak Protection

1. First, identify what handles DNS requests

When DNS settings appear to have no effect, the problem often isn't an incorrect server address—the query may never reach the resolver you expect. The Windows system resolver, a browser's Secure DNS, V2Ray's built-in DNS, and the resolver on the proxy server are separate parts of the process. Changing one doesn't automatically change the others.

This diagram shows a common flow, but not every connection uses built-in DNS. For example, a browser using an HTTP proxy may submit the domain for the remote proxy to resolve. If the application resolves it locally first and passes the IP to the proxy, the core may receive only an IP address. Enabling “System proxy → Automatically configure system proxy” alone does not take over all Windows DNS requests.

• System proxy: Primarily affects apps that honor the system proxy settings; it is not a system-wide DNS forwarding switch.
• TUN mode: Captures traffic from more apps, but DNS interception still depends on the core in use, the TUN configuration, and routing.
• Built-in DNS: Resolves domains when the core needs an address. Adding a dns configuration does not automatically create a DNS service on the system's port 53.
• Browser Secure DNS: A browser may connect to a DoH service on its own. First decide whether the browser or the client should manage DNS resolution.

2. What do servers, domains, and expectIPs control?

servers defines the available upstream resolvers. A server object's domains sets query priority for specified domains, while expectIPs defines the expected address ranges in that server's responses. They answer three different questions: “which resolver?”, “which domains should prefer it?”, and “which results are acceptable?” Don't treat them all as traffic-routing rules.

domains is not an exclusive access-control rule. If a query to a matching server fails, or its response does not satisfy expectIPs, the query may still enter the fallback process. To restrict a mainland China resolver to specified domains, set skipFallback: true for it and keep an unrestricted remote resolver as the default candidate.

3. Split DNS example: Prefer a local resolver for mainland China; use DoH for other domains

This example uses 223.5.5.5 as the preferred resolver for domains in mainland China and https://1.1.1.1/dns-query as the default DoH upstream. “Local resolution” here means connecting directly from your device to the specified resolver—not using DNS automatically supplied by your router or ISP. These addresses are examples; verify that they are reachable and return suitable results on your network.

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

For domains matching geosite:cn, the mainland China resolver is queried first. Other domains use the unrestricted DoH candidate. If the mainland China resolver returns an address outside the expected range, the query may move on to another candidate. Avoid casually adding an unrestricted localhost: that would bring the system resolver back into the fallback path and undermine the boundary you're trying to establish.

expectIPs: ["geoip:cn"] is a relatively strict policy. Some websites in mainland China use overseas CDNs, so legitimate responses may be rejected and take longer to resolve. For those sites, check the specific domain and returned IP first, then adjust the domain group or that server's expected range. Don't assume an overseas IP means DNS poisoning.

4. Route DoH through your proxy: Add routing rules

DoH encrypts traffic to the resolver; it doesn't guarantee that requests automatically go through the proxy. In V2Ray, regular https:// DoH requests can be handled by routing, while local-mode https+local:// requests do not go through routing in the same way. If you want remote DoH to use your proxy server's egress, don't mix up these two formats.

These snippets still need to be merged into an existing configuration. They assume outbounds already contains a direct outbound tagged direct and a working proxy outbound tagged proxy. If your actual tags differ, replace them with the correct ones. Put these two rules for the upstream addresses before any broad rules that might match first.

{
  "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"
      }
    ]
  }
}

• Don't confuse the two strategy names: dns.queryStrategy controls address-family resolution; routing.domainStrategy controls how domains are handled during route matching. They serve different purposes.
• AsIs does not resolve domains for IP-based rules: If ordinary web connections carry only a domain, don't expect geoip:cn alone to route every site automatically. Configure separate domain-based routing rules for websites.
• The rule specifies an address and port: This example doesn't route all port 443 traffic through the same outbound. It applies only to connections to the specified resolver.
• Using an IP address for DoH: This can avoid a bootstrap lookup for the upstream hostname, but the service still needs a valid TLS certificate matching that address. Don't replace an arbitrary DoH hostname with an IP address.

By default, connections that don't match a rule use the default outbound, which is typically determined by outbound order. Don't skip checking DoH's outbound route and assume that receiving a response means the query went through the proxy. If your server address is a domain, it also needs an independent, working bootstrap resolution path; otherwise, you'll have a circular dependency where you need to connect to the server before you can resolve its address.

5. Before applying settings in v2rayN, keep a known-good baseline

v2rayN is a configuration management client, not a DNS protocol. Settings saved in its interface are converted into the core's runtime configuration. Direct edits to a temporary generated file may be overwritten when you switch servers or restart the core. Pasting V2Ray JSON into the configuration area for a different core may also prevent startup.

1. Record the current state. Save your existing DNS settings, current server, and routing mode. Make sure the current configuration can open the sites you use before changing the DNS strategy.
2. Choose the right configuration area. Under “Settings → DNS settings,” select the section for your current core. If your version provides a full DNS JSON editor, enter only the DNS object structure it expects—not the entire example file.
3. Manage full configurations separately. To maintain routing and outbounds yourself, use “Servers → Add custom configuration server” to import a complete core configuration. The two snippets in this guide omit inbounds, proxy outbounds, and other required elements, so they won't run as standalone configurations.
4. Restart the core and check the logs. Check JSON syntax, rule resources, and outbound tag errors before testing the network. A successful save doesn't guarantee a successful start.
5. Add features one at a time. First verify the default DoH resolver, then add the mainland China domain preference, and finally check TUN or browser-specific DNS settings. Change one layer at a time to make regressions easier to track down.

A local mixed-listener port is not a DNS port. Pointing an app's HTTP or SOCKS proxy to this port is entirely different from entering it as a DNS server. Check “Local mixed listener port” under “Settings → Parameter settings,” and don't substitute the example ports 53, 443, and 10808 for one another.

6. Verify split DNS and DNS leak protection: Check queries, outbound routes, and results separately

The goal isn't to find one “always correct” DNS address. It's to confirm that queries reach the expected upstream, connections use the expected outbound, and the returned addresses fit the website's actual deployment. CDNs return different addresses based on resolver location, proxy egress, and timing. Different results from two resolvers don't, by themselves, prove DNS poisoning.

nslookup www.baidu.com 223.5.5.5
ipconfig /flushdns
curl.exe --proxy http://127.0.0.1:10808 --head https://www.microsoft.com/

These are three separate checks: the first tests a specified resolver, the second clears the Windows DNS cache, and the third tests the local HTTP proxy connection. Before running the third, replace the port with the value shown in your settings. These commands are not an automated test for built-in DNS. In particular, an nslookup result does not prove that “DoH split routing is working.”

Clearing the system cache does not also clear every browser and core cache. To retest, restart the core and the test app. If you temporarily increase the log level, restore the usual level when you're done. Debug logs may contain visited domains, so don't post them publicly in full.

7. Common split DNS questions