v2rayN DNS Settings Explained: Split Resolution for Domains in Mainland China and Abroad

First distinguish system DNS, core DNS, and remote resolution

In v2rayN, open “Settings” → “Parameter Settings” and check the active core type, system proxy mode, and TUN status. DNS splitting depends not only on which servers you enter, but also on whether domain requests reach the Xray core. A standard system proxy mainly handles an application’s HTTP or SOCKS traffic, while some apps still query the operating system DNS directly. TUN mode covers more network requests, but you must also check DNS hijacking and routing rules.

System DNS is the resolver currently used by the network adapter or operating system. Core DNS is the top-level dns object in the generated configuration; it selects DNS servers according to domain rules. Remote resolution means the query is sent through a proxy outbound to the target resolver, not merely that the server address was changed to one outside mainland China. If the query packet still leaves through a direct connection, entering a remote server does not make it remote resolution.

Configure local DoH for mainland domains and remote resolution for overseas domains

Set up a low-latency local DoH resolver for mainland domains, then a remote DoH resolver for everything else that must be reached through the proxy. Split by domain sets rather than by the returned IP: this selects the resolver before the query is sent, preventing overseas domains from being exposed to a local resolver and receiving misleading results.

1. Open “Settings” → “Parameter Settings”, confirm that the Xray core is enabled, and note the local SOCKS listening port. The common default is 10808, but use the value shown on the current parameter page.
2. Open v2rayN’s DNS settings and select the configuration area for the active core. Interface labels may vary slightly by version. After editing, inspect the generated runtime configuration rather than relying only on the editor.
3. Bind the mainland DoH server to a domain rule such as geosite:cn, and use geoip:cn to constrain the expected returned addresses.
4. Place the remote DoH later in the matching order as the resolver for overseas and unmatched domains. Also ensure that the DoH domain or destination connection uses a proxy outbound.
5. Save the configuration and restart the core. Test one clearly mainland domain first, then one overseas domain; do not draw conclusions from a single site.

The snippet below shows the core structure of the Xray dns object. It is a structural example and should not replace v2rayN’s complete generated configuration. In practice, merge it through the client’s custom DNS section while preserving the existing log, inbound, outbound, and routing sections.

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableCache": false,
    "hosts": {
      "dns.local.example": "223.5.5.5"
    },
    "servers": [
      {
        "address": "https://dns.alidns.com/dns-query",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

When queryStrategy is set to UseIP, the core can request A and AAAA results according to network availability. If the local network has unreliable IPv6 but IPv6 queries are forced, resolution may succeed while the connection times out. IPv4-only environments can choose the appropriate strategy supported by the current core, but do not confuse query strategy with routing outbound selection.

Make sure remote DNS queries actually use the proxy outbound

Remote DoH is still an HTTPS connection. If routing sends its destination to a direct outbound, the query leaves through the local network. In the routing settings, explicitly proxy the remote resolver’s domain, while keeping the local DoH direct to preserve low latency for mainland queries.

• In “Settings” → “Routing Settings”, check the order of custom rules. The proxy rule for the remote DoH domain must come before broad direct-connection rules.
• The local DoH domain can be set to direct using geosite:cn or an explicit domain, and the connection usually uses port 443.
• If traditional DNS uses UDP 53, make sure TUN and the firewall do not let packets bypass the core. DoH uses HTTPS, making it easier to apply routing rules alongside ordinary TCP traffic.
• If a subscription node uses a domain as its server address, preserve a basic resolution path for the initial connection. Otherwise you can create a loop: the proxy must connect before the node can be resolved, but the node must be resolved before the proxy can connect.

During troubleshooting, open v2rayN’s log window and temporarily raise the core log level enough to observe DNS queries and routing matches. Then clear the system cache and visit the test domains in sequence. Look for the query type, matched DNS server, outbound tag, returned address, and timeout reason. Restore a lower log level afterward to reduce routine output.

Prioritize hosts, fakeDNS, and caching

hosts overrides specified domains before a regular DNS query begins. It is useful for fixed internal service addresses, temporarily bypassing broken resolution, or mapping one domain to another. It is not suitable for maintaining addresses for large, frequently changing sites: a fixed IP can bypass nearby routing and may break connections after the service changes addresses.

fakeDNS is commonly used with TUN. It first returns a synthetic address to the application, often from the 198.18.0.0/15 pool. The core then maps that synthetic address back to the original domain and routes the connection. This preserves domain information and avoids cases where the application resolves a real address at the system layer before giving the core only an IP. Enable it according to the current TUN configuration and core support.

The cache stores resolution results until their TTL expires, reducing duplicate queries and initial page-load delays. If old results remain after changing DNS rules, the new configuration may be working: a stale record may still exist in the system, application, or core cache. Restart the core first, then clear the operating system DNS cache and fully restart the application used for testing.

Hosts override

Returns a specified address or alias before querying regular servers. Best for a small number of clear, maintainable domain mappings.

fakeDNS

Returns a synthetic address to the application while retaining the original domain mapping in the core. Mainly solves domain identification for TUN traffic.

DNS cache

Reuses existing results according to their TTL. This reduces latency but can temporarily keep showing old results after a configuration change.

{
  "dns": {
    "hosts": {
      "internal.example": "192.168.10.20",
      "alias.example": "target.example"
    },
    "disableCache": false,
    "disableFallback": false
  }
}

After configuring hosts, check both DNS resolution and the actual connection. A correct address with an inaccessible website may indicate that the target requires the proper TLS domain, reverse-proxy entry point, or port. hosts changes address selection only; it does not rewrite certificate validation, the HTTP Host header, or the server’s listening configuration.

Locate resolution failures and unmatched rules by symptom

Break the issue into four categories: “no query was sent,” “the query used the wrong outbound,” “the returned result was unexpected,” and “resolution succeeded but the connection failed.” Website accessibility alone is not proof of a DNS issue; TLS handshakes, routing rules, node status, and the destination service can look identical.

Command-line tests provide supporting evidence, but nslookup queries the system DNS by default and may not pass through the Xray core. It is useful for checking the operating system’s current resolver, but cannot by itself prove a remote DoH path. To verify core-level split DNS, combine the command output with v2rayN core logs and observations of the network exit.

1. Record the DNS settings, routing mode, core type, and listening port before making changes.
2. Change one variable at a time—for example, adjust the resolver first, then the routing rules.
3. Restart the core and confirm there are no JSON parse errors, port conflicts, or DNS initialization failures.
4. Test one mainland domain and one overseas domain separately, recording the matched server and outbound tag.
5. Finally, restore the normal log level and save a working copy of the configuration.